默认的价值加载因子为2/3,在重新哈希后，加载因子变为1/3.当哈希表中的条目数超出了加载因子与当前容量的乘积时，通过调用 reszie 方法将容量翻倍,重新进行哈希。增加桶数，重新哈希，可能相当昂贵。
 因此创建具有足够大的期望最大数量的标识哈希映射更合算。另一方面，对 collection 视图进行迭代所需的时间与哈希表中的桶数成正比，
 所以如果特别注重迭代性能或内存使用，则不宜将期望的最大数量设置得过高。
 注意，此实现不是同步的。如果多个线程同时访问此映射，并且其中至少一个线程从结构上修改了该映射，
 则其必须 保持外部同步（结构上的修改是指添加或删除一个或多个映射关系的操作；仅改变与实例已经包含的键关联的值不是结构上的修改。）
 这一般通过对自然封装该映射的对象进行同步操作来完成。如果不存在这样的对象，则应该使用 Collections.synchronizedMap 方法来“包装”该映射。
 最好在创建时完成这一操作，以防止对映射进行意外的不同步访问，如下所示：
      Map m = Collections.synchronizedMap(new HashMap(...));
 由所有此类的“collection 视图方法”所返回的迭代器都是快速失败 的：在迭代器创建之后，
 如果从结构上对映射进行修改，除非通过迭代器自身的 remove 或 add 方法，其他任何时间任何方式的修改，
 迭代器都将抛出 ConcurrentModificationException。因此，面对并发的修改，迭代器很快就会完全失败，
 而不冒在将来不确定的时间任意发生不确定行为的风险。
 注意，迭代器的快速失败行为不能得到保证，一般来说，存在不同步的并发修改时，不可能作出任何强有力的保证。
 快速失败迭代器尽最大努力抛出 ConcurrentModificationException。因此，编写依赖于此异常的程序的方式是错误的，正确做法是：
 迭代器的快速失败行为应该仅用于检测程序错误。
 实现注意事项：此为简单的线性探头哈希表，如 Sedgewick 和 Knuth 原文示例中所述。
 该数组交替保持键和值（对于大型表来说，它比使用独立组保持键和值更具优势）。对于多数 JRE 实现和混合操作，
 此类比 HashMap（它使用链 而不使用线性探头）能产生更好的性能。 
 注意1：允许 null 值和 null 键。
 注意2：此类对映射的顺序不提供任何保证；特别是不保证顺序随时间的推移保持不变。
 注意3：此实现不是同步的。
 注意4：迭代器的快速失败行为不能得到保证。
 注意5：此为简单的线性探头哈希表。对于多数 JRE 实现和混合操作，
 此类比 HashMap（它使用链 而不使用线性探头）能产生更好的性能。