1.高并发编程-CountDownLatch深入解析
2.深入理解Linux的高高并epoll机制
3.ConcurrentHashMap源码解析（超级详细版本）

高并发编程-CountDownLatch深入解析

       CountDownLatch是一个用于在多线程环境中实现同步和等待的工具类，它允许一个或者多个线程一直等待，框架直到一组其他操作执行完成。源码在使用CountDownLatch时，发框首先需要指定一个整数值，架设计这表示线程将要等待的高高并库存管理access源码操作数。当某个线程等待执行这些操作时，框架需要调用`await`方法。源码这个方法会让线程进入休眠状态，发框直到所有等待的架设计操作完成为止。操作完成后，高高并需要通过`countDown`方法减少CountDownLatch类的框架内部计数器。当内部计数器递减为0时，源码CountDownLatch会唤醒所有调用`await`方法而休眠的发框线程。

       下面是架设计一个简单的代码示例，演示了CountDownLatch的基本使用。假设我们有一个场景，5位运动员参加跑步比赛，发令枪响起后，5个计时器开始分别计时，直到所有运动员都到达终点。具体代码如下：

       java

       // 输出结果示例，由于HTML格式限制，此代码将无法直接执行，仅提供概念示例

       代码演示了CountDownLatch的简单使用场景，展示了线程等待和唤醒机制。

       接下来，我们深入分析CountDownLatch的核心方法：

       构造方法 `CountDownLatch(int count)`：根据给定的`count`参数构建CountDownLatch实例，内部创建了一个Sync实例。Sync是CountDownLatch的一个内部类，其构造方法用于初始化内部计数器。

       `await()` 方法：当该方法被调用时，当前线程会阻塞，直到内部计数器的值等于零或当前线程被中断。

       `countDown()` 方法：内部计数器减一，如果计数达到零，则唤醒所有等待的线程。

       进一步，让我们分析CountDownLatch的源码实现，特别是构造方法和核心方法的实现细节。从类图开始，我们可以看到CountDownLatch内部的Sync类继承了AbstractQueuedSynchronizer，这是Java并发框架中的基础类。通过构造方法、`await`和`countDown`方法的具体实现，我们可以深入了解CountDownLatch的工作原理。

       使用CountDownLatch时，通常将它与线程池、异步操作结合使用。例如，在实际工作中，如果需要在客户端执行一个同步请求查询用户的风险等级，而服务端则需要请求多个子系统获取数据，可以使用CountDownLatch。通过并发请求多个子系统并使用CountDownLatch在获取所有子系统数据后再进行风险评估，可以显著减少处理时间。

       在面试中，可能会遇到关于CountDownLatch和CyclicBarrier的比较问题。两者都是用于线程间等待的工具，但侧重点不同。CountDownLatch主要用于等待一组其他线程的操作完成，而CyclicBarrier则是一组线程间的等待至某同步点。此外，CyclicBarrier的计数器可以重复使用，而CountDownLatch的计数器则不能。

深入理解Linux的epoll机制

       在Linux系统之中有一个核心武器：epoll池，在高并发的login.html 模板源码，高吞吐的IO系统中常常见到epoll的身影。

IO多路复用

       在Go里最核心的是Goroutine，也就是所谓的协程，协程最妙的一个实现就是异步的代码长的跟同步代码一样。比如在Go中，网络IO的read，write看似都是同步代码，其实底下都是异步调用，一般流程是：

write(/*IO参数*/)请求入队等待完成后台loop程序发送网络请求唤醒业务方

       Go配合协程在网络IO上实现了异步流程的同步代码化。核心就是用epoll池来管理网络fd。

       实现形式上，后台的程序只需要1个就可以负责管理多个fd句柄，负责应对所有的业务方的IO请求。这种一对多的IO模式我们就叫做IO多路复用。

       多路是指？多个业务方（句柄）并发下来的IO。

       复用是指？复用这一个后台处理程序。

       站在IO系统设计人员的角度，业务方咱们没办法提要求，因为业务是上帝，只有你服从的份，他们要创建多个fd，那么你就需要负责这些fd的处理，并且最好还要并发起来。

       业务方没法提要求，那么只能要求后台loop程序了！

       要求什么呢？快！快！快！这就是最核心的要求，处理一定要快，要给每一个fd通道最快的感受，要让每一个fd觉得，你只在给他一个人跑腿。

       那有人又问了，那我一个IO请求（比如write）对应一个线程来处理，这样所有的IO不都并发了吗？是可以，但是有瓶颈，线程数一旦多了，性能是反倒会差的。

       这里不再对比多线程和IO多路复用实现高并发之间的区别，详细的可以去了解下nginx和redis高并发的秘密。

最朴实的实现方式？

       我不用任何其他系统调用，能否实现IO多路复用？

       可以的。那么写个for循环，每次都尝试IO一下，读/写到了就处理，读/写不到就sleep下。这样我们不就实现了1对多的IO多路复用嘛。

whileTrue:foreach句柄数组{ read/write(fd,/*参数*/)}sleep(1s)

       慢着，有个问题，上面的程序可能会被卡死在第三行，使得整个系统不得运行，为什么？

       默认情况下，我们没有加任何参数create出的句柄是阻塞类型的。我们读数据的时候，如果数据还没准备好，是会需要等待的，当我们写数据的时候，如果还没准备好，默认也会卡住等待。所以，在上面伪代码第三行是可能被直接卡死，而导致整个线程都得到不到运行。

       举个例子，现在有，，乐彩娱乐系统源码这3个句柄，现在读写都没有准备好，只要read/write(,/*参数*/)就会被卡住，但，这两个句柄都准备好了，那遍历句柄数组，，的时候就会卡死在前面，后面，则得不到运行。这不符合我们的预期，因为我们IO多路复用的loop线程是公共服务，不能因为一个fd就直接瘫痪。

       那这个问题怎么解决？

       只需要把fd都设置成非阻塞模式。这样read/write的时候，如果数据没准备好，返回EAGIN的错误即可，不会卡住线程，从而整个系统就运转起来了。比如上面句柄还未就绪，那么read/write(,/*参数*/)不会阻塞，只会报个EAGIN的错误，这种错误需要特殊处理，然后loop线程可以继续执行，的读写。

       以上就是最朴实的IO多路复用的实现了。但是好像在生产环境没见过这种IO多路复用的实现？为什么？

       因为还不够高级。for循环每次要定期sleep1s，这个会导致吞吐能力极差，因为很可能在刚好要sleep的时候，所有的fd都准备好IO数据，而这个时候却要硬生生的等待1s，可想而知。。。

       那有同学又要质疑了，那for循环里面就不sleep嘛，这样不就能及时处理了吗？

       及时是及时了，但是CPU估计要跑飞了。不加sleep，那在没有fd需要处理的时候，估计CPU都要跑到%了。这个也是无法接受的。

       纠结了，那sleep吞吐不行，不sleep浪费cpu，怎么办？

       这种情况用户态很难有所作为，只能求助内核来提供机制协助来。因为内核才能及时的管理这些通知和调度。

       我们再梳理下IO多路复用的需求和原理。IO多路复用就是1个线程处理多个fd的模式。我们的要求是：这个“1”就要尽可能的快，避免一切无效工作，要把所有的时间都用在处理句柄的IO上，不能有任何空转，sleep的时间浪费。

       有没有一种工具，我们把一箩筐的fd放到里面，只要有一个fd能够读写数据，后台loop线程就要立马唤醒，全部马力跑起来。其他时间要把cpu让出去。

       能做到吗？能，这种需求只能内核提供机制满足你。

这事Linux内核必须要给个说法？

       是的，想要不用sleep这种辣眼睛的微信登录接口源码实现，Linux内核必须出手了，毕竟IO的处理都是内核之中，数据好没好内核最清楚。

       内核一口气提供了3种工具select，poll，epoll。

       为什么有3种？

       历史不断改进，矬->较矬->卧槽、高效的演变而已。

       Linux还有其他方式可以实现IO多路复用吗？

       好像没有了！

       这3种到底是做啥的？

       这3种都能够管理fd的可读可写事件，在所有fd不可读不可写无所事事的时候，可以阻塞线程，切走cpu。fd有情况的时候，都要线程能够要能被唤醒。

       而这三种方式以epoll池的效率最高。为什么效率最高？

       其实很简单，这里不详说，其实无非就是epoll做的无用功最少，select和poll或多或少都要多余的拷贝，盲猜（遍历才知道）fd，所以效率自然就低了。

       举个例子，以select和epoll来对比举例，池子里管理了个句柄，loop线程被唤醒的时候，select都是蒙的，都不知道这个fd里谁IO准备好了。这种情况怎么办？只能遍历这个fd，一个个测试。假如只有一个句柄准备好了，那相当于做了1千多倍的无效功。

       epoll则不同，从epoll_wait醒来的时候就能精确的拿到就绪的fd数组，不需要任何测试，拿到的就是要处理的。

epoll池原理

       下面我们看一下epoll池的使用和原理。

epoll涉及的系统调用

       epoll的使用非常简单，只有下面3个系统调用。

epoll_createepollctlepollwait

       就这？是的，就这么简单。

       epollcreate负责创建一个池子，一个监控和管理句柄fd的池子；

       epollctl负责管理这个池子里的fd增、删、改；

       epollwait就是负责打盹的，让出CPU调度，但是只要有“事”，立马会从这里唤醒；

epoll高效的原理

       Linux下，epoll一直被吹爆，作为高并发IO实现的秘密武器。其中原理其实非常朴实：epoll的实现几乎没有做任何无效功。我们从使用的角度切入来一步步分析下。

       首先，epoll的第一步是创建一个池子。这个使用epoll_create来做：

       原型：

intepoll_create(intsize);

       示例：

epollfd=epoll_create();if(epollfd==-1){ perror("epoll_create");exit(EXIT_FAILURE);}

       这个池子对我们来说是黑盒，这个黑盒是用来装fd的，我们暂不纠结其中细节。我们拿到了一个epollfd，这个epollfd就能唯一代表这个epoll池。

       然后，我们就要往这个epoll池里放fd了，这就要用到epoll_ctl了

       原型：

intepoll_ctl(intepfd,intop,intfd,structepoll_event*event);

       示例：

if(epoll_ctl(epollfd,EPOLL_CTL_ADD,,&ev)==-1){ perror("epoll_ctl:listen_sock");exit(EXIT_FAILURE);}

       上面，我们就把句柄放到这个池子里了，op（EPOLL_CTL_ADD）表明操作是增加、修改、熊猫烧香图片源码删除，event结构体可以指定监听事件类型，可读、可写。

       第一个跟高效相关的问题来了，添加fd进池子也就算了，如果是修改、删除呢？怎么做到时间快？

       这里就涉及到你怎么管理fd的数据结构了。

       最常见的思路：用list，可以吗？功能上可以，但是性能上拉垮。list的结构来管理元素，时间复杂度都太高O(n)，每次要一次次遍历链表才能找到位置。池子越大，性能会越慢。

       那有简单高效的数据结构吗？

       有，红黑树。Linux内核对于epoll池的内部实现就是用红黑树的结构体来管理这些注册进程来的句柄fd。红黑树是一种平衡二叉树，时间复杂度为O(logn)，就算这个池子就算不断的增删改，也能保持非常稳定的查找性能。

       现在思考第二个高效的秘密：怎么才能保证数据准备好之后，立马感知呢？

       epoll_ctl这里会涉及到一点。秘密就是：回调的设置。在epoll_ctl的内部实现中，除了把句柄结构用红黑树管理，另一个核心步骤就是设置poll回调。

       思考来了：poll回调是什么？怎么设置？

       先说说file_operations->poll是什么？

       在fd篇说过，Linux设计成一切皆是文件的架构，这个不是说说而已，而是随处可见。实现一个文件系统的时候，就要实现这个文件调用，这个结构体用structfile_operations来表示。这个结构体有非常多的函数，我精简了一些，如下：

structfile_operations{ ssize_t(*read)(structfile*,char__user*,size_t,loff_t*);ssize_t(*write)(structfile*,constchar__user*,size_t,loff_t*);__poll_t(*poll)(structfile*,structpoll_table_struct*);int(*open)(structinode*,structfile*);int(*fsync)(structfile*,loff_t,loff_t,intdatasync);//....};

       你看到了read，write，open，fsync，poll等等，这些都是对文件的定制处理操作，对于文件的操作其实都是在这个框架内实现逻辑而已，比如ext2如果有对read/write做定制化，那么就会是ext2_read，ext2_write，ext4就会是ext4_read，ext4_write。在open具体“文件”的时候会赋值对应文件系统的file_operations给到file结构体。

       那我们很容易知道read是文件系统定制fd读的行为调用，write是文件系统定制fd写的行为调用，file_operations->poll呢？

       这个是定制监听事件的机制实现。通过poll机制让上层能直接告诉底层，我这个fd一旦读写就绪了，请底层硬件（比如网卡）回调的时候自动把这个fd相关的结构体放到指定队列中，并且唤醒操作系统。

       举个例子：网卡收发包其实走的异步流程，操作系统把数据丢到一个指定地点，网卡不断的从这个指定地点掏数据处理。请求响应通过中断回调来处理，中断一般拆分成两部分：硬中断和软中断。poll函数就是把这个软中断回来的路上再加点料，只要读写事件触发的时候，就会立马通知到上层，采用这种事件通知的形式就能把浪费的时间窗就完全消失了。

       划重点：这个poll事件回调机制则是epoll池高效最核心原理。

       划重点：epoll池管理的句柄只能是支持了file_operations->poll的文件fd。换句话说，如果一个“文件”所在的文件系统没有实现poll接口，那么就用不了epoll机制。

       第二个问题：poll怎么设置？

       在epoll_ctl下来的实现中，有一步是调用vfs_poll这个里面就会有个判断，如果fd所在的文件系统的file_operations实现了poll，那么就会直接调用，如果没有，那么就会报告响应的错误码。

staticinline__poll_tvfs_poll(structfile*file,structpoll_table_struct*pt){ if(unlikely(!file->f_op->poll))returnDEFAULT_POLLMASK;returnfile->f_op->poll(file,pt);}

       你肯定好奇poll调用里面究竟是实现了什么？

       总结概括来说：挂了个钩子，设置了唤醒的回调路径。epoll跟底层对接的回调函数是：ep_poll_callback，这个函数其实很简单，做两件事情：

       把事件就绪的fd对应的结构体放到一个特定的队列（就绪队列，readylist）；

       唤醒epoll，活来啦！

       当fd满足可读可写的时候就会经过层层回调，最终调用到这个回调函数，把对应fd的结构体放入就绪队列中，从而把epoll从epoll_wait出唤醒。

       这个对应结构体是什么？

       结构体叫做epitem，每个注册到epoll池的fd都会对应一个。

       就绪队列很高级吗？

       就绪队列就简单了，因为没有查找的需求了呀，只要是在就绪队列中的epitem，都是事件就绪的，必须处理的。所以就绪队列就是一个最简单的双指针链表。

       小结下：epoll之所以做到了高效，最关键的两点：

       内部管理fd使用了高效的红黑树结构管理，做到了增删改之后性能的优化和平衡；

       epoll池添加fd的时候，调用file_operations->poll，把这个fd就绪之后的回调路径安排好。通过事件通知的形式，做到最高效的运行；

       epoll池核心的两个数据结构：红黑树和就绪列表。红黑树是为了应对用户的增删改需求，就绪列表是fd事件就绪之后放置的特殊地点，epoll池只需要遍历这个就绪链表，就能给用户返回所有已经就绪的fd数组；

哪些fd可以用epoll来管理？

       再来思考另外一个问题：由于并不是所有的fd对应的文件系统都实现了poll接口，所以自然并不是所有的fd都可以放进epoll池，那么有哪些文件系统的file_operations实现了poll接口？

       首先说，类似ext2，ext4，xfs这种常规的文件系统是没有实现的，换句话说，这些你最常见的、真的是文件的文件系统反倒是用不了epoll机制的。

       那谁支持呢？

       最常见的就是网络套接字：socket。网络也是epoll池最常见的应用地点。Linux下万物皆文件，socket实现了一套socket_file_operations的逻辑（net/socket.c）：

staticconststructfile_operationssocket_file_ops={ .read_iter=sock_read_iter,.write_iter=sock_write_iter,.poll=sock_poll,//...};

       我们看到socket实现了poll调用，所以socketfd是天然可以放到epoll池管理的。

       还有吗？

       有的，其实Linux下还有两个很典型的fd，常常也会放到epoll池里。

       eventfd：eventfd实现非常简单，故名思义就是专门用来做事件通知用的。使用系统调用eventfd创建，这种文件fd无法传输数据，只用来传输事件，常常用于生产消费者模式的事件实现；

       timerfd：这是一种定时器fd，使用timerfd_create创建，到时间点触发可读事件；

       小结一下：

       ext2，ext4，xfs等这种真正的文件系统的fd，无法使用epoll管理；

       socketfd，eventfd，timerfd这些实现了poll调用的可以放到epoll池进行管理；

       其实，在Linux的模块划分中，eventfd，timerfd，epoll池都是文件系统的一种模块实现。

思考

       前面我们已经思考了很多知识点，有一些简单有趣的知识点，提示给读者朋友，这里只抛砖引玉。

       问题：单核CPU能实现并行吗？

       不行。

       问题：单线程能实现高并发吗？

       可以。

       问题：那并发和并行的区别是？

       一个看的是时间段内的执行情况，一个看的是时间时刻的执行情况。

       问题：单线程如何做到高并发？

       IO多路复用呗，今天讲的epoll池就是了。

       问题：单线程实现并发的有开源的例子吗？

       redis，nginx都是非常好的学习例子。当然还有我们Golang的runtime实现也尽显高并发的设计思想。

总结

       IO多路复用的原始实现很简单，就是一个1对多的服务模式，一个loop对应处理多个fd；

       IO多路复用想要做到真正的高效，必须要内核机制提供。因为IO的处理和完成是在内核，如果内核不帮忙，用户态的程序根本无法精确的抓到处理时机；

       fd记得要设置成非阻塞的哦，切记；

       epoll池通过高效的内部管理结构，并且结合操作系统提供的poll事件注册机制，实现了高效的fd事件管理，为高并发的IO处理提供了前提条件；

       epoll全名eventpoll，在Linux内核下以一个文件系统模块的形式实现，所以有人常说epoll其实本身就是文件系统也是对的；

       socketfd，eventfd，timerfd这三种”文件“fd实现了poll接口，所以网络fd，事件fd，定时器fd都可以使用epoll_ctl注册到池子里。我们最常见的就是网络fd的多路复用；

       ext2，ext4，xfs这种真正意义的文件系统反倒没有提供poll接口实现，所以不能用epoll池来管理其句柄。那文件就无法使用epoll机制了吗？不是的，有一个库叫做libaio，通过这个库我们可以间接的让文件使用epoll通知事件，以后详说，此处不表；

后记

       epoll池使用很简洁，但实现不简单。还是那句话，Linux内核帮你包圆了。

       今天并没有罗列源码实现，以很小的思考点为题展开，简单讲了一些epoll的思考，以后有机会可以分享下异步IO（aio）和epoll能产生什么火花？Golang是怎样使用epoll池的？敬请期待哦。

       原创不易，更多干货，关注：奇伢云存储

ConcurrentHashMap源码解析（超级详细版本）

       concurrentHashMap概述

       concurrentHashMap是HashMap的线程安全版本，是juc包中提供的。利用volatile关键字和cas还有synchronized关键字对hashMap进行改造，使其变为线程安全的。其很多特性和hashMap是一样的，hashMap的源码可以去看我之前的博客：/article/.html

       但是与hashMap区别不只是线程安全方面，还有就是concurrentHashMap不允许key和value为空，这点在后面源码解析也可以看到，本文章主要分析JDK1.8及之后的版本，1.7之前的版本会提一点，不会对源码进行详细的解析。

数据结构图解

       自我感觉学一个东西首先要了解他的架构图，包括框架，这样我们可以有一个整体的框架，学习起来也会更轻松。接下来我们来看concurrentHashMap的数据结构图，下面两张是从别人博客里面摘的（ps：感觉很多博客都是这两张图，就不注明出处了，我：拿来吧你0.0）

       1.8：

       1.7：

       如图，1.8版本之后，concurrentHashMap和hashMap数据结构基本是一致的，唯一的区别就是concurrentHashMap是在操作链表或者红黑树时对node数组中的每一个链表或红黑树加锁，其他时候利用cas来保证线程同步。并且利用volatile关键字，保证了table数组、标索引等的可见性，结合cas，在不加锁的情况下保证线程同步，相较于1.7，还引入了红黑树，极大的优化了速度。

       1.7版本之前，concurrentHashMap是利用分段锁，将entry数组分为多个segment数组，然后当我们插入数据时对segment加锁，相较于hashTable的全部加锁速度快了不少，并且能够至此一定的并发操作，但是速度方面还是不够优秀。

源码解析1.GET方法

       get方法比较简单，相对于put方法，只需要我们通过valotile关键字保证可见性就可以了，所以和hashMap差别不大

       在读这get源码之前，我们需要知道一个方法，这个方法在put中也被用到，我们需要理解他是干什么的:

staticfinal<K,V>Node<K,V>tabAt(Node<K,V>[]tab,inti){ return(Node<K,V>)U.getObjectVolatile(tab,((long)i<<ASHIFT)+ABASE);}

       这段代码主要是用来取table数组中的对应下标的元素的，可以看到调用了一个getObjectVolatile()方法,这个方法是Usafe类提供的一个方法，这个类提供了一些原子操作，是通过我们的本地方法实现的，也就是调用了C++代码

       然后是spread()方法，可以看到这个和我们hashmap中的hash()方法是一样的，只是和HASH_BITS进行了一次与运算，这个是用来使最高位为0，保证我们的哈希值为正数，代表是一个链表，若为1则为负数，代表一个红黑树，这个后面判断红黑树的时候会用到。

staticfinalintHASH_BITS=0x7fffffff;//usablebitsofnormalnodehashstaticfinalintspread(inth){ return(h^(h>>>))&HASH_BITS;}

       然后我们来看get的源码：

publicVget(Objectkey){ Node<K,V>[]tab;Node<K,V>e,p;intn,eh;Kek;inth=spread(key.hashCode());if((tab=table)!=null&&(n=tab.length)>0&&(e=tabAt(tab,(n-1)&h))!=null){ if((eh=e.hash)==h){ if((ek=e.key)==key||(ek!=null&&key.equals(ek)))returne.val;}elseif(eh<0)return(p=e.find(h,key))!=null?p.val:null;while((e=e.next)!=null){ if(e.hash==h&&((ek=e.key)==key||(ek!=null&&key.equals(ek))))returne.val;}}returnnull;}

       首先我们通过spread()方法计算出传入的key的hash值，如果table不为空并且(n-1)&h对应位置的节点不为空（n是table数组长度），

       那么就先判断对应位置根节点的hash值是否等于我们计算出的key值的hash值，如果相等就直接返回根节点的val值，否则就进行下一步

       若根接节点的hash值小于0，若小于0代表为红黑树，那么就采用红黑树的方式向下查找，找到有相同的值就返回，否则返回null。

       若接节点的hash值大于等于0，遍历node链表向下找，同样找到就返回值，否则返回null。

       到此，get方法结束。

2.PUT方法

       put方法相对就比较麻烦了，代码如下：

publicVput(Kkey,Vvalue){ returnputVal(key,value,false);}

       这里调用了putVal()方法，哪个false参数是代表当put的值重复时要不要替换，false代表要替换。然后我们看putVal()方法：

finalVputVal(Kkey,Vvalue,booleanonlyIfAbsent){ //判断key和value是否为空，为空直接抛出空指针异常if(key==null||value==null)thrownewNullPointerException();//计算hash值，和put方法中一致inthash=spread(key.hashCode());//用于记录链表长度intbinCount=0;for(Node<K,V>[]tab=table;;){ Node<K,V>f;intn,i,fh;//如果table未初始化，就先初始化tableif(tab==null||(n=tab.length)==0)tab=initTable();//如果要插入的table数组下标位置为空，则直接利用cas插入一个node即可elseif((f=tabAt(tab,i=(n-1)&hash))==null){ if(casTabAt(tab,i,null,newNode<K,V>(hash,key,value,null)))break;//nolockwhenaddingtoemptybin}//如果table数组正在扩容，那么就需要当前线程帮助其扩容elseif((fh=f.hash)==MOVED)tab=helpTransfer(tab,f);//如果下标位置有节点，并且没有在扩容else{ //记录要被替换的老数据VoldVal=null;//对table数组对应下表位置的根节点加锁synchronized(f){ if(tabAt(tab,i)==f){ //如果根节点hash大于等于0，代表为链表if(fh>=0){ binCount=1;//对链表进行遍历，binCount记录链表长度for(Node<K,V>e=f;;++binCount){ Kek;//如果有相同的节点if(e.hash==hash&&((ek=e.key)==key||(ek!=null&&key.equals(ek)))){ //将老数据进行保存oldVal=e.val;//根据参数条件，将节点的value值进行替换if(!onlyIfAbsent)e.val=value;break;}Node<K,V>pred=e;//如果没有相同节点，并且遍历到了最后一个节点if((e=e.next)==null){ //将节点拼接在链表最后面pred.next=newNode<K,V>(hash,key,value,null);break;}}}//如果根节点是树节点，用树的方式进行插入elseif(finstanceofTreeBin){ Node<K,V>p;binCount=2;if((p=((TreeBin<K,V>)f).putTreeVal(hash,key,value))!=null){ oldVal=p.val;if(!onlyIfAbsent)p.val=value;}}}}if(binCount!=0){ //判断链表长度，如果大于TREEIFY_THRESHOLD，也就是大于8if(binCount>=TREEIFY_THRESHOLD)//尝试进行扩容treeifyBin(tab,i);//如果是替换，那么返回替换前的valueif(oldVal!=null)returnoldVal;break;}}}//添加计数，判断是否需要扩容，如果正在扩容，则帮助扩容，扩容后再次判断是否需要再次扩容。//根据sizeCtl扩容阈值(注意还有一个SIZECTL，这两个并不是同一个东西)//判断是否达到阈值需要进行扩容，需要扩容的话，//判断是否正在扩容，正在扩容则帮助扩容addCount(1L,binCount);returnnull;}

       我们来看一下这个addcount()方法：

//从putVal传入的参数是1，binCount，binCount默认是0，只有hash冲突了才会大于1.且他的大小是链表的长度（如果不是红黑数结构的话）。privatefinalvoidaddCount(longx,intcheck){ CounterCell[]as;longb,s;//如果计数盒子不是空或者//如果修改baseCount失败if((as=counterCells)!=null||!U.compareAndSwapLong(this,BASECOUNT,b=baseCount,s=b+x)){ CounterCella;longv;intm;booleanuncontended=true;//如果计数盒子是空（尚未出现并发）//如果随机取余一个数组位置为空或者//修改这个槽位的变量失败（出现并发了）//执行fullAddCount方法。并结束if(as==null||(m=as.length-1)<0||(a=as[ThreadLocalRandom.getProbe()&m])==null||!(uncontended=U.compareAndSwapLong(a,CELLVALUE,v=a.value,v+x))){ fullAddCount(x,uncontended);return;}if(check<=1)return;s=sumCount();}//如果需要检查,检查是否需要扩容，在putVal方法调用时，默认就是要检查的。if(check>=0){ Node<K,V>[]tab,nt;intn,sc;//如果map.size()大于sizeCtl（达到扩容阈值需要扩容）且//table不是空；且table的长度小于1<<。（可以扩容）while(s>=(long)(sc=sizeCtl)&&(tab=table)!=null&&(n=tab.length)<MAXIMUM_CAPACITY){ //根据length得到一个标识intrs=resizeStamp(n);//如果正在扩容if(sc<0){ //如果sc的低位不等于标识符（校验异常sizeCtl变化了）//如果sc==标识符+1（扩容结束了，不再有线程进行扩容）（默认第一个线程设置sc==rs左移位+2，当第一个线程结束扩容了，就会将sc减一。这个时候，sc就等于rs+1）//如果sc==标识符+（帮助线程数已经达到最大）//如果nextTable==null（结束扩容了）//如果transferIndex<=0(转移状态变化了)//结束循环if((sc>>>RESIZE_STAMP_SHIFT)!=rs||sc==rs+1||sc==rs+MAX_RESIZERS||(nt=nextTable)==null||transferIndex<=0)break;//如果可以帮助扩容，那么将sc加1.表示多了一个线程在帮助扩容if(U.compareAndSwapInt(this,SIZECTL,sc,sc+1))//扩容transfer(tab,nt);}//如果不在扩容，将sc更新：标识符左移位然后+2.也就是变成一个负数。高位是标识符，低位初始是2.elseif(U.compareAndSwapInt(this,SIZECTL,sc,(rs<<RESIZE_STAMP_SHIFT)+2))//更新sizeCtl为负数后，开始扩容。transfer(tab,null);s=sumCount();}}}

       x参数表示的此次需要对表中元素的个数加几。check参数表示是否需要进行扩容检查，大于等于0需要进行检查，而我们的putVal方法的binCount参数最小也是0，因此，每次添加元素都会进行检查。（除非是覆盖操作），下面是详细步骤：

       判断计数盒子（counterCells）属性是否是空，如果是空，就尝试修改baseCount变量，对该变量进行加X。

       如果计数盒子不是空，或者修改baseCount变量失败了，则放弃对baseCount进行操作。

       如果计数盒子是null或者计数盒子的length是0，或者随机取一个位置是null，那么就对刚刚的元素进行CAS赋值。

       如果赋值失败，或者满足上面的条件，则调用fullAddCount方法重新死循环插入。

       这里如果操作baseCount失败了（或者计数盒子不是Null），且对计数盒子赋值成功，那么就检查check变量，如果该变量小于等于1.直接结束。否则，计算一下count变量。

       如果check大于等于0，说明需要对是否扩容进行检查。

       如果map的size大于sizeCtl（扩容阈值），且table的长度小于1<<，那么就进行扩容。

       根据length得到一个标识符，然后，判断sizeCtl状态，如果小于0，说明要么在初始化，要么在扩容。

       如果正在扩容，那么就校验一下数据是否变化了（具体可以看上面代码的注释）。如果检验数据不通过，break。

       如果校验数据通过了，那么将sizeCtl加一，表示多了一个线程帮助扩容。然后进行扩容。

       如果没有在扩容，但是需要扩容。那么就将sizeCtl更新，赋值为标识符左移位——一个负数。然后加2。表示，已经有一个线程开始扩容了。然后进行扩容。然后再次更新count，看看是否还需要扩容。

       到此，我们的put方法结束了。

1.7与1.8的区别项目1..8同步机制分段锁，每个segment继承ReentrantLockCAS+synchronized保证并发更新数据结构数组+链表数组+链表+红黑树节点HashEntryNodeput操作多个线程同时竞争获取同一个segment锁，获取成功的线程更新map；失败的线程尝试多次获取锁仍未成功，则挂起线程，等待释放锁访问相应的bucket时，使用sychronizeded关键字，防止多个线程同时操作同一个bucket，如果该节点的hash不小于0，则遍历链表更新节点或插入新节点；如果该节点是TreeBin类型的节点，说明是红黑树结构，则通过putTreeVal方法往红黑树中插入节点；更新了节点数量，还要考虑扩容和链表转红黑树总结

       concurrentHashMap和hashMap相比，由于考虑了高并发，整体更加复杂，并且也更难以理解。本文只对put和get方法进行了详细的分析，其他方法相对来说比较简单，想要了解的朋友可以自己去查看源码。另外本次源码解析有错误的，欢迎各位指正，谢谢。