1.HashMap实现原理
2.震惊！ConcurrentHashMap里面也有死循环，作者留下的“彩蛋”了解一下？
3.HashMap为什么不安全？
4.多线程环境下,hashmap为什么会出现死循环?
5.hashmap1.7和1.8的区别

HashMap实现原理

        HashMap在实际开发中用到的频率非常高，面试中也是热点。所以决定写一篇文章进行分析，希望对想看源码的人起到一些帮助，看之前需要对链表比较熟悉。

        以下都是我自己的理解，欢迎讨论，写的不好轻喷。

        HashMap中的数据结构为散列表，又名哈希表。在这里我会对散列表进行一个简单的介绍，在此之前我们需要先回顾一下 数组、链表的优缺点。

        数组和链表的优缺点取决于他们各自在内存中存储的模式，也就是直接使用顺序存储或链式存储导致的。无论是数组还是链表，都有明显的缺点。而在实际业务中，我们想要的往往是寻址、删除、插入性能都很好的数据结构，散列表就是这样一种结构，它巧妙的结合了数组与链表的优点，并将其缺点弱化（并不是完全消除）

        散列表的做法是将key映射到数组的某个下标，存取的时候通过key获取到下标（index）然后通过下标直接存取。速度极快，而将key映射到下标需要使用散列函数，又名哈希函数。说到哈希函数可能有人已经想到了，如何将key映射到数组的下标。

        图中计算下标使用到了以下两个函数：

        值得注意的是，下标并不是通过hash函数直接得到的，计算下标还要对hash值做index()处理。

        Ps：在散列表中，数组的格子叫做桶，下标叫做桶号，桶可以包含一个key-value对，为了方便理解，后文不会使用这两个名词。

        以下是哈希碰撞相关的说明：

        以下是下标冲突相关的说明：

        很多人认为哈希值的碰撞和下标冲突是同一个东西，其实不是的，它们的正确关系是这样的，hashCode发生碰撞，则下标一定冲突；而下标冲突，hashCode并不一定碰撞

        上文提到，在jdk1.8以前HashMap的实现是散列表 = 数组 + 链表，但是到目前为止我们还没有看到链表起到的作用。事实上，HashMap引入链表的用意就是解决下标冲突。

        下图是引入链表后的散列表：

        如上图所示，左边的竖条，是一个大小为的数组，其中存储的是链表的头结点，我们知道，拥有链表的头结点即可访问整个链表，所以认为这个数组中的每个下标都存储着一个链表。其具体做法是，如果发现下标冲突，则后插入的节点以链表的形式追加到前一个节点的后面。

        这种使用链表解决冲突的方法叫做：拉链法（又叫链地址法）。HashMap使用的就是拉链法，拉链法是冲突发生以后的解决方案。

        Q：有了拉链法，就不用担心发生冲突吗？

        A：并不是！由于冲突的节点会不停的在链表上追加，大量的冲突会导致单个链表过长，使查询性能降低。所以一个好的散列表的实现应该从源头上减少冲突发生的可能性，冲突发生的概率和哈希函数返回值的均匀程度有直接关系，得到的哈希值越均匀，冲突发生的可能性越小。为了使哈希值更均匀，HashMap内部单独实现了hash()方法。

        以上是散列表的存储结构，但是在被运用到HashMap中时还有其他需要注意的地方，这里会详细说明。

        现在我们清楚了散列表的存储结构，细心的人应该已经发现了一个问题：Java中数组的长度是固定的，无论哈希函数是否均匀，随着插入到散列表中数据的增多，在数组长度不变的情况下，链表的长度会不断增加。这会导致链表查询性能不佳的缺点出现在散列表上，从而使散列表失去原本的意义。为了解决这个问题，HashMap引入了扩容与负载因子。

        以下是和扩容相关的一些概念和解释：

        Ps：扩容要重新计算下标，扩容要重新计算下标，扩容要重新计算下标，因为下标的计算和数组长度有关，长度改变，下标也应当重新计算。

        在1.8及其以上的jdk版本中，HashMap又引入了红黑树。

        红黑树的引入被用于替换链表，上文说到，如果冲突过多，会导致链表过长，降低查询性能，均匀的hash函数能有效的缓解冲突过多，但是并不能完全避免。所以HashMap加入了另一种解决方案，在往链表后追加节点时，如果发现链表长度达到8，就会将链表转为红黑树，以此提升查询的性能。

震惊！ConcurrentHashMap里面也有死循环，作者留下的“彩蛋”了解一下？

       在探讨一个近期发现的JDK 8的BUG时，我们了解到Dubbo 2.7.7版本更新点的微在乎源码描述中，涉及到了与JDK相关的修复。这个BUG实际上是位于闻名的concurrent包中的computeIfAbsent方法。在JDK 9中被修复，修复者正是Doug Lea。由于ConcurrentHashMap就是Doug Lea的杰作，这个BUG可以被视作“谁污染谁治理”。为了理解这个BUG的成因，需要先了解computeIfAbsent方法的用途。

       computeIfAbsent方法的目的是当Map中某个key对应的值不存在时，通过调用mappingFunction函数并返回该函数执行结果（非null）作为key的modbus源码详解值。如初始化一个ConcurrentHashMap，第一次获取名为why的value，若未获取到，则返回null。接着调用computeIfAbsent方法获取null后，调用getValue方法，将返回值与当前key关联起来。因此，第二次获取时能拿到"why技术"。

       了解了方法的用途，接下来揭示这个BUG。通过链接，我们看到具体的描述指向了concurrent包中的computeIfAbsent方法。这个BUG在JDK 9中被修复，修复人正是源码制作exeDoug Lea。要理解BUG，需要先了解这个方法的工作流程。在JDK 8之后，computeIfAbsent方法提供了第二个参数mappingFunction，该方法的含义是当前Map中key对应的值不存在时，调用mappingFunction函数，并将该函数的执行结果（非null）作为该key的value返回。

       通过一系列代码演示，我们发现正常情况下，Map应该显示{ AaAa=，BBBB=}，但在JDK 8环境中运行给定的测试用例时，方法不会结束，而是陷入了死循环。这就是redis源码详解BUG。

       在这个BUG被发现的过程中，提问的艺术也发挥了重要作用。Doug Lea和Pardeep在讨论中展示了提问和回答的策略。Pardeep提供的测试案例是转折点，它清晰地指出了问题所在。Doug Lea在问题提出后不久给出了回复，提出了解决问题的可能性，并且在后续的讨论中逐步明确了这个BUG的存在以及可能的解决方法。最终，这个BUG在JDK 9中得到了修复。

       这个BUG的成因在于computeIfAbsent方法内部的另一个computeIfAbsent调用，导致了两个方法在处理相同的key时进入了死循环。在处理此BUG时，我们需要深入理解computeIfAbsent方法的工作流程。从代码分析中可以看出，unity建造源码当key为"AaAa"和"BBBB"时，它们在进行计算和存储操作时，由于key的哈希值相同，导致了循环条件无法满足break的情况，从而进入了死循环。

       总结这个BUG，我们发现当key的哈希值相同时，多次调用computeIfAbsent方法会导致死循环。Doug Lea在JDK 9中通过增加判断条件，避免了这种循环情况，从而修复了这个BUG。对于使用JDK 8的开发者，可以通过将computeIfAbsent方法的使用方式调整为先调用get方法，再使用putIfAbsent方法，以此避免遇到这个BUG。此外，我们还提到了线程安全问题，即虽然ConcurrentHashMap本身是线程安全的，但在使用时仍需注意避免线程冲突，以确保程序的正确性。

HashMap为什么不安全？

       åŽŸå› ï¼š

       JDK1.7 中，由于多线程对HashMap进行扩容，调用了HashMap#transfer()，具体原因：某个线程执行过程中，被挂起，其他线程已经完成数据迁移，等CPU资源释放后被挂起的线程重新执行之前的逻辑，数据已经被改变，造成死循环、数据丢失。

       JDK1.8 中，由于多线程对HashMap进行put操作，调用了HashMap#putVal()，具体原因：假设两个线程A、B都在进行put操作，并且hash函数计算出的插入下标是相同的，当线程A执行完第六行代码后由于时间片耗尽导致被挂起，而线程B得到时间片后在该下标处插入了元素，完成了正常的插入，然后线程A获得时间片，由于之前已经进行了hash碰撞的判断，所有此时不会再进行判断，而是直接进行插入，这就导致了线程B插入的数据被线程A覆盖了，从而线程不安全。

       æ”¹å–„：

       æ•°æ®ä¸¢å¤±ã€æ­»å¾ªçŽ¯å·²ç»åœ¨åœ¨JDK1.8中已经得到了很好的解决，如果你去阅读1.8的源码会发现找不到HashMap#transfer()，因为JDK1.8直接在HashMap#resize()中完成了数据迁移。

       2、HashMap线程不安全的体现：

       JDK1.7 HashMap线程不安全体现在：死循环、数据丢失

       JDK1.8 HashMap线程不安全体现在：数据覆盖

       äºŒã€HashMap线程不安全、死循环、数据丢失、数据覆盖的原因

       1、JDK1.7 扩容引发的线程不安全

       HashMap的线程不安全主要是发生在扩容函数中，其中调用了JDK1.7 HshMap#transfer()：

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;

              }

          }

       }

       å¤åˆ¶ä»£ç 

       è¿™æ®µä»£ç æ˜¯HashMap的扩容操作，重新定位每个桶的下标，并采用头插法将元素迁移到新数组中。头插法会将链表的顺序翻转，这也是形成死循环的关键点。理解了头插法后再继续往下看是如何造成死循环以及数据丢失的。

       2、扩容造成死循环和数据丢失

       å‡è®¾çŽ°åœ¨æœ‰ä¸¤ä¸ªçº¿ç¨‹A、B同时对下面这个HashMap进行扩容操作：

       æ­£å¸¸æ‰©å®¹åŽçš„结果是下面这样的：

       ä½†æ˜¯å½“线程A执行到上面transfer函数的第行代码时，CPU时间片耗尽，线程A被挂起。即如下图中位置所示：

       æ­¤æ—¶çº¿ç¨‹A中：e=3、next=7、e.next=null

       å½“线程A的时间片耗尽后，CPU开始执行线程B，并在线程B中成功的完成了数据迁移

       é‡ç‚¹æ¥äº†ï¼Œæ ¹æ®Java内存模式可知，线程B执行完数据迁移后，此时主内存中newTable和table都是最新的，也就是说：7.next=3、3.next=null。

       éšåŽçº¿ç¨‹A获得CPU时间片继续执行newTable[i] = e，将3放入新数组对应的位置，执行完此轮循环后线程A的情况如下：

       æŽ¥ç€ç»§ç»­æ‰§è¡Œä¸‹ä¸€è½®å¾ªçŽ¯ï¼Œæ­¤æ—¶e=7，从主内存中读取e.next时发现主内存中7.next=3，此时next=3，并将7采用头插法的方式放入新数组中，并继续执行完此轮循环，结果如下：

       æ­¤æ—¶æ²¡ä»»ä½•é—®é¢˜ã€‚

       ä¸Šè½®next=3，e=3，执行下一次循环可以发现，3.next=null，所以此轮循环将会是最后一轮循环。

       æŽ¥ä¸‹æ¥å½“执行完e.next=newTable[i]即3.next=7后，3和7之间就相互连接了，当执行完newTable[i]=e后，3被头插法重新插入到链表中，执行结果如下图所示：

       ä¸Šé¢è¯´äº†æ­¤æ—¶e.next=null即next=null，当执行完e=null后，将不会进行下一轮循环。到此线程A、B的扩容操作完成，很明显当线程A执行完后，HashMap中出现了环形结构，当在以后对该HashMap进行操作时会出现死循环。

       å¹¶ä¸”从上图可以发现，元素5在扩容期间被莫名的丢失了，这就发生了数据丢失的问题。

       3、JDK1.8中的线程不安全

       ä¸Šé¢çš„扩容造成的数据丢失、死循环已经在在JDK1.8中已经得到了很好的解决，如果你去阅读1.8的源码会发现找不到HashMap#transfer()，因为JDK1.8直接在HashMap#resize()中完成了数据迁移。

       ä¸ºä»€ä¹ˆè¯´ JDK1.8会出现数据覆盖的情况？ æˆ‘们来看一下下面这段JDK1.8中的put操作代码：

       å…¶ä¸­ç¬¬å…­è¡Œä»£ç æ˜¯åˆ¤æ–­æ˜¯å¦å‡ºçŽ°hash碰撞，假设两个线程A、B都在进行put操作，并且hash函数计算出的插入下标是相同的，当线程A执行完第六行代码后由于时间片耗尽导致被挂起，而线程B得到时间片后在该下标处插入了元素，完成了正常的插入，然后线程A获得时间片，由于之前已经进行了hash碰撞的判断，所有此时不会再进行判断，而是直接进行插入，这就导致了线程B插入的数据被线程A覆盖了，从而线程不安全。

       é™¤æ­¤ä¹‹å‰ï¼Œè¿˜æœ‰å°±æ˜¯ä»£ç çš„第行处有个++size，我们这样想，还是线程A、B，这两个线程同时进行put操作时，假设当前HashMap的zise大小为，当线程A执行到第行代码时，从主内存中获得size的值为后准备进行+1操作，但是由于时间片耗尽只好让出CPU，线程B快乐的拿到CPU还是从主内存中拿到size的值进行+1操作，完成了put操作并将size=写回主内存，然后线程A再次拿到CPU并继续执行(此时size的值仍为)，当执行完put操作后，还是将size=写回内存，此时，线程A、B都执行了一次put操作，但是size的值只增加了1，所有说还是由于数据覆盖又导致了线程不安全。

       ä¸‰ã€å¦‚何使HashMap在多线程情况下进行线程安全操作？

       ä½¿ç”¨ Collections.synchronizedMap(map)，包装成同步Map，原理就是在HashMap的所有方法上synchronized。

       ä¾‹å¦‚：Collections.SynchronizedMap#get()

public V get(Object key) {

          synchronized (mutex) {

              return m.get(key);

          }

       }

       å¤åˆ¶ä»£ç 

       å››ã€æ€»ç»“

       1、HashMap线程不安全原因：

       åŽŸå› ï¼š

       JDK1.7 中，由于多线程对HashMap进行扩容，调用了HashMap#transfer()，具体原因：某个线程执行过程中，被挂起，其他线程已经完成数据迁移，等CPU资源释放后被挂起的线程重新执行之前的逻辑，数据已经被改变，造成死循环、数据丢失。

       JDK1.8 中，由于多线程对HashMap进行put操作，调用了HashMap#putVal()，具体原因：假设两个线程A、B都在进行put操作，并且hash函数计算出的插入下标是相同的，当线程A执行完第六行代码后由于时间片耗尽导致被挂起，而线程B得到时间片后在该下标处插入了元素，完成了正常的插入，然后线程A获得时间片，由于之前已经进行了hash碰撞的判断，所有此时不会再进行判断，而是直接进行插入，这就导致了线程B插入的数据被线程A覆盖了，从而线程不安全。

       æ”¹å–„：

       æ•°æ®ä¸¢å¤±ã€æ­»å¾ªçŽ¯å·²ç»åœ¨åœ¨JDK1.8中已经得到了很好的解决，如果你去阅读1.8的源码会发现找不到HashMap#transfer()，因为JDK1.8直接在HashMap#resize()中完成了数据迁移。

       2、HashMap线程不安全的体现：

       JDK1.7 HashMap线程不安全体现在：死循环、数据丢失

       JDK1.8 HashMap线程不安全体现在：数据覆盖

多线程环境下,hashmap为什么会出现死循环?

       在多线程环境下，HashMap出现死循环问题主要与JDK1.7版本的实现机制相关。当并发操作时，可能会导致闭合回路，引发CPU占用率%的问题。原因在于HashMap内部使用Entry数组存储数据。通过哈希算法获取数组索引，并在该位置插入元素。若发生冲突，则在数组位置生成链表。

       在1.7版本中，当多线程环境下进行扩容操作，可能会产生循环链表或数据丢失现象。而在1.8版本中，虽然仍然可能发生数据覆盖的情况，但通过优化，新数组中链表顺序与旧数组保持一致。

       Java8对HashMap的改进，不再在resize()方法中调用transfer()方法，而是直接在方法体内执行transfer()代码，从而避免了在多线程环境下可能引发的循环链表问题。

       针对死循环问题，解决策略主要有三个：一是使用线程安全的ConcurrentHashMap替代HashMap，这是首选方案；二是使用线程安全的容器Hashtable，但其性能较低，不推荐使用；三是通过synchronized或Lock加锁实现多线程同步操作，虽然可以避免死循环，但会显著影响性能。

       综上所述，推荐使用ConcurrentHashMap作为多线程环境下的替代方案，以避免死循环问题，提高系统稳定性与性能。

hashmap1.7和1.8的区别

       HashMap是我们开发中经常使用到的集合，jdk1.8相对于1.7底层实现发生了一些改变。1.8主要优化减少了Hash冲突 ，提高哈希表的存、取效率。

       底层数据结构不一样，1.7是数组+链表，1.8则是数组+链表+红黑树结构（当链表长度大于8，转为红黑树）。

       JDK1.8中resize()方法在表为空时，创建表；在表不为空时，扩容；而JDK1.7中resize()方法负责扩容，inflateTable()负责创建表。

       1.8中没有区分键为null的情况，而1.7版本中对于键为null的情况调用putForNullKey()方法。但是两个版本中如果键为null，那么调用hash()方法得到的都将是0，所以键为null的元素都始终位于哈希表table0中。

       当1.8中的桶中元素处于链表的情况，遍历的同时最后如果没有匹配的，直接将节点添加到链表尾部；而1.7在遍历的同时没有添加数据，而是另外调用了addEntry()方法，将节点添加到链表头部。

       1.7中新增节点采用头插法，1.8中新增节点采用尾插法。这也是为什么1.8不容易出现环型链表的原因。

       1.7中是通过更改hashSeed值修改节点的hash值从而达到rehash时的链表分散，而1.8中键的hash值不会改变，rehash时根据（hash&oldCap）==0将链表分散。

       1.8rehash时保证原链表的顺序，而1.7中rehash时有可能改变链表的顺序（头插法导致）。

       在扩容的时候：

       1.7在插入数据之前扩容，而1.8插入数据成功之后扩容。