HashMap底层运行原理/底层数据结构/扩容机制/并发修改异常/fast-fail机制/优化使用
Posted java_wxid
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了HashMap底层运行原理/底层数据结构/扩容机制/并发修改异常/fast-fail机制/优化使用相关的知识，希望对你有一定的参考价值。
—
文章目录
HashMap底层原理
向HashMap中存放一个元素(k1,v1)，先根据k1做hash算法，然后将hash值映射到内存地址，直接获取key所对应的数据。如果这个位置没有其它元素，将(k1,v1)直接放入一个Node类型的数组中，默认HashMap初始大小16，负载因子0.75，负载因子是一个介于0和1之间的浮点数，它决定了HashMap在扩容之前内部数组的填充度。所以当元素加到12的时候，底层会进行扩容，扩容为原来的2倍。【HashMap扩容机制】还会提到在jdk1.7的时候，这个扩容机制会引发的一些问题。如果该位置已经有其它元素(k2,v2)，那就调用k1的equals方法和k2进行比较二个元素是否相同。如果返回值为true，说明二个元素是一样的，用v1替换v2。如果返回值为false，说明二个元素是不一样的，用链表的形式将(k1,v1)存放。不过当链表中的数据较多时，查询的效率会下降，所以在JDK1.8版本后做了一个升级。HashMap存储数据时，需要满足链表长度超过8，数组长度大于64，才会将链表替换成红黑树才会树化时，会将链表替换成红黑树，来提高查找效率。
HashMap底层数据结构
HashMap中数据存储的结构是数组+链表/红黑树
- 数组作为基础的数据存储结构。
- 链表是为了解决hash碰撞问题，可参考【HashMap底层原理】。
- 红黑树是为了解决链表中的数据较多（满足链表长度超过8，数组长度大于64，才会将链表替换成红黑树才会树化）时效率下降的问题。
因为对于搜索，插入，删除操作多的情况下，使用红黑树的效率要高一些。
红黑树是一种特殊的二叉查找树，二叉查找树所有节点的左子树都小于该节点，所有节点的右子树都大于该节点，就可以通过大小比较关系来进行快速的检索。
在红黑树上插入或者删除一个节点之后，红黑树就发生了变化，当它不再是红黑树时，可以通过左旋和右旋，保证每次插入或者删除操作最多只需要三次旋转就能达到平衡。
因为红黑树强制约束了从根到叶子的最长的路径不多于最短的路径的两倍长，插入、删除和查找某个值的最坏情况时间都要求与树的高度成比例，这个在高度上的理论上限允许红黑树在最坏情况下都是高效的。
为什么是使用红黑树而不是AVL树？
CurrentHashMap中是加锁了的，实际上是读写锁，如果写冲突就会等待，如果插入时间过长必然等待时间更长，而红黑树相对AVL树他的插入更快！在AVL树中，从根到任何叶子的最短路径和最长路径之间的差异最多为1。在红黑树中，差异可以是2倍。
在AVL树中查找通常更快，但这是以更多旋转操作导致更慢的插入和删除为代价的，红黑树在添加，删除，查找相对较好。
那为什么HashMap不直接使用红黑树代替链表呢？
树的节点占的空间是普通节点的两倍，在节点足够多的时候才会使用树形数据结构，如果节点变少了还是会变回普通节点。所以节点太少的时候没必要转换、不仅转换后的数据结构占空间而且转换也需要花费时间。
在HashMap源码有这样一段描述，在使用分布良好的哈希代码时，很少使用树状容器。理想情况下，在随机散列码下，箱中节点的频率遵循泊松分布，默认大小调整阈值为0.75。
在理想状态下受随机分布的hashCode影响，链表中的节点遵循泊松分布，链表中的节点数是8的概率已经接近千分之一且此时链表的性能已经很差，所以在这种比较罕见的和极端的情况下才会把链表转变为红黑树，大部分情况下HashMap还是使用链表，如果理想的均匀分布节点数不到8就已经自动扩容了。
HashMap扩容机制
将(k1,v1)直接放入Node类型的数组中，这个数组初始化容量是16，默认的加载因子是0.75。
HashMap有两个参数影响其性能：初始容量和加载因子。
容量是哈希表中桶的数量，初始容量只是哈希表在创建时的容量。
加载因子其实是用来判断当前HashMap<K,V>中存放的数据量。
当哈希表中的条目数超出了加载因子与当前容量的乘积时，则要对该哈希表进行扩容、rehash操作（即重建内部数据结构），扩容后的哈希表将具有两倍的原容量。hashmap初始化容量时候，对容量大小做的处理，保证初始化容量为最近的2的幂次方。
HashMap初始化容量非得是2的幂次方，2的倍数不行么，奇数不行么？
- 2的幂次方：hashmap在确定元素落在数组的位置的时候，计算方法是(n - 1) & hash，n为数组长度也就是初始容量 。hashmap结构是数组，每个数组里面的结构是node（链表或红黑树），正常情况下，如果你想放数据到不同的位置，肯定会想到取余数确定放在那个数组里，计算公式：hash % n，这个是十进制计算。在计算机中， (n - 1) & hash，当n为2次幂时，会满足一个公式：(n - 1) & hash = hash % n，计算更加高效。
- 奇数不行：在计算hash的时候，确定落在数组的位置的时候，计算方法是(n - 1) & hash，奇数n-1为偶数，偶数2进制的结尾都是0，经过hash值&运算后末尾都是0，那么0001，0011，0101，1001，1011，0111，1101这几个位置永远都不能存放元素了，空间浪费相当大，更糟的是这种情况中，数组可以使用的位置比数组长度小了很多，这样就会造成空间的浪费而且会增加hash冲突。
HashMap加载因子为什么是0.75？
如果加载因子比较大，扩容发生的频率比较低，浪费的空间比较小，发生hash冲突的几率比较大。比如，加载因子是1的时候，hashmap长度为128，实际存储元素的数量在64至128之间时间段比较多，这个时间段发生hash冲突比较多，造成数组中其中一条链表比较长，会影响性能。
如果加载因子比较小，扩容发生的频率比较高，浪费的空间比较多，发生hash冲突的几率比较小。比如，加载因子是0.5的时候，hashmap长度为128，当数量达到65的时候会触发扩容，扩容后为原理的256，256里面只存储了65个浪费了。
综合了一下，取了一个平均数0.75作为加载因子。当负载因子为0.75,时代入到泊松分布公式，计算出来长度为8时，概率=0.00000006，概率很小了，链表长度为8时转红黑树。
可能引发的问题： HashMap实际使用过程中会出现一些性能问题以及线程安全问题。
在JDK1.7中有二块值得注意的地方。
- 扩容的时候需要rehash操作，需要将所有的数据重新计算HashCode，然后赋给新的HashMap<K,V>，rehash的过程是非常耗费时间和空间的。
- 当并发执行扩容操作时会造成环形链和数据丢失的情况，开多个线程不断进行put操作，所以当旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置(就是因为头插)，所以最后的结果打乱了插入的顺序，就可能发生环形链和数据丢失的问题，引起死循环，导致CPU利用率接近100%。
在JDK1.8中，对HashMap进行了优化。
- 经过rehash之后元素的位置，要么是在原位置，要么是在原位置再移动2次幂的位置。HashMap的数组长度恒定为2的n次方，也就是说只会为16，32，64，128这种数。即便你给的初始值是13，最后数组长度也会变成16，它会取与你传入的数最近的一个2的n次方的数。
扩容之后元素的位置是否改变，完全取决于紫色框框中的运算是为0还是1，为0则新位置与原位置相同，不需要换位置，不为零则需要换位置。
在扩充HashMap的时候，不需要像JDK1.7的实现那样重新计算hash，只需要看看原来的hash值新增的那个bit是1还是0就好了，是0的话索引没变，是1的话索引变成原位置+原数组长度。
为什么新的位置是原位置+原数组长度?
HashMap中运算数组的位置使用的是leng-1，对于初始长度为16的数组，扩容之后为32，对应的leng-1就是15，31。
举例一：假设某个元素的hashcode为52，这个52与15运算做按位与运算的的结果是4，这个52与31做按位与运算的的结果是20，20不就是等于4+16吗，刚好是原数组的下标+原数组的长度。
举例二：假设某个元素的hashcode为100，100&15=4，100&31=4，对于HashCode为100的元素来说，扩容后与扩容前其所在数组中的下标均为4。
以上两个例子证明了，经过rehash之后，元素的位置要么是在原位置，要么是在原位置加原数组长度的位置。
因为每次扩容会把原数组的长度*2，那么再二进制上的表现就是多出来一个1
比如原数组16-1二进制为0000 1111
那么扩容后的32-1的二进制就变成了0001 1111
再次扩容64-1就是0011 1111
扩容之后元素的位置是否改变则取决于与这个多出来的1的运算结果，运算结果为0则不需要换位置，运算结果为1则换新位置，新位置为老位置的高位进1。
既省去了重新计算hash值的时间，而且由于新增的1bit是0还是1，可以认为是随机的，因此resize的过程，均匀的把之前的冲突的节点分散到新的bucket了。
- 发生hash碰撞，不再采用头插法方式，而是直接插入链表尾部，因此不会出现环形链表的情况，但是在多线程环境下，会发生数据覆盖的情况，如果没有hash碰撞的时候，它会直接插入元素。如果线程A和线程B同时进行put操作，刚好这两条不同的数据hash值一样，并且该位置数据为null，线程A进入后还未进行数据插入时挂起，而线程B正常执行，从而正常插入数据，然后线程A获取CPU时间片，此时线程A不用再进行hash判断了，线程A会把线程B插入的数据给覆盖，导致数据发生覆盖的情况，发生线程不安全。可参考【HashMap并发修改异常】
HashMap并发修改异常
HashMap实际使用过程中会出现一些线程安全问题，在JDK1.7中，当并发执行扩容操作时会造成环形链和数据丢失的情况，开多个线程不断进行put操作，rehash的时候，旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置(就是因为头插)所以最后的结果打乱了插入的顺序，就可能发生环形链和数据丢失的问题，引起死循环，导致CPU利用率接近100%。在jdk1.8中对HashMap进行了优化，发生hash碰撞，不再采用头插法方式，而是直接插入链表尾部，因此不会出现环形链表的情况，但是在多线程环境下，会发生数据覆盖的情况，如果没有hash碰撞的时候，它会直接插入元素。如果线程A和线程B同时进行put操作，刚好这两条不同的数据hash值一样，并且该位置数据为null，线程A进入后还未进行数据插入时挂起，而线程B正常执行，从而正常插入数据，然后线程A获取CPU时间片，此时线程A不用再进行hash判断了，线程A会把线程B插入的数据给覆盖，导致数据发生覆盖的情况，发生线程不安全。可参考【HashMap扩容机制】
实际的故障现象：java.util.ConcurrentModificationException并发修改异常。导致原因：并发争取修改导致，一个线程正在写，一个线程过来争抢，导致线程写的过程被其他线程打断，导致数据不一致。
使用HashTable
HashTable是线程安全的，只不过实现代价却太大了，简单粗暴，get/put所有相关操作都是synchronized的，这相当于给整个哈希表加了一把大锁。多线程访问时候，只要有一个线程访问或操作该对象，那其他线程只能阻塞，相当于将所有的操作串行化，在竞争激烈的并发场景中性能就会非常差。
使用工具类
线程同步：Map<String,String> hashMap = Collections.synchronizedMap(new HashMap<>());
和Hashtable一样，实现上在操作HashMap时自动添加了synchronized来实现线程同步，都对整个map进行同步，在性能以及安全性方面不如ConcurrentHashMap。
使用写时复制(CopyOnWrite)
往一个容器里面加元素的时候，不直接往当前容器添加，而是先将当前容器的元素复制出来放到一个新的容器中，然后新的元素添加元素，添加完之后，再将原来容器的引用指向新的容器，这样就可以对它进行并发的读，不需要加锁，因为当前容器不添加任何元素。利用了读写分离的思想，读和写是不同的容器。
会有内存占用问题，在复制的时候只是复制容器里的引用，只是在写的时候会创建新对象添加到新容器里，而旧容器的对象还在使用，所以有两份对象内存。
会有数据一致性问题，CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。
使用ConcurrentHashMap
为了应对hashmap在并发环境下不安全问题可以使用，ConcurrentHashMap大量的利用了volatile，CAS等技术来减少锁竞争对于性能的影响。在JDK1.7版本中ConcurrentHashMap避免了对全局加锁，改成了局部加锁（分段锁），分段锁技术，将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问，能够实现真正的并发访问。不过这种结构的带来的副作用是Hash的过程要比普通的HashMap要长。
所以在JDK1.8版本中CurrentHashMap内部中的value使用volatile修饰，保证并发的可见性以及禁止指令重排，只不过volatile不保证原子性，使用为了确保原子性，采用CAS（比较交换）这种乐观锁来解决。
fast-fail机制
在系统设计中，快速失效系统一种可以立即报告任何可能表明故障的情况的系统。快速失效系统通常设计用于停止正常操作，而不是试图继续可能存在缺陷的过程。这种设计通常会在操作中的多个点检查系统的状态，因此可以及早检测到任何故障。快速失败模块的职责是检测错误，然后让系统的下一个最高级别处理错误。其实就是在做系统设计的时候先考虑异常情况，一旦发生异常，直接停止并上报。
以下的代码是一个对两个整数做除法的方法，在fast_fail_method方法中，我们对被除数做了个简单的检查，如果其值为0，那么就直接抛出一个异常，并明确提示异常原因。这其实就是fail-fast理念的实际应用。
public int fast_fail_method(int arg1,int arg2)
if(arg2 == 0)
throw new RuntimeException("can't be zero");
return arg1/arg2;
在Java集合类中很多地方都用到了该机制进行设计，一旦使用不当，触发fail-fast机制设计的代码，就会发生非预期情况。我们通常说的Java中的fail-fast机制，默认指的是Java集合的一种错误检测机制。当多个线程对部分集合进行结构上的改变的操作时，有可能会触发该机制时，之后就会抛出并发修改异常ConcurrentModificationException。当然如果不在多线程环境下，如果在foreach遍历的时候使用add/remove方法，也可能会抛出该异常。
之所以会抛出ConcurrentModificationException异常，是因为我们的代码中使用了增强for循环，而在增强for循环中，集合遍历是通过iterator进行的，但是元素的add/remove却是直接使用的集合类自己的方法。这就导致iterator在遍历的时候，会发现有一个元素在自己不知不觉的情况下就被删除/添加了，就会抛出一个异常，用来提示可能发生了并发修改！所以，在使用Java的集合类的时候，如果发生ConcurrentModificationException，优先考虑fail-fast有关的情况，实际上这可能并没有真的发生并发，只是Iterator使用了fail-fast的保护机制，只要他发现有某一次修改是未经过自己进行的，那么就会抛出异常。
HashMap优化使用
- 不能用==判断或者可能有哈希冲突时，尽量减少长度，一旦冲突也会少用点时间。如果hashCode 不冲突，那查找效率很高，但是如果hashCode一旦冲突，要调用equals一个字节一个自己的去比较，key越短效率越高。
- 建议采用String，Integer这样的类作为键。特别是String，他是不可变的，也是final的，而且已经重写了equals 和hashCode方法，这个和HashMap 要求的计算hashCode的不可变性要求不谋而合，核心思想就是保证键值的唯一性，不变性，其次是不可变性还有诸如线程安全的问题，以上这么定义键，可以最大限度的减少碰撞的出现。
- 迭代器遍历Map，在各个数量级效率稳定且较高，一般采用Iterator迭代器遍历Map。数据量为10000以下时，迭代器遍历entrySet，迭代器遍历keySet()后map.get(key)，for循环遍历keySet()后Map.get(key)这三种遍历方式效率较高，数据量为10000以上时，for循环遍历entrySet，迭代器遍历entrySet这二种方式效率较高。
- concurrentHashMap或迭代器Iterator遍历删除，当遍历Map需要删除的时候，不可以for循环遍历，否则会产生并发修改异常CME，只能使用迭代器iterator.remove()来删除元素，或者使用线程安全的concurrentHashMap来删除Map中的元素。
- 考虑加载因子地设定初始大小，设定时一定要考虑加载因子的存在。使用的时候最好估算存储的大小，如果初始桶为16，等到满16个元素才扩容，某些桶里可能就有不止一个元素了。所以加载因子默认为0.75，也就是说大小为16的HashMap，到了第13个元素，就会扩容成32。Guava的做法则是加上如下计算
(int) ((float) expectedSize / 0.75F + 1.0F); - 减小加载因子，如果你的Map是一个长期存在而不是每次动态生成的，而里面的key又是没法预估的，那可以适当加大初始大小，同时减少加载因子，降低冲突的机率。毕竟如果是长期存在的map，浪费点数组大小不算啥，降低冲突概率，减少比较的次数更重要。
- 使用IntObjectHashMap，HashMap的结构是 Node[] table; Node 下面有Hash，Key，Value，Next四个属性。而IntObjectHashMap的结构是int[] keys 和 Object[] values。在插入时，同样把int先取模落桶，如果遇到冲突，则不采样HashMap的链地址法，而是用开放地址法（线性探测法）index＋1找下一个空桶，最后在keys[index]，values[index]中分别记录。在查找时也是先落桶，然后在key[index++]中逐个比较key。所以，对比整个数据结构，省的不止是int vs Integer，还有每个Node的内容。性能IntObjectHashMap还是稳赢一点的，随便测了几种场景，耗时至少都有24ms vs 28ms的样子，好的时候甚至快1/3。
以上是关于HashMap底层运行原理/底层数据结构/扩容机制/并发修改异常/fast-fail机制/优化使用的主要内容，如果未能解决你的问题，请参考以下文章
java集合专题 （ArrayListHashSet等集合底层结构及扩容机制HashMap源码）