3、HashMap 有哪些属性？
如下，看代码注释，写的很清楚了。
// HashMap 初始化长度 static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16 // HashMap 最大长度 static final int MAXIMUM_CAPACITY = 1 << 30; // 1073741824 // 默认的加载因子 (扩容因子) static final float DEFAULT_LOAD_FACTOR = 0.75f; // 当链表长度大于此值且数组长度大于 64 时，会从链表转成红黑树 static final int TREEIFY_THRESHOLD = 8; // 转换链表的临界值，当元素小于此值时，会将红黑树结构转换成链表结构 static final int UNTREEIFY_THRESHOLD = 6; // 最小树容量 static final int MIN_TREEIFY_CAPACITY = 64;
4、为什么 HashMap 的初始化长度是 16 ？
前面说过，从 Key 映射到 HashMap 数组的对应位置，会用到一个 Hash 函数，比如：index = Hash ("狗哥")
注意到 HashMap 初始化长度用的是 1<<4，而不是直接写 16。这是为啥呢？其实这样是为了位运算的方便，「位与运算比算数计算的效率高太多了，之所以选择 16，是为了服务将 Key 映射到 index 的算法」。
那如何实现一个尽量均匀分布的 Hash 函数呢？从而减少 HashMap 碰撞呢？没错，就是通过 Key 的 HashCode 值来做位运算。
有公式（Length 是 HashMap 的长度）：「HashCode（Key） & （Length- 1）」
我举个例子，key 为 "book" 的十进制为 3029737 那二进制就是 101110001110101110 1001 HashMap 长度是默认的 16，length - 1 的结果。十进制 : 15；二进制 : 1111
把以上两个结果做与运算：101110001110101110 1001 & 1111 = 1001；1001 的十进制 = 9, 所以 index=9。
❝也就是说：「hash 算法最终得到的 index 结果，取决于 hashcode 值的最后几位」
❞ ❝你可以试试把长度指定为 10 以及其他非 2 次幂的数字，做位运算。发现 index 出现相同的概率大大升高。而长度 16 或者其他 2 的幂，length - 1 的值是所有二进制位全为 1, 这种情况下，index 的结果等同于 hashcode 后几位的值，只要输入的 hashcode 本身分布均匀，hash 算法的结果就是均匀的
❞
「所以，HashMap 的默认长度为 16，是为了降低 hash 碰撞的几率」。
5、为什么树化是 8，退树化是 6？
红黑树平均查找长度为 log (n)，长度为 8 时，查找长度为 3，而链表平均查找长度为 n/2；也就是 8 除以 2；查找长度链表大于树，转化为树，效率更高。
当为 6 时，树：2.6；链表：3。链表 > 树。这时理应也还是树化，但是树化需要时间，为了这点效率牺牲时间是不划算的。
6、什么是加载因子？加载因子为什么是 0.75 ？
前面说了扩容机制。那什么时候扩容呢？这就取决于原数组长度和加载因子两个因素了。
❝加载因子也叫扩容因子或负载因子，用来判断什么时候进行扩容的，假如加载因子是 0.5，HashMap 的初始化容量是 16，那么当 HashMap 中有 16*0.5=8 个元素时，HashMap 就会进行扩容。
❞
那加载因子为什么是 0.75 而不是 0.5 或者 1.0 呢？这其实是出于容量和性能之间平衡的结果：
- 上面说到，为了提升扩容效率，HashMap 的容量（capacity）有一个固定的要求，那就是一定是 2 的幂。所以，如果负载因子是 3/4 的话，那么和 capacity 的乘积结果就可以是一个整数
- 当加载因子设置较大时，扩容门槛提高，扩容发生频率低，占用的空间小，但此时发生 Hash 冲突的几率就会提升，因此需要更复杂的数据结构来存储元素，这样对元素的操作时间就会增加，运行效率也会降低；
- 当加载因子设置较小时，扩容门槛降低，会占用更多的空间，此时元素的存储就比较稀疏，发生哈希冲突的可能性就比较小，因此操作性能会比较高。
「所以综合了以上情况就取了一个 0.5 到 1.0 的平均数 0.75 作为加载因子」。
7、HashMap 是线程安全的么？
不是，因为 get 和 put 方法都没有上锁。「多线程操作无法保证：此刻 put 的值，片刻后 get 还是相同的值，会造成线程安全问题」。
还有个 HashTable 是线程安全的，但是加锁的粒度太大。并发度很低，最多同时允许一个线程访问，性能不高。一般我们使用 currentHashMap，当然啦，后面会聊到它的。
8、为什么重写 equals 方法的时，需要重写 hashCode 方法呢？
❝Java 中，所有的对象都是继承于 Object 类。Ojbect 类中有两个方法 equals、hashCode，这两个方法都是用来比较两个对象是否相等的。
❞
先来看看 equals 方法：
public boolean equals(Object obj) { return (this == obj); }
在未重写 equals 方法，他其实就是 == 。有以下两个特点：
- 对于值对象，== 比较的是两个对象的值
- 对于引用对象，== 比较的是两个对象的地址
看回 put 方法的源码：「HashMap 是通过 key 的 hashcode 去寻找地址 index 的。如果 index 一样就会形成链表」，也即是 "狗哥" 和 "阿狗" 是有可能在同一个位置上。
前面的 get 方法说过：「当哈希冲突时我们不仅需要判断 hash 值，还需要通过判断 key 值是否相等，才能确认此元素是不是我们想要的元素」。我们去 get 首先是找到 hash 值一样的，那怎么知道你想要的是那个对象呢？「没错，就是利用 equals 方法」，如果重写 hashCode 方法，不写 equals 方法，当发生 hash 冲突，hashcode 一样时，就不知道取哪个对象了。
9、HashMap 死循环分析
以下代码基于 JDK1.7 分析。这个问题，主要是 JDK1.7 的链表尾插法造成的。假设 HashMap 默认大小为 2，原本 HashMap 中没有一个元素。使用三个线程：t1、t2、t3 添加元素 key1，key2，key3。我在扩容之前打了个断点，让三个线程都停在这里。源码如下：
void transfer(Entry[] newTable, boolean rehash) { int newCapacity = newTable.length; for (Entry < K, V > e: table) { while (null != e) { Entry < K, V > next = e.next; // 此处加断点 if (rehash) { e.hash = null == e.key ? 0 : hash(e.key); } int i = indexFor(e.hash, newCapacity); e.next = newTable[i]; newTable[i] = e; e = next; } } }
假设 3 个元素 hash 冲突，放到同一个链表上。其中 key1→key2→key3 这样的顺序。没毛病，一切很正常。
此时放开断点，HashMap 扩容。就有可能变成这样：原来是 key1→key2→key3。很不幸扩容之后，key1 和 key2 还是在同一个位置，这时形成链表，如果 key2 比 key1 后面插入，根据头插法。此时就变成 key2→key1
最终 3 个线程都调整完毕，就会出现下图所示的死循环：这个时候 get (key1) 就会出现 Infinite Loop 异常。
当然发生死循环的原因是 JDK 1.7 链表插入方式为首部倒序插入，这种方式在扩容时会改变链表节点之间的顺序。「这个问题在 JDK 1.8 得到了改善，变成了尾部正序插入」，在扩容时会保持链表元素原本的顺序，就不会出现链表成环的问题。
10、总结
HashMap 是 Java 基础中的重点。可以说无论是在工作中还是面试中都很常用，小伙伴们必须做到熟练运用、信手拈来才算是过关的。本篇文章基本说到了 HashMap 的所有重点，红黑树没有展开说，主要是因为篇幅原因，后面会单独聊。另外，如果发现本文有啥错误，欢迎友善指正。
