ConcurrentHashMap 的 size() 返回近似值，因其底层 sumCount() 仅累加 baseCount 与 volatile 读取的 CounterCell 数组值，无锁且不保证强一致性。
ConcurrentHashMap 并不直接通过 sumCount() 方法“计算”当前元素数量，而是用它来读取一个近似、非实时的总数。这个值是多个分段计数器（CounterCell[] 数组）的累加和，加上主计数器 baseCount，但不保证强一致性。
sumCount 的作用：聚合分散的计数器
为避免高并发下多个线程竞争同一计数器造成性能瓶颈，ConcurrentHashMap 把计数任务分散到多个 CounterCell 中（类似分段锁思想）。当线程执行 put、remove 等操作时，会尝试将增量写入某个 CounterCell；失败则退化到更新 baseCount。
sumCount() 做的事很简单：
- 读取当前
baseCount值 - 遍历
counterCells数组（如果非 null），把每个非 null 单元格的value累加进来 - 返回总和
为什么 size() 返回的是近似值？
size() 方法底层就调用了 sumCount()，但它不加锁、不阻塞，也不等待所有 pending 更新完成。因此：
立即学习“Java免费学习笔记（深入）”；
- 在高并发写入过程中，可能有线程刚更新了
CounterCell但还没被sumCount()扫到（比如数组扩容中、或 CAS 更新尚未成功） - 某些写操作可能还在重试或退避，未反映到计数器上
- 没有全局内存屏障强制刷新所有 CPU 缓存，不同线程看到的计数值可能短暂不一致
所以官方文档明确说明：size() 是“a best-effort estimate”，不是精确快照。
想获取更准确的数量？有这些替代思路
如果业务确实需要强一致的元素个数（例如做校验或关键统计），不能依赖 size() 或 sumCount()：
-
用
mappingCount()：Java 8+ 引入，语义同size()，但返回long类型，避免int溢出；仍是估算，无一致性提升 -
手动遍历计数：调用
keySet().size()或entrySet().size()—— 这会触发一次全表遍历，获得精确值，但代价是 O(n) 时间 + 短暂的结构一致性保障（内部使用Traverser，不加锁但能保证不漏项） -
业务层维护原子计数器：如果只关心总数且写操作可控，可用
AtomicLong在每次put/remove后同步增减 —— 需自行保证逻辑正确性，但可得精确、低延迟的总数
源码里 sumCount 长什么样？（精简示意）
大致逻辑如下（以 JDK 11 为例）：
final long sumCount() {
CounterCell[] as = counterCells;
long sum = baseCount;
if (as != null) {
for (CounterCell a : as) {
if (a != null)
sum += a.value; // volatile read
}
}
return sum;
}
注意：这里对 a.value 的读取是 volatile 的，保证可见性，但不解决竞态窗口问题。
