关于Java HashMap的那些你不清楚的的事情

大热的《阿里巴巴Java开发规约》中有提到：

【推荐】集合初始化时，指定集合初始值大小。
说明：HashMap使用如下构造方法进行初始化，如果暂时无法确定集合大小，那么指定默认值（16）即可：

public HashMap (int initialCapacity) {
    this(initialCapacity, DEFAULT_LOAD_FACTOR);
}

看到代码规约这一条的时候，我觉得是不是有点太 low 了，身为开发，大家都知道 HashMap 的原理。

什么？这个要通过插件监测？没必要吧，哪个开发不知道默认大小，何时 resize 啊，然后我和孤尽打赌随机咨询几位同学以下几个问题：

HashMap 默认bucket数组多大？
如果new HashMap<>(19)，bucket数组多大？
HashMap 什么时候开辟bucket数组占用内存？
HashMap 何时扩容？
抽样调查的结果出乎我的意料：

HashMap 默认bucket数组多大？（答案是16，大概一半的同学答错）
如果new HashMap<>(19)，bucket数组多大？（答案是32，大多被咨询同学都不太了解这个点）
HashMap 什么时候开辟bucket数组占用内存？（答案是第一次 put 时，一半同学认为是 new 的时候）
HashMap 何时扩容？（答案是put的元素达到容量乘负载因子的时候，默认16*0.75，有1/4同学中枪）
HashMap 是写代码时最常用的集合类之一，看来大家也不是全都很了解。孤尽乘胜追击又抛出问题：JDK8中 HashMap 和之前 HashMap 有什么不同？

我知道 JDK8 中 HashMap 引入了红黑树来处理哈希碰撞，具体细节和源代码并没有仔细翻过，看来是时候对比翻看下 JDK8 和 JDK7 的 HashMap 源码了。

通过对比翻看源码，先说下结论：

HashMap 在 new 后并不会立即分配bucket数组，而是第一次 put 时初始化，类似 ArrayList 在第一次 add 时分配空间。
HashMap 的 bucket 数组大小一定是2的幂，如果 new 的时候指定了容量且不是2的幂，实际容量会是最接近(大于)指定容量的2的幂，比如 new HashMap<>(19)，比19大且最接近的2的幂是32，实际容量就是32。
HashMap 在 put 的元素数量大于 Capacity LoadFactor（默认16 0.75）之后会进行扩容。
JDK8在哈希碰撞的链表长度达到TREEIFY_THRESHOLD（默认8)后，会把该链表转变成树结构，提高了性能。
JDK8在 resize 的时候，通过巧妙的设计，减少了 rehash 的性能消耗。

存储结构

JDK7 中的 HashMap 还是采用大家所熟悉的数组+链表的结构来存储数据。

JDK8 中的 HashMap 采用了数组+链表或树的结构来存储数据。

重要参数

HashMap中有两个重要的参数，容量(Capacity) 和负载因子(Load factor)

Initial capacity： The capacity is the number of buckets in the hash table, The initial capacity is simply the capacity at the time the hash table is created.
Load factor： The load factor is a measure of how full the hash table is allowed to get before its capacity is automatically increased.

Initial capacity 决定 bucket 的大小，Load factor 决定 bucket 内数据填充比例，基于这两个参数的乘积，HashMap 内部由 threshold 这个变量来表示 HashMap 能放入的元素个数。