1.concurrenthashmap1.8源码如何详细解析?扩扩容
2.为什么HashMap是线程不安全的
3.结合源码探究HashMap初始化容量问题
4.JDK成长记7：3张图搞懂HashMap底层原理！
5.HashMap实现原理

concurrenthashmap1.8源码如何详细解析?容源

       ConcurrentHashMap在JDK1.8的线程安全机制基于CAS+synchronized实现，而非早期版本的源码分段锁。

       在JDK1.7版本中，扩扩容ConcurrentHashMap采用分段锁机制，容源包含一个Segment数组，源码孕育站源码每个Segment继承自ReentrantLock，扩扩容并包含HashEntry数组，容源每个HashEntry相当于链表节点，源码用于存储key、扩扩容value。容源默认支持个线程并发，源码每个Segment独立，扩扩容互不影响。容源

       对于put流程，源码与普通HashMap相似，首先定位至特定的Segment，然后使用ReentrantLock进行操作，后续过程与HashMap基本相同。

       get流程简单，通过hash值定位至segment，再遍历链表找到对应元素。需要注意的是，value是volatile的，因此get操作无需加锁。

       在JDK1.8版本中，线程安全的关键在于优化了put流程。首先计算hash值，遍历node数组。若位置为空，则通过CAS+自旋方式初始化。

       若数组位置为空，尝试使用CAS自旋写入数据；若hash值为MOVED，表示需执行扩容操作；若满足上述条件均不成立，则使用synchronized块写入数据，同时判断链表或转换为红黑树进行插入。链表操作与HashMap相同，链表长度超过8时转换为红黑树。zbar源码案例

       get查询流程与HashMap基本一致，通过key计算位置，若table对应位置的key相同则返回结果；如为红黑树结构，则按照红黑树规则获取；否则遍历链表获取数据。

为什么HashMap是线程不安全的

       这是《Java程序员进阶之路》专栏的第篇，我们来聊聊为什么HashMap是线程不安全的。

、多线程下扩容会死循环

       众所周知，HashMap是通过拉链法来解决哈希冲突的，也就是当哈希冲突时，会将相同哈希值的键值对通过链表的形式存放起来。

       JDK7时，采用的是头部插入的方式来存放链表的，也就是下一个冲突的键值对会放在上一个键值对的前面（同一位置上的新元素被放在链表的头部）。扩容的时候就有可能导致出现环形链表，造成死循环。

       resize方法的源码：

//newCapacity为新的容量voidresize(intnewCapacity){ //小数组，临时过度下Entry[]oldTable=table;//扩容前的容量intoldCapacity=oldTable.length;//MAXIMUM_CAPACITY为最大容量，2的次方=1<<if(oldCapacity==MAXIMUM_CAPACITY){ //容量调整为Integer的最大值0x7fffffff（十六进制）=2的次方-1threshold=Integer.MAX_VALUE;return;}//初始化一个新的数组（大容量）Entry[]newTable=newEntry[newCapacity];//把小数组的元素转移到大数组中transfer(newTable,initHashSeedAsNeeded(newCapacity));//引用新的大数组table=newTable;//重新计算阈值threshold=(int)Math.min(newCapacity*loadFactor,MAXIMUM_CAPACITY+1);}

       transfer方法用来转移，将小数组的元素拷贝到新的数组中。

voidtransfer(Entry[]newTable,booleanrehash){ //新的容量intnewCapacity=newTable.length;//遍历小数组for(Entry<K,V>e:table){ while(null!=e){ //拉链法，相同key上的不同值Entry<K,V>next=e.next;//是否需要重新计算hashif(rehash){ e.hash=null==e.key?0:hash(e.key);}//根据大数组的容量，和键的hash计算元素在数组中的下标inti=indexFor(e.hash,newCapacity);//同一位置上的新元素被放在链表的头部e.next=newTable[i];//放在新的数组上newTable[i]=e;//链表上的下一个元素e=next;}}}

       注意e.next=newTable[i]和newTable[i]=e这两行代码，就会将同一位置上的新元素被放在链表的头部。

       扩容前的样子假如是下面这样子。

       那么正常扩容后就是下面这样子。

       假设现在有两个线程同时进行扩容，线程A在执行到newTable[i]=e;被挂起，此时线程A中：e=3、next=7、e.next=null

       线程B开始执行，并且完成了数据转移。

       此时，7的next为3，3的next为null。

       随后线程A获得CPU时间片继续执行newTable[i]=e，将3放入新数组对应的crf python源码位置，执行完此轮循环后线程A的情况如下：

       执行下一轮循环，此时e=7，原本线程A中7的next为5，但由于table是线程A和线程B共享的，而线程B顺利执行完后，7的next变成了3，那么此时线程A中，7的next也为3了。

       采用头部插入的方式，变成了下面这样子：

       好像也没什么问题，此时next=3，e=3。

       进行下一轮循环，但此时，由于线程B将3的next变为了null，所以此轮循环应该是最后一轮了。

       接下来当执行完e.next=newTable[i]即3.next=7后，3和7之间就相互链接了，执行完newTable[i]=e后，3被头插法重新插入到链表中，执行结果如下图所示：

       套娃开始，元素5也就成了弃婴，惨~~~

       不过，JDK8时已经修复了这个问题，扩容时会保持链表原来的顺序，参照HashMap扩容机制的这一篇。

、多线程下put会导致元素丢失

       正常情况下，当发生哈希冲突时，HashMap是这样的：

       但多线程同时执行put操作时，如果计算出来的索引位置是相同的，那会造成前一个key被后一个key覆盖，从而导致元素的丢失。

       put的源码：

finalVputVal(inthash,Kkey,Vvalue,booleanonlyIfAbsent,booleanevict){ Node<K,V>[]tab;Node<K,V>p;intn,i;//步骤①：tab为空则创建if((tab=table)==null||(n=tab.length)==0)n=(tab=resize()).length;//步骤②：计算index，并对null做处理if((p=tab[i=(n-1)&hash])==null)tab[i]=newNode(hash,key,value,null);else{ Node<K,V>e;Kk;//步骤③：节点key存在，直接覆盖valueif(p.hash==hash&&((k=p.key)==key||(key!=null&&key.equals(k))))e=p;//步骤④：判断该链为红黑树elseif(pinstanceofTreeNode)e=((TreeNode<K,V>)p).putTreeVal(this,tab,hash,key,value);//步骤⑤：该链为链表else{ for(intbinCount=0;;++binCount){ if((e=p.next)==null){ p.next=newNode(hash,key,value,null);//链表长度大于8转换为红黑树进行处理if(binCount>=TREEIFY_THRESHOLD-1)//-1for1sttreeifyBin(tab,hash);break;}//key已经存在直接覆盖valueif(e.hash==hash&&((k=e.key)==key||(key!=null&&key.equals(k))))break;p=e;}}//步骤⑥、直接覆盖if(e!=null){ //existingmappingforkeyVoldValue=e.value;if(!onlyIfAbsent||oldValue==null)e.value=value;afterNodeAccess(e);returnoldValue;}}++modCount;//步骤⑦：超过最大容量就扩容if(++size>threshold)resize();afterNodeInsertion(evict);returnnull;}

       问题发生在步骤②这里：

if((p=tab[i=(n-1)&hash])==null)tab[i]=newNode(hash,geoserver源码编译key,value,null);

       两个线程都执行了if语句，假设线程A先执行了tab[i]=newNode(hash,key,value,null)，那table是这样的：

       接着，线程B执行了tab[i]=newNode(hash,key,value,null)，那table是这样的：

       3被干掉了。

、put和get并发时会导致get到null

       线程A执行put时，因为元素个数超出阈值而出现扩容，线程B此时执行get，有可能导致这个问题。

       注意来看resize源码：

finalNode<K,V>[]resize(){ Node<K,V>[]oldTab=table;intoldCap=(oldTab==null)?0:oldTab.length;intoldThr=threshold;intnewCap,newThr=0;if(oldCap>0){ //超过最大值就不再扩充了，就只好随你碰撞去吧if(oldCap>=MAXIMUM_CAPACITY){ threshold=Integer.MAX_VALUE;returnoldTab;}//没超过最大值，就扩充为原来的2倍elseif((newCap=oldCap<<1)<MAXIMUM_CAPACITY&&oldCap>=DEFAULT_INITIAL_CAPACITY)newThr=oldThr<<1;//doublethreshold}elseif(oldThr>0)//initialcapacitywasplacedinthresholdnewCap=oldThr;else{ //zeroinitialthresholdsignifiesusingdefaultsnewCap=DEFAULT_INITIAL_CAPACITY;newThr=(int)(DEFAULT_LOAD_FACTOR*DEFAULT_INITIAL_CAPACITY);}//计算新的resize上限if(newThr==0){ floatft=(float)newCap*loadFactor;newThr=(newCap<MAXIMUM_CAPACITY&&ft<(float)MAXIMUM_CAPACITY?(int)ft:Integer.MAX_VALUE);}threshold=newThr;@SuppressWarnings({ "rawtypes","unchecked"})Node<K,V>[]newTab=(Node<K,V>[])newNode[newCap];table=newTab;}

       线程A执行完table=newTab之后，线程B中的table此时也发生了变化，此时去get的时候当然会get到null了，因为元素还没有转移。

       为了便于大家更系统化地学习Java，二哥已经将《Java程序员进阶之路》专栏开源到GitHub上了，大家只需轻轻地star一下，就可以和所有的小伙伴一起打怪升级了。

       GitHub地址：/itwanger/toBeBetterJavaer

结合源码探究HashMap初始化容量问题

       探究HashMap初始化容量问题

       在深入研究HashMap源码时，有一个问题引人深思：为何在知道需要存储n个键值对时，我们通常会选择初始化容量为capacity = n / 0. + 1？

       本文旨在解答这一疑惑，适合具备一定HashMap基础知识的读者。请在阅读前，思考以下问题：

       让我们通过解答这些问题，逐步展开对HashMap初始化容量的深入探讨。

       源码探究

       让我们从实际代码出发，通过debug逐步解析HashMap的初始化逻辑。

       举例：初始化一个容量为9的HashMap。

       执行代码后，我们发现初始化容量为，且阈值threshold设置为。

       解析

       通过debug，我们首先关注到构造方法中的初始化逻辑。注意到，初始化阈值时，实际调用的jquery prop源码是`tabliSizeFor(int n)`方法，它返回第一个大于等于n的2的幂。例如，`tabliSizeFor(9)`返回，`tabliSizeFor()`返回，`tabliSizeFor(8)`返回8。

       继续解析

       在构造方法结束后，我们通过debug继续追踪至`put`方法，直至`putVal`方法。

       在`putVal`方法中，我们发现当第一次调用`put`时，table为null，从而触发初始化逻辑。在初始化过程中，关键在于`resize()`方法中对新容量`newCap`的初始化，即等于构造方法中设置的阈值`threshold`()。

       阈值更新

       在初始化后，我们进一步关注`updateNewThr`的代码逻辑，发现新的阈值被更新为新容量乘以负载因子，即 * 0.。

       案例分析

       举例：初始化一个容量为8的HashMap。

       解答：答案是8，因为`tableSizeFor`方法返回大于等于参数的2的幂，而非严格大于。

       扩容问题

       举例：当初始化容量为时，放入9个不同的entry是否会引发扩容。

       解答：不会，因为扩容条件与阈值有关，当map中存储的键值对数量大于阈值时才触发扩容。根据第一问，初始化容量是，阈值为 * 0. = 9，我们只放了9个，因此不会引起扩容。

       容量选择

       举例：已知需要存储个键值对，如何选择合适的初始化容量。

       解答：初始化容量的目的是减少扩容次数以提高效率并节省空间。选择容量时，应考虑既能防止频繁扩容又能充分利用空间。具体选择取决于实际需求和预期键值对的数量。

       总结

       通过本文的探讨，我们深入了解了HashMap初始化容量背后的逻辑和原因。希望这些解析能够帮助您更深入地理解HashMap的内部工作原理。如果您对此有任何疑问或不同的见解，欢迎在评论区讨论。

       最后，如有帮助，欢迎点赞分享。

JDK成长记7：3张图搞懂HashMap底层原理！

       一句话讲， HashMap底层数据结构，JDK1.7数组+单向链表、JDK1.8数组+单向链表+红黑树。

       在看过了ArrayList、LinkedList的底层源码后，相信你对阅读JDK源码已经轻车熟路了。除了List很多时候你使用最多的还有Map和Set。接下来我将用三张图和你一起来探索下HashMap的底层核心原理到底有哪些？

       首先你应该知道HashMap的核心方法之一就是put。我们带着如下几个问题来看下图：

       如上图所示，put方法调用了putVal方法，之后主要脉络是：

       如何计算hash值？

       计算hash值的算法就在第一步，对key值进行hashCode()后，对hashCode的值进行无符号右移位和hashCode值进行了异或操作。为什么这么做呢？其实涉及了很多数学知识，简单的说就是尽可能让高和低位参与运算，可以减少hash值的冲突。

       默认容量和扩容阈值是多少？

       如上图所示，很明显第二步回调用resize方法，获取到默认容量为，这个在源码里是1<<4得到的，1左移4位得到的。之后由于默认扩容因子是0.，所以两者相乘就是扩容大小阈值*0.=。之后就分配了一个大小为的Node[]数组，作为Key-Value对存放的数据结构。

       最后一问题是，如何进行hash寻址的？

       hash寻址其实就在数组中找一个位置的意思。用的算法其实也很简单，就是用数组大小和hash值进行n-1&hash运算，这个操作和对hash取模很类似，只不过这样效率更高而已。hash寻址后，就得到了一个位置，可以把key-value的Node元素放入到之前创建好的Node[]数组中了。

       当你了解了上面的三个原理后，你还需要掌握如下几个问题:

       还是老规矩，看如下图：

       当hash值计算一致，比如当hash值都是时，Key-Value对的Node节点还有一个next指针，会以单链表的形式，将冲突的节点挂在数组同样位置。这就是数据结构中所提到解决hash 的冲突方法之一：单链法。当然还有探测法+rehash法有兴趣的人可以回顾《数据结构和算法》相关书籍。

       但是当hash冲突严重的时候，单链法会造成原理链接过长，导致HashMap性能下降，因为链表需要逐个遍历性能很差。所以JDK1.8对hash冲突的算法进行了优化。当链表节点数达到8个的时候，会自动转换为红黑树，自平衡的一种二叉树，有很多特点，比如区分红和黑节点等，具体大家可以看小灰算法图解。红黑树的遍历效率是O(logn)肯定比单链表的O(n)要好很多。

       总结一句话就是，hash冲突使用单链表法+红黑树来解决的。

       上面的图，核心脉络是四步，源码具体的就不粘出来了。当put一个之后，map的size达到扩容阈值，就会触发rehash。你可以看到如下具体思路：

       情况1:如果数组位置只有一个值：使用新的容量进行rehash，即e.hash & (newCap - 1)

       情况2:如果数组位置有链表，根据 e.hash & oldCap == 0进行判断，结果为0的使用原位置，否则使用index + oldCap位置,放入元素形成新链表，这里不会和情况1新的容量进行rehash与运算了，index + oldCap这样更省性能。

       情况3：如果数组位置有红黑树，根据split方法，同样根据 e.hash & oldCap == 0进行树节点个数统计，如果个数小于6，将树的结果恢复为普通Node，否则使用index + oldCap，调整红黑树位置，这里不会和新的容量进行rehash与运算了，index + oldCap这样更省性能。

       你有兴趣的话，可以分别画一下这三种情况的图。这里给大家一个图，假设都出发了以上三种情况结果如下所示：

       上面源码核心脉络，3个if主要是校验了一堆，没做什么事情，之后赋值了扩容因子，不传递使用默认值0.，扩容阈值threshold通过tableSizeFor(initialCapacity);进行计算。注意这里只是计算了扩容阈值，没有初始化数组。代码如下：

       竟然不是大小*扩容因子？

       n |= n >>> 1这句话，是在干什么？n |= n >>> 1等价于n = n | n >>>1; 而|表示位运算中的或，n>>>1表示无符号右移1位。遇到这种情况，之前你应该学到了，如果碰见复杂逻辑和算法方法就是画图或者举例子。这里你就可以举个例子：假设现在指定的容量大小是,n=cap-1=，那么计算过程应该如下：

       n是int类型，java中一般是4个字节，位。所以的二进制： 。

       最后n+1=，方法返回，赋值给threshold=。再次注意这里只是计算了扩容阈值，没有初始化数组。

       为什么这么做呢？一句话，为了提高hash寻址和扩容计算的的效率。

       因为无论扩容计算还是寻址计算，都是二进制的位运算，效率很快。另外之前你还记得取余(%)操作中如果除数是2的幂次方则等同于与其除数减一的与(&)操作。即 hash%size = hash & (size-1)。这个前提条件是除数是2的幂次方。

       你可以再回顾下resize代码，看看指定了map容量，第一次put会发生什么。会将扩容阈值threshold，这样在第一次put的时候就会调用newCap = oldThr;使得创建一个容量为threshold的数组，之后从而会计算新的扩容阈值newThr为newCap*0.=*0.=。也就是说map到了个元素就会进行扩容。

       除了今天知识，技能的成长，给大家带来一个金句甜点，结束我今天的分享：坚持的三个秘诀之一目标化。

       坚持的秘诀除了上一节提到的视觉化，第二个秘诀就是目标化。顾名思义，就是需要给自己定立一个目标。这里要提到的是你的目标不要定的太高了。就比如你想要增加肌肉，给自己定了一个目标，每天5组，每次个俯卧撑，你看到自己胖的身形或者海报，很有刺激，结果开始前两天非常厉害，干劲十足，特别奥利给。但是第三天，你想到要个俯卧撑，你就不想起床，就算起来，可能也会把自己撅死过去......其实你的目标不要一下子定的太大，要从微习惯开始，比如我媳妇从来没有做过俯卧撑，就让她每天从1个开始,不能多，我就怕她收不住，做多了。一开始其实从习惯开始，先变成习惯，再开始慢慢加量。量太大养不成习惯，量小才能养成习惯。很容易做到才能养成，你想想是不是这个道理？

       所以，坚持的第二个秘诀就是定一个目标，可以通过小量目标，养成微习惯。比如每天你可以读五分钟书或者5分钟成长记，不要多，我想超过你也会睡着了的.....

       最后，大家可以在阅读完源码后，在茶余饭后的时候问问同事或同学，你也可以分享下，讲给他听听。

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，就会将链表转为红黑树，以此提升查询的性能。