Java刷题知识点之HashMap的实现原理、HashMap的存储结构、HashMap在JDK1.6、JDK1.7、JDK1.8之间的差异以及带来的性能影响HashMap的实现原理HashMap的存储结构牛客网Java刷题知识点之数组、链表、哈希表、 红黑二叉树HashMap在JDK1.6中的实现方式HashMap在JDK1.7中的实现HashMap在JDK1.8中的实现HashMap的不足以及产生原因总结

　　HashMap是基于java.util.map接口的实现，该实现提供了所有的对Map的可选操作，同时也允许null类型的key以及value （HashTable与此大致相同，只是HashTable是同步的，不过HashTable一般被认为是已经过时的，很少有人再去用了）。

　　HashMap不保证Map中的顺序，特别是不能保证数据在一段时间内的顺序性。

　　如果散列函数（Hash函数）在正确的在桶中分散元素，HashMap的实现提供了对基本的操作（put与get）时间性能为常数。

　　集合视图的迭代需要的时间与HashMap实例的容量capacity值（桶数）和大小（键值对个数）成正比，所以如果对迭代器的性能比较关注， 那么不要把初始化的容量capacity值设的太高或不要将装填因子load factor设的太小就非常重要。

　　HashMap的实例总有两个非常重要的影响性能的参数：初始容量大小（initial capacity）与装填因子（load factor）。

       在HashMap中，capacity就是buckets的数量，初始容量大小就是在HashMap创建的时候指定的capacity。

　　装填因子指的是HashMap在多满的时候就需要提前自动扩容了（如初始化容量16，装填因子0.75，一旦元素个数 超过16*0.75=12个的时候，就需要对容量进行扩充，翻倍） 扩容需要rehash，也就是说HashMap内部结构会被重新构建。

　　通常来讲，默认的装填因子0.75提供了一个基于时间与空间代价比较好的平衡。桶中装的更满意味着空间开销更低， 但是查找开销变大（反映到HashMap中就是包含get与put在内各种操作开销变大，时间变长）。

　　当设置初始容量大小时，应该考虑HashMap中预期的数量以及装填因子，这样才能让rehash执行的次数最少， 如果初始化大小的值比实际数据的条数乘以装填因子的积还要大，那么就不会发生rehash。

　　如果有非常多的记录存在HashMap中，那么在初始化这个HashMap的时候将容量capacity设置的足够大，比自动rehash 扩容效率更高。

　　注意如果很多key有了相同的hashCode值，那么会对性能造成很大的影响（产生聚集问题，rehash次数变多，性能下降），为了改善这种情况 当key可以进行比较（继承了Comparable接口之类的），HashMap会采用对key进行比较排序。

　　注意：HashMap不是线程同步的。

　　如果多线程并发访问一个HashMap，同时至少有一个线程修改了HashMap的结构，那么该HashMap必须要在外部进行同步 （结构的改变指的是添加或删除一个映射关系-键值对，只是根据key修改了value的值不会对HashMap造成结构上的影响） 这种同步操作通常在封装有HashMap的Object中实现；如果没有这样的对象实现，那么HashMap需要采用Collections.synchronizedMap 来保证多线程并发环境下的数据同步问题，这个操作最好在创建HashMap的时候就去做。 Map m = Collections.synchronizedMap(new HashMap(…));

　　如果HashMap产生的迭代器创建后，HashMap数据结构又发生了变化，则除了remove方法外，迭代器iterator会抛出一个 ConcurrentModificationException异常，这就是迭代器的快速失败（fail-fast）。 因此面对并发修改，迭代器采用快速而干净的失败来取代在未来的某一个不确定的时间产生不确定的后果。

　　注意：迭代器的快速失败行为是无法保证的，通常来讲，在非同步并发修改的情况下这种硬性保证都没法给出，快速失败也只能尽量抛出 ConcurrentModificationException异常，所以不能写一段代码去基于该异常做出义务逻辑处理，最好快速失败进行BUG探测。

　　HashMap的存储，本质上是构造了一个table，根据计算的hashCode将对应的KV存储到该table中，一旦发生hashCode冲突，那么就会将该KV放到对应的已有元素的后面， 此时，形成了一个链表式的存储结构，即：HashMap 就是一个table数组  +   链表实现的存储结构（在JDK1.8之前的存储结构），如下图所示：

　　

　　 从上图中，我们可以发现哈希表是由数组  +   链表组成的，一个长度为16的数组中，每个元素存储的是一个链表的头结点。那么这些元素是按照什么样的规则存储到数组中呢。一般情况是通过hash(key)%len获得，也就是元素的key的哈希值对数组长度取模得到。比如上述哈希表中，12%16=12,28%16=12,108%16=12,140%16=12。所以12、28、108以及140都存储在数组下标为12的位置。它的内部其实是用一个Entity数组来实现的，属性有key、value、next。

　　当构造出一个HashMap后，每次put一个元素时，会执行addEntry操作，addEntry中会执行创建一个Entry实体存储当前的KV，如果有Hash冲突， 那么就会将当前的entry指向最后一个冲突的entry，同时将当前的entry放到链表中，执行完当前操作后，判断是否需要resize，如果需要，则构造出一个新的entry数组（比之前大一倍）， 并将原有的数组中的entry链表（或entry）拷贝到新的数组中。

 　　在JDK1.8中有了一些变化，当链表的存储的数据个数大于等于8的时候，不再采用链表存储，而采用了红黑树存储结构。如下图所示：

　　 这么做主要是查询的时间复杂度上，链表为O(n)，而红黑树一直是O(logn)，一般来讲，冲突（即为相同的hash值存储的元素个数） 超过8个，红黑树的性能高于链表的查找性能。

　　put方法：

　　put方法完成数据的基本写入操作，同时会验证数据的有效性，如key是否为空的处理，计算hash值，hash值 的查找，并根据hash值找出所有的数据，判断是否重复，如果重复，则替换，并返回旧值，如果不重复，则写入数据（addEntry）。

　　对应的addEntry方法： addEntry方法实现了数据的写入以及判断是否需要对HashMap进行扩容。

　　resize方法： resize方法主要是对Map进行扩容的实际操作：构造存储结构，并调用数据转移方法transfer进行数据转移

　　transfer 方法： 完成数据转移，注意，转移的过程就是两个数组进行数据拷贝的过程，数据产生了倒置，新元素其实是插入到了第一个位置。

　　 Entry的构造： 链式存储结构。

　　JDK1.7中的实现与JDK1.6中的实现总体来说，基本没有改进，区别不大。

　　put 方法：

　　addEntry方法：

　　resize方法：

　　transfer方法：

　　createEntry方法：

　　put方法： put方法中与JDK1.6/1.7相比，新增了判断是否是TreeNode的逻辑，TreeNode即为红黑树， 同时添加了冲突的元素个数是否大于等于7的判断（因为第一个是-1，所以还是8个元素），如果冲突的元素个数超过8个，则构造红黑树（treeifyBin方法），否则还是按照链表方式存储。

　　treeifyBin方法： treeifyBin方法主要是将链式存储的冲突的数据转换成树状存储结构

　　resize方法： 注意：JDK1.8中resize方法扩容时对链表保持了原有的顺序。

　　在多线程并发环境下会有如下一种情况：

　　两个线程同时操作时同时遇到HashMap需要扩容，且映射到相同的地址（key计算得到的HashCode相同），此时在扩容时可能发生一种情况， 两个线程同时对HashMap进行扩容，扩容时做第一次循环时一个线程阻塞，另一个完成扩容，前一个继续，那么就可能发生链表数据的相互指向问题， 造成get数据时遍历的死循环

　　测试代码如下：

　　注意：我参考了大量的网上的一些博客，他们基本都是基于JDK1.6进行的分析，即：先写入数据，再扩容：

　　由此，很容易产生上述问题，而在JDK1.7中发生了变化，先扩容，再进行数据写入：

　　此时，先扩容，再写入数据，就不会产生这种问题，但是会产生另一中问题，即： HashMap中有A元素，thread1 写入B元素（碰撞），thread2写入C元素（碰撞） 线程thread1先扩容，在写入数据，同时线程thread2也进行该操作那么，最终互不影响， thread1得到：B->A链表，thread2得到：C->A链表，那么，在thread1中取数据，能否取到C元素？ 多线程并发问题依旧存在。

　　在JDK1.8中，HashMap的这块儿做了大量改进，死循环问题已经解决了：

　　但是JDK1.8 中通过测试发现依然存在JDK1.7中的数据丢失情况。

　　同时在并发情况下会出现如下新的问题： Hash碰撞情况下：前一个线程判断是链表存储，准备写入数据，但是写入时阻塞，其他线程也准备写入，发现数据链表为8，此时构造红黑树，然后完成数据转移 前一个线程此后写入数据时，就会出现类型错误：

相关测试代码（可能需要多执行几次）：

HashMap的JDK1.6、JDK1.7、JDK1.8中的实现各不相同，尤其以JDK1.8变化最大，注意区分

本文转自大数据躺过的坑博客园博客，原文链接：http://www.cnblogs.com/zlslch/p/7622756.html，如需转载请自行联系原作者