title: ConcurrentHashMap 的 size 不是实时值一次缓存不一致让我追了 2 小时源码date: 2026-09-25tags: [Java, ConcurrentHashMap, CAS, 分段锁, 源码, 并发]2024 年做本地缓存改造我们用ConcurrentHashMap做热点数据缓存同时用另一个线程定时打印map.size()做容量监控。有一天运营反馈缓存命中率异常监控显示缓存条目数一直卡在 0但实际查询却能命中数据。我盯着size()的结果看了半天以为是缓存没写入后来才发现size()在 JDK 8 里不是实时精确值而computeIfAbsent的返回值才是。这篇文章把ConcurrentHashMap的size()、computeIfAbsent和扩容机制拆开聊清楚为什么高并发下有些方法看似对其实不对。一、事故现场size() 显示 0get 却能命中代码大致如下Service public class HotCache { private final ConcurrentHashMapLong, Product cache new ConcurrentHashMap(); public Product get(Long id) { return cache.computeIfAbsent(id, k - loadFromDB(k)); } public int size() { return cache.size(); } }另一个线程每 5 秒打印一次Scheduled(fixedRate 5000) public void report() { System.out.println(cache size hotCache.size()); }压测时发现-get(id)能返回商品数据说明缓存里有值。- 但size()一直返回 0。二、size() 源码JDK 8 用 baseCount CounterCellJDK 8 的ConcurrentHashMap不再像 JDK 7 那样维护一个全局的segment计数器而是用了baseCount和CounterCell[]数组private transient volatile long baseCount; private transient volatile CounterCell[] counterCells;addCount是增加计数的核心方法private final void addCount(long x, int check) { CounterCell[] as; long b, s; if ((as counterCells) ! null || !U.compareAndSwapLong(this, BASECOUNT, b baseCount, s b x)) { CounterCell a; long v; int m; boolean uncontended true; 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(); } // ... 检查是否需要扩容 }逻辑1. 先尝试 CAS 更新baseCount。2. 如果 CAS 失败高并发下多个线程同时更新说明竞争激烈使用CounterCell[]分散热点。3. 每个线程根据ThreadLocalRandom.getProbe()选择一个 CounterCell 更新。size()最终调用sumCount()public int size() { long n sumCount(); return ((n 0L) ? 0 : (n (long)Integer.MAX_VALUE) ? Integer.MAX_VALUE : (int)n); } final long sumCount() { CounterCell[] as counterCells; CounterCell a; long sum baseCount; if (as ! null) { for (int i 0; i as.length; i) { if ((a as[i]) ! null) sum a.value; } } return sum; }注意sumCount()返回的是一个快照不是实时精确值。在读的瞬间可能有的线程已经修改了baseCount或某个CounterCell但还没被统计进去。但这还不能解释为什么size()一直返回 0。真正的原因是另一个问题computeIfAbsent的返回值和size()的语义不一致。三、computeIfAbsent 的坑函数可能执行多次computeIfAbsent的源码public V computeIfAbsent(K key, Function? super K, ? extends V mappingFunction) { if (mappingFunction null) throw new NullPointerException(); int h spread(key.hashCode()); V val null; int binCount 0; for (NodeK,V[] tab table;;) { NodeK,V f; int n, i, fh; if (tab null || (n tab.length) 0) tab initTable(); else if ((f tabAt(tab, i (n - 1) h)) null) { NodeK,V r new ReservationNodeK,V(); synchronized (r) { if (casTabAt(tab, i, null, r)) { binCount 1; try { if ((val mappingFunction.apply(key)) ! null) val new NodeK,V(h, key, val, null); } finally { setTabAt(tab, i, val); } } } } // ... 其他情况 if (binCount ! 0) { if (binCount TREEIFY_THRESHOLD) treeifyBin(tab, i); if (val ! null) return val; break; } } if (val ! null) addCount(1L, binCount); return val; }关键点1.computeIfAbsent只对 bin桶加锁不是全表锁。2. 如果多个线程同时调用同一个 key只有一个线程会执行 mappingFunction其他线程会等待。3. 但如果是不同 key 落到同一个 bin会串行执行。我们遇到的 size 为 0 问题是因为computeIfAbsent在ReservationNode占位后如果 mappingFunction 抛异常会用setTabAt(tab, i, val)把 null 写回去。addCount只在val ! null时调用。所以某些 bin 里有 Node但计数没增加。但这不是size()返回 0 的原因。真正原因是size()是快照而get()读的是实时 table。如果在打印 size 的那个时间点所有写入刚好发生在sumCount()遍历 CounterCell 之后且baseCount还没更新确实可能读到 0。不过这种概率很低。更可能的情况是我们的定时任务线程和写线程有可见性问题或者打印逻辑本身有问题。四、实际根因监控读的是另一个 map 实例排查到最后发现report()方法里的hotCache是另一个 Spring 代理对象它内部的cache和实际写入的cache不是同一个实例。原因是早期版本用了Cacheable和手动 new 的ConcurrentHashMap混用重构时没清干净。但这个问题让我好好读了一遍size()的源码也意识到ConcurrentHashMap.size()的返回值不是精确值在高并发下只能作为参考。五、CounterCell 和 LongAdder 是一套思路如果你读过LongAdder的源码会发现CounterCell极其眼熟——因为 JDK 8 里ConcurrentHashMap的计数就是照着 LongAdder 的设计抄的思路无竞争时更新一个 base 值有竞争时把热点分散到 cell 数组求和时再遍历累加。代价是求和这一步永远不是原子的。这带来一个直接的推论size() 在写入繁忙时既可能偏大也可能偏小。sumCount() 先读 baseCount再遍历 CounterCell遍历期间任何一个 cell 被更新都不会体现在结果里。所以它的文档注释里写的是 Returns the number of mappings而 Javadoc 明确提示这是估计值。顺便说一个冷知识JDK 8 里ConcurrentHashMap还有一个mappingCount()方法返回 long。它存在的理由是 size() 返回 int超过 21 亿条目时会截断成 Integer.MAX_VALUE——虽然绝大多数项目到不了这个量级但既然官方都补了这个方法说明确实有人撞上过。六、监控该怎么改一次说清三种方案方案精确性额外成本适用场景map.size()近似快照零粗略容量观察允许 ±N 误差外部 AtomicLong 计数精确每次写多一次 CAS条目稳定、增删对称LongAdder 计数最终精确sum 时点写分散读时求和高频增删 低频读监控我们的修复最终用的是 LongAddercomputeIfAbsent命中新 key 时added.increment()remove/invalidate时added.decrement()。监控线程改用added.sum()。写入侧几乎零开销监控数值和实际条目数的误差在压测里稳定为 0——因为 sum 虽然也是瞬时快照但我们的缓存只有新增和批量过期两种变更批量过期走的是全量重建重建完同步 reset 计数语义就对齐了。这里有一个我踩过的次生坑批量过期用map.clear()之后如果忘了added.reset()监控数字会一直虚高。别笑这个问题在告警群里挂了一周才有人发现因为大家都默认监控是对的数据是错的。七、扩容机制transfer 和 sizeCtlConcurrentHashMap的扩容是并发扩容多个线程可以同时参与private final void transfer(NodeK,V[] tab, NodeK,V[] nextTab) { int n tab.length, stride; if ((stride (NCPU 1) ? (n 3) / NCPU : n) MIN_TRANSFER_STRIDE) stride MIN_TRANSFER_STRIDE; if (nextTab null) { try { NodeK,V[] nt (NodeK,V[])new Node?,?[n 1]; nextTab nt; } catch (Throwable ex) { sizeCtl Integer.MAX_VALUE; return; } nextTable nextTab; transferIndex n; } // ... 迁移逻辑 }sizeCtl是一个很重要的字段- 负数表示正在扩容。--1表示有线程在初始化 table。- 其他负数高 16 位表示扩容标识戳低 16 位表示参与扩容的线程数加 1。- 正数下一次扩容的阈值。八、我的取舍判断ConcurrentHashMap.size()不是精确值只能做容量参考。如果需要精确值可以外部维护一个AtomicLong计数器。computeIfAbsent适合只计算一次的缓存场景但要注意 mappingFunction 不能抛异常否则桶会被清空。不要用ConcurrentHashMap做实时全量统计它的设计目标是高并发读写不是强一致性快照。如果 key 的 hashCode 分布不均会导致某些 bin 过长影响性能。九、复盘真实数字排查时间2 小时根因监控读的是另一个 map 实例源码学习收益理解了 size() 的近似性和 computeIfAbsent 的 ReservationNode 机制修复后统一用一个缓存实例size 监控改为 AtomicLong 计数十、思考题你的项目里用ConcurrentHashMap.size()做监控吗如果 size 不精确你会怎么改