ConcurrentHashMapsize()无锁统计原理揭秘

ConcurrentHashMap 的 `size()` 方法返回的是一个非阻塞、无锁的近似统计值，其背后采用 `baseCount` 与分片式 `counterCells` 数组协同计数的设计，巧妙规避了高并发下单变量竞争导致的性能瓶颈，思想类似 `LongAdder`；但正因全程无锁、不阻塞写操作，且存在扩容延迟、CAS 时序差、缓存伪共享等现实约束，该结果仅适用于监控告警或宽松阈值判断，绝不可用于强一致性逻辑——若需精确计数，应改用 `mappingCount()` 或外层原子控制。

ConcurrentHashMap 的 size() 为什么不能直接用 volatile int 计数

因为高并发写入时，baseCount 字段会成为热点竞争点：多个线程同时执行 addCount，反复 CAS 失败会导致大量自旋和重试，严重拖慢 put 性能。JDK 8 放弃单变量计数，转而用分片 + CAS 的组合策略来摊平竞争压力。

这和 LongAdder 的设计思路一致——不是“一个数大家抢”，而是“每人记一点，最后加总”。counterCells 数组就是那组“分散记账本”，每个线程优先往自己选中的 CounterCell 里写增量，冲突概率大幅下降。

counterCells 数组如何被初始化和扩容

数组默认为 null，首次竞争失败后才触发初始化；初始长度为 2，后续按需翻倍（最大不超过 CPU 核心数）。关键逻辑在 fullAddCount 方法中：

• 先尝试 CAS 更新 baseCount，失败则进入分片流程
• 若 counterCells 为空或长度为 0，先用 CAS 设置一个初始化标志位，再创建长度为 2 的数组
• 若数组已存在但目标 CounterCell 为 null，尝试用 CAS 创建新单元；失败则重试或扩容
• 扩容条件是：当前线程再次 CAS 失败，且数组长度未达上限，此时重建为原长两倍的新数组

注意：counterCells 不是线程私有，而是通过 ThreadLocalRandom.getProbe() 做哈希寻址，实现伪随机分片——这避免了固定线程总写同一个槽位。

size() 返回值为何是近似值

size() 调用 sumCount()，它把 baseCount 和所有非 null 的 CounterCell.value 累加。但这个过程本身不加锁，也不阻塞写操作：

• 遍历 counterCells 数组时，可能有线程正在扩容、新建或更新某个 CounterCell
• 某个 CounterCell 的值被读取后，另一线程可能立刻对其 CAS 增量，该增量不会体现在本次 sum 中
• 更隐蔽的是：addCount 中的 check 扩容逻辑可能正在运行，而 sumCount 读到的是扩容前的 baseCount 或旧 CounterCell 值

所以 size() 是统计快照，不是事务快照。它适合做监控、日志或阈值判断（如“超过 1000 就告警”），但绝不能用于“size == 0 才关闭资源”这类强一致性场景。

什么时候 size() 的误差会明显变大

误差不是均匀分布的，以下情况会让偏差显著放大：

• 写操作极其密集，且集中在短时间窗口（如批量导入）：大量 addCount 拥挤在 fullAddCount 路径，counterCells 扩容滞后，部分增量暂存于 baseCount 未及时分流
• 读多写少场景下突然爆发写请求：此时 counterCells 可能仍为 null 或长度很小，所有写线程都挤在 baseCount 上 CAS，导致部分增量丢失或延迟计入
• 调用 size() 的线程与写线程发生 cache line 争用：baseCount 和 counterCells 都是 volatile 字段，频繁读写可能引发 false sharing，进一步拉大观测延迟

真正容易被忽略的点是：你无法靠“多调用几次 size() 取平均”来逼近真实值——因为每次调用都是独立快照，且中间状态不可见。需要精确计数，就得在外层用 compute 或 merge 配合原子变量控制。

到这里，我们也就讲完了《ConcurrentHashMapsize()无锁统计原理揭秘》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！