HashMap底层原理实现

简述

在jdk1.7之前，使用数组加链表的形式组成的

1.8之后新增红黑树的组成结构，链表大于8且容量大于64的时候转为红黑树结构

数组中的元素叫做hash桶

组成结构图如下：

每个hash桶中包含四个字段，hash，key，value，next

为什么会加入红黑树？

一旦链表过长，会严重影响HashMap的性能，红黑树具有快速增删改查的特点，可以有效解决链表过长时间操作比较慢的问题

为什么加入红黑树而不选择AVL树（完全平衡二叉树）

为什么HashMap使用红黑树而不使用AVL树-感谢Running-Waiting

在CurrentHashMap是加锁的（读写锁），如果冲突就会等待，插入时间过长就会导致等待时间过长，红黑树相对AVL插入更快

红黑树和AVL树都是最常用的平衡二叉搜索树，它们的查找、删除、修改都是O(lgn) time

AVL树和红黑树有几点比较和区别：
（1）AVL树是更加严格的平衡，因此可以提供更快的查找速度，一般读取查找密集型任务，适用AVL树。
（2）红黑树更适合于插入修改密集型任务。
（3）通常，AVL树的旋转比红黑树的旋转更加难以平衡和调试。

总结：
（1）AVL以及红黑树是高度平衡的树数据结构。它们非常相似，真正的区别在于在任何添加/删除操作时完成的旋转操作次数。
（2）两种实现都缩放为a O(lg N)，其中N是叶子的数量，但实际上AVL树在查找密集型任务上更快：利用更好的平衡，树遍历平均更短。另一方面，插入和删除方面，AVL树速度较慢：需要更高的旋转次数才能在修改时正确地重新平衡数据结构。
（3）在AVL树中，从根到任何叶子的最短路径和最长路径之间的差异最多为1。在红黑树中，差异可以是2倍。
（4）两个都给O（log n）查找，但平衡AVL树可能需要O（log n）旋转，而红黑树将需要最多两次旋转使其达到平衡（尽管可能需要检查O（log n）节点以确定旋转的位置）。旋转本身是O（1）操作，因为你只是移动指针。

HahsMap从JDK1.7到1.8

JDK1.7

JDK1.7 HashMap的扩容导致get的时候出现死循环-[[qq_38229543]

如果是在单线程下使用HashMap，自然是没有问题的，如果后期由于代码优化，这段逻辑引入了多线程并发执行，在一个未知的时间点，会发现CPU占用100%，居高不下，通过查看堆栈，你会惊讶的发现，线程都Hang在hashMap的get()方法上，服务重启之后，问题消失，过段时间可能又复现了

头插法（首部倒入排序）发生了死循环

总结
所以在并发的情况，发生扩容时，可能会产生循环链表，在执行get的时候，会触发死循环，引起CPU的100%问题，所以一定要避免在并发环境下使用HashMap

JDK1.8

尾插发（使用尾部顺序插入）

同样会多线程会死锁（与之前JDK1.7不一样）-树化过程长度为8和退树化长度为6过程

至于为什么是8和6呢

避免频发的触发类型转换带来的性能开销

HashMap没有对多线程的场景下做任何的处理，不用说别的，就两个线程同时put，然后冲突了，两者需要操作一个链表/红黑树，这肯定就会有错误发生，所以HashMap是线程不安全的。

参考：

JDK1.8前多线程并发下HashMap会发生死循环

HashMap在jdk1.8也会出现死循环的问题（实测）

HashMap在jdk1.8中也会死循环

JDK8中HashMap依然会死循环！

什么可以解决线程不安全的问题呢？哪个更优秀？

HashTable

底层数组+链表实现，无论key还是value都不能为null，线程安全，实现线程安全的方式是在修改数据时锁住整个HashTable，效率低

ConcurrentHashMap

• 底层采用分段的数组+链表实现，线程安全

• 通过把整个Map分为N个Segment，可以提供相同的线程安全，但是效率提升N倍，默认提升16倍。(读操作不加锁，由于HashEntry的value变量是 volatile的，也能保证读取到最新的值。)

• Hashtable的synchronized是针对整张Hash表的，即每次锁住整张表让线程独占，ConcurrentHashMap允许多个修改操作并发进行，其关键在于使用了锁分离技术

• 有些方法需要跨段，比如size()和containsValue()，它们可能需要锁定整个表而而不仅仅是某个段，这需要按顺序锁定所有段，操作完毕后，又按顺序释放所有段的锁

• 扩容：段内扩容（段内元素超过该段对应Entry数组长度的75%触发扩容，不会对整个Map进行扩容），插入前检测需不需要扩容，有效避免无效扩容

  加载因子为什么是0.75

  平衡效率和空间上的开销

  0.75>0.5

  更难达到扩容的门槛，扩容的概率下降，对应的占用空间就会比较小，发生hash冲突的可能性就会提升，因此需要更复杂的数据结构来存储元素，这样对元素的操作时间就会增加，效率降低；

  0.75<1

  扩容的门槛比较低，会占用更多的空间，存储比较稀疏，hash碰撞概率就会比较小，操作性就更高。

  HashMap的容量是2的幂次方，这样容量和加载因子相乘会得到一个整数。

  HashMap三种重要方法

  查询

  当hash冲突时（HashMap使用拉链法解决hash冲突具体参考：什么是拉链法）我们需要判断key值是否相等，才能确定是否是我们想要的元素

  新增：

  1.判断hash表是否为空-是扩容，否2

  2.根据key得到下标，在table中有没有这个下标直接赋值，有直接插入，没有3

  3.判断key值是否相等，是，直接赋值（更新操作）否4

  4.判断是否是红黑树，是，红黑树插入值，否5

  5.遍历链表插入，检查节点大于8，大于8红黑树插入，否链表插入

  6.插入的值，检查hash表是否大于threshold（加载因子（loadFactor*capacity）），是扩容，否结束。

  扩容：

  不像JDK1.7重新计算每个元素的hash值，JDK1.8通过高位运算（e.hash&oldCap）来确定元素是否移动

PS

面试必备：HashMap、Hashtable、ConcurrentHashMap的原理与区别–猿人谷