HashMap 1.7 与 1.8 的 区别，说明 1.8 做了哪些优化，如何优化的？

HashMap 1.7 与 1.8 的 区别，说明 1.8 做了哪些优化，如何优化的？
HashMap结构图

在JDK1.7 及之前的版本中， HashMap 又叫散列链表：基于一个数组以及多个链表的实现，hash值冲突的时候，就将对应节点以链表的形式存储。
JDK1.8 中，当同一个hash值（ Table 上元素）的链表节点数不小于8时，将不再以单链表的形式存储了，会被调整成一颗红黑树。这就是JDK7 与JDK8 中HashMap 实现的最大区别。

下面基于 JDK1.7.0_80 与 JDK1.8.0_66 做的分析

JDK1.7中
使用一个Entry 数组来存储数据，用key的hashcode 取模来决定key会被放到数组里的位置，如果hashcode 相同，或者hashcode 取模后的结果相同（ hash collision ），那么这些key 会被定位到Entry 数组的同一个格子里，这些key 会形成一个链表。

在hashcode 特别差的情况下，比方说所有key的hashcode 都相同，这个链表可能会很长，那么put/get 操作都可能需要遍历这个链表，也就是说时间复杂度在最差情况下会退化到O(n)

JDK1.8中
使用一个Node 数组来存储数据，但这个Node 可能是链表结构，也可能是红黑树结构

• 如果插入的key 的hashcode 相同，那么这些key也会被定位到Node 数组的同一个格子里。
• 如果同一个格子里的key不超过8个，使用链表结构存储。
• 如果超过了8个，那么会调用treeifyBin 函数，将链表转换为红黑树。

那么即使hashcode 完全相同，由于红黑树的特点，查找某个特定元素，也只需要O(log n)的开销
也就是说put/get的操作的时间复杂度最差只有O(log n)
但是真正想要利用JDK1.8 的好处，有一个限制：
key的对象，必须正确的实现了Compare 接口
如果没有实现Compare 接口，或者实现得不正确（比方说所有Compare 方法都返回0）
那JDK1.8 的HashMap 其实还是慢于JDK1.7 的