上篇文章介绍了 HashMap 源码后，在博客平台广受好评，让本来己经不打算更新这个系列的我，仿佛被打了一顿鸡血。真的，被读者认可的感觉，就是这么奇妙。
然后，有读者希望我能出一版 ConcurrentHashMap 的解析。所以，今天的这篇文章，我准备讲述一下 ConcurrentHashMap 分别在JDK1.7和 JDK1.8 的源码。文章较长，建议小伙伴们可以先收藏再看哦~
说一下为什么我要把源码解析写的这么详细吧。一方面，可以记录下当时自己的思考过程，也方便后续自己复习翻阅；另一方面，记录下来还能够帮助看到文章的小伙伴加深对源码的理解，简直是一举两得的事情。
更正错误另外，上一篇文章，有个错误点，却没有读者给我指正出来。o(╥﹏╥)o 。因此，我只能自己在此更正一下。见下面截图，
put 方法，在新值替换旧值那里，应该是只有一种情况的，e 不包括新值。图中的方框也标注出来了。因为，判断 e=p.next==null ， 然后新的节点是赋值给 p.next 了，并没有赋值给 e，此时 e 依旧是空的。所以 e!=null，代表当前的 e 是已经存在的旧值。
文章编写过程，难免出现作者考虑不周的地方，如果有朋友发现有错误的地方，还请不吝赐教，指正出来。知错能改，善莫大焉，对于技术，我们应该怀有一颗严谨的心态~
文章目录这篇文章，我打算从以下几个方面来讲。
1）多线程下的 HashMap 有什么问题？
2）怎样保证线程安全，为什么选用 ConcurrentHashMap？
3）ConcurrentHashMap 1.7 源码解析
底层存储结构
常用变量
构造函数
put() 方法
ensureSegment() 方法
scanAndLockForPut() 方法
rehash() 扩容机制
get() 获取元素方法
remove() 方法
size() 方法是怎么统计元素个数的
4）ConcurrentHashMap 1.8 源码解析
put()方法详解
initTable()初始化表
addCount()方法
fullAddCount()方法
transfer()是怎样扩容和迁移元素的
helpTransfer()方法帮助迁移元素
多线程下 HashMap 有什么问题？在上一篇文章中，已经讲解了 HashMap 1.7 死循环的成因，也正因为如此，我们才说 HashMap 在多线程下是不安全的。但是，在JDK1.8 的 HashMap 改为采用尾插法，已经不存在死循环的问题了，为什么也会线程不安全呢？
我们以 put 方法为例（1.8），
假如现在有两个线程都执行到了上图中的划线处。当线程一判断为空之后，CPU 时间片到了，被挂起。线程二也执行到此处判断为空，继续执行下一句，创建了一个新节点，插入到此下标位置。然后，线程一解挂，同样认为此下标的元素为空，因此也创建了一个新节点放在此下标处，因此造成了元素的覆盖。
所以，可以看到不管是 JDK1.7 还是 1.8 的 HashMap 都存在线程安全的问题。那么，在多线程环境下，应该怎样去保证线程安全呢？
怎样保证线程安全，为什么选用 ConcurrentHashMap？首先，你可能想到，在多线程环境下用 Hashtable 来解决线程安全的问题。这样确实是可以的，但是同样的它也有缺点，我们看下最常用的 put 方法和 get 方法。
可以看到，不管是往 map 里边添加元素还是获取元素，都会用 synchronized 关键字加锁。当有多个元素之前存在资源竞争时，只能有一个线程可以获取到锁，操作资源。更不能忍的是，一个简单的读取操作，互相之间又不影响，为什么也不能同时进行呢？
所以，hashtable 的缺点显而易见，它不管是 get 还是 put 操作，都是锁住了整个 table，效率低下，因此 并不适合高并发场景。
也许，你还会想起来一个集合工具类 Collections，生成一个SynchronizedMap。其实，它和 Hashtable 差不多，同样的原因，锁住整张表，效率低下。