HashMap学习（一）

先看JavaDoc，我先翻译如下：

• 基于HashTable的Map接口的实现，HashMap提供了所有的Map接口定义的操作，并允许null值和null键。
• HashMap类大致等同于HashTable，除了它是不同步的，并且允许空值，HashMap不保证Map的顺序；特别是它不能保证该顺序将随时间保持不变。
• HashMap的基本操作（get和put）提供恒定的时间性能，假设hash函数将各个桶中的元素适当地分散。
• Iterator的迭代时间是HashMap实例的“容量”（桶数）加上其大小（键值映射的数量）成比例，那么想要提升Iterator的性能，不要把初始容量设置太高（或者负载因子太低）。
• HashMap的一个实例有两个参数影响其性能：初始容量和负载因子，容量是哈希表中桶的数量，而初始容量仅仅是创建哈希表时的容量；负载因子是在容量自动增加之前允许哈希表的满度的容量比例。
• 当哈希表中的条目数目超过了负载因子和当前容量的乘积时，哈希表被rehashed（即，内部数据结构被重建），使得哈希表的桶数大约是桶数的两倍。
• 作为一般规则，默认负载因子（0.75）在时间和空间成本之间提供了很好的折衷，较高的值减少了空间开销，但增加了查找成本（反映在HashMap类的大部分操作中，包括get和put）。
• 在设置初始容量时，应考虑Map中预期的条目数目及其负载因子，以尽量减少重新散列操作的次数，如果初始容量大于由负载因子除以的条目的最大数量，则不会发生任何重散列操作。
• 如果将许多映射存储在HashMap实例中，那么以足够大的容量创建它将允许映射更有效地存储，而不是让它按照表的增长来执行rehash。
• HashMap线程不安全，如果多个线程同时访问HashMap，并且至少一个线程在结构上修改映射，则必须在外部进行同步。（结构修改是添加或删除一个或多个映射的任何操作，仅改变与实例所包含的键相关联的值不是结构修改。）
• 这通常是通过对一些自然封装的对象进行同步来实现的Map，如果不存在这样的对象，则应该使用Collections.synchronizedMap方法封装这个Map，这最好在创建时完成，以防止意外地不同步访问Map。
• 所有此类的“集合视图方法”返回的迭代器都是fail-fast的：如果Map在任何时候都被结构修改了。迭代器被创建，除了通过迭代器自身的移除方法外，迭代器将抛出ConcurrentMofificationException异常。
• 因此，在并发修改的情况下，迭代器快速且干净地失败，而不是在未来的不确定时间冒任意的、非确定性的行为。
• 注意，迭代器的fail-fast行为不能保证，一般来说，在不同步的并发修改的存在下，不可能做出任何硬的保证，fail-fast迭代器在尽力的基础上抛出ConcurrentMofificationException修改异常，因此，编写一个依赖于该异常的程序的正确性是错误的：迭代器的fail-fast行为应该只用于检测错误。