大热的《阿里巴巴 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 能放入的元素个数。
- Capacity 就是 HashMap 中数组的 length
- loadFactor 一般都是使用默认的 0.75
- threshold 决定能放入的数据量，一般情况下等于 Capacity * LoadFactor
以上参数在 JDK7 和 JDK8 中是一致的，接下来会根据实际代码分析。
JDK8 中的 HashMap 实现
以下内容见原文
https://yq.aliyun.com/article…