ConcurrentHashMap 并发扩容骚操作
上期问题
少年，老衲看你骨骼清奇，眉宇之间透露着一股王者的气息。来吧，跟我讲讲 ConcurrentHashMap 是如何进行管理它的容量的，也就是当我们调用它的 size 方法的时候发生了什么故事？（前面我们介绍了 ConcurrentHashMap 的实现原理，但是扩容和容量大小留了个小尾巴，今天来割一下这个小尾巴，嘿嘿）
我的答案
毕竟是要支持并发，ConcurrentHashMap 的扩容操作比较复杂，我们将从以下几点来带讨论一下它的扩容。
触发扩容
-
添加新元素后，元素个数达到扩容阈值触发扩容。
-
调用 putAll 方法，发现容量不足以容纳所有元素时候触发扩容。
-
某个槽内的链表长度达到 8，但是数组长度小于 64 时候触发扩容。
统计元素个数
触发后面 2 点没啥问题，但是第 1 点中有个小问题，它是如何统计元素的个数呢？它采用和 LongAdder类似的分散热点数据的解决思路，不知道 LongAdder 的小伙伴可以参考往期文章 还在用 AtomicLong？是时候了解一下 LongAdder 了。ConcurrentHashMap 内部定义了一个 CounterCell 的类，它同样被 Contended 修饰防止 volatile 带来的伪共享问题，伪共享不了解可以参考往期文章 面试官问我 volatile 是否存在伪共享问题？我懵逼了。内部实例化了一个 CounterCell 的数组来记录元素的个数，每当线程 put 一个元素到容器中，线程会被映射到一个 CounterCell 的一个元素上面采用 CAS 算法进行加 1 操作，当然如果当前 CounterCell 上已经有线程在操作，或者并发量比较小的话会直接将加 1 累加到 BASECOUNT 上面。
就是依据这样的策略，容器的元素的个数就会游刃有余的计算出来，当需要获取当前容器元素个数的时候，直接将 CounterCell 数据的每个元素值加起来再加上 BASECOUNT 的值就是当前容器中的元素个数。
扩容
上面我们知道了触发扩容的条件为元素个数达到阈值开始扩容，然后也知道了它是如何统计元素的个数的，接下来就看看扩容的运行机制。
首先每个线程承担不小于 16 个槽中的元素的扩容，然后从右向左划分 16 个槽给当前线程去迁移，每当开始迁移一个槽中的元素的时候，线程会锁住当前槽中列表的头元素，假设这时候正好有 get 请求过来会仍旧在旧的列表中访问，如果是插入、修改、删除、合并、compute 等操作时遇到 ForwardingNode，当前线程会加入扩容大军帮忙一起扩容，扩容结束后再做元素的更新操作。
总结
总结一下，对于 ConcurrentHashMap 的扩容我们需要明确如上三点就可以了，扩容触发的时机、元素个数的计算以及具体扩容过程中是如何坚持对外提供服务的就可以了。
如上即为 ConcurrentHashMap 扩容操作的简单介绍，实际 JDK 里面的扩容源码非常复杂，如果有小伙伴对源码感兴趣的话，本毛毛虫找到一篇不错的源码分析文章大家可以参考一下 https://blog.****.net/ZOKEKAI/article/details/90051567 。这篇相当于 ConcurrentHashMap 的续集，对前序感兴趣的可以参考往期文章 ConcurrentHashMap 并发读写，用了什么黑科技。
以上即为昨天的问题的答案，小伙伴们对这个答案是否满意呢？欢迎留言和我讨论。
又要到年末了，你是不是又悄咪咪的开始看机会啦。为了广大小伙伴能充足电量，能顺利通过 BAT 的面试官无情三连炮，我特意推出大型刷题节目。每天一道题目，第二天给答案，前一天给小伙伴们独立思考的机会。