ConcurrentHashMap 不能用 put 替代 computeIfAbsent，因 put 无法保证初始化的原子性，而 computeIfAbsent 通过 RESERVED 状态、CAS 和分段锁确保 key 对应 value 只创建一次。
ConcurrentHashMap 为什么不能直接用 put 替代 computeIfAbsent
当多个线程同时尝试初始化某个 key 对应的 value（比如缓存构建、单例对象创建），直接用 put 会覆盖或丢失写入，而 computeIfAbsent 能保证只初始化一次，且整个过程原子。它底层利用了 Node 的 RESERVED 状态和 CAS + synchronized 分段加锁机制，不是简单“先查后 put”。
常见错误是这样写：
if (!map.containsKey(key)) {
map.put(key, expensiveCreate());
}
这在并发下会多次执行 expensiveCreate()，且可能丢弃部分结果。正确做法是：
map.computeIfAbsent(key, k -> expensiveCreate());
-
computeIfAbsent返回的是最终值，无论是否新创建 - 如果 key 已存在（哪怕 value 是
null），不会触发 mappingFunction - mappingFunction 内部不要依赖外部可变状态，否则可能引发不可预测的竞态
ConcurrentHashMap 的 size() 和 isEmpty() 为什么不准
这两个方法返回的是近似值，不加全局锁，只汇总各 segment / bin 的统计快照。高并发写入时，调用瞬间可能漏掉正在提交的修改，size() 可能比实际少，isEmpty() 可能返回 true 即使刚有线程 put 成功。
立即学习“Java免费学习笔记（深入）”；
典型误用场景：
- 用
while (!map.isEmpty()) { ... }做轮询消费 —— 可能提前退出 - 根据
size() == 0判断是否需要初始化 —— 条件竞争导致重复初始化
替代方案取决于用途：
- 判断是否为空：改用
map.containsKey(someKey)或更明确的哨兵标志 - 获取精确大小：仅在低并发或调试时用，生产逻辑不应依赖它做控制流
- 需要强一致性计数：搭配
LongAdder单独维护
ConcurrentHashMap 在 JDK 8 和 JDK 9+ 的扩容行为差异
JDK 8 使用“多线程协助扩容”，迁移时其他线程发现 table 正在扩容，会主动帮着搬数据；JDK 9+（确切说是 Java 11 起）引入了 ForwardingNode 的优化，但关键变化在于：扩容阈值计算方式变了，且对 TreeBin（红黑树节点）的迁移逻辑更严格。
影响最直接的是：
- 从 JDK 8 升级到 11+ 后，如果手动设置了初始容量和负载因子，但没考虑树化阈值（
UNTREEIFY_THRESHOLD = 6），可能意外触发更多树化/退化，影响遍历性能 -
putAll()在大集合场景下，JDK 11+ 更倾向于批量分段扩容，但若原 map 已接近阈值，可能引发连续多次扩容 - 使用
new ConcurrentHashMap(initialCapacity)时，JDK 8 实际分配的是 >= initialCapacity 的最小 2 的幂；JDK 11+ 仍如此，但内部sizeCtl初始化逻辑略有调整，极端情况下首次 put 可能多一次 resize
建议：线上服务升级 JDK 后，观察 GC 日志中的 ConcurrentHashMap 相关扩容频率，尤其关注 transferIndex 和 baseCount 的波动。
用 ConcurrentHashMap 实现简易线程安全计数器的陷阱
很多人用 map.compute(key, (k, v) -> (v == null ? 1 : v + 1)) 做计数，看似简洁，但每次调用都触发哈希查找 + CAS 尝试，高频更新下竞争激烈，性能远不如 LongAdder。
真正适合用 ConcurrentHashMap 计数的场景是：key 空间稀疏、更新频次中低、需要按 key 聚合且后续要遍历或查询特定 key。
- 高频单 key 计数（如请求总数）→ 用
LongAdder或AtomicLong - 多 key 分桶计数（如按用户 ID 统计）→
ConcurrentHashMap<string longadder></string>比嵌套compute更高效 - 需要原子增减并返回旧值 →
map.merge(key, 1L, Long::sum)比compute更语义清晰，且 merge 底层对数字类型做了少量优化
别忽略 LongAdder 的内存开销：它本质是数组+cell，每个线程争用不同 cell，但总内存占用比单个 AtomicLong 高数倍。权衡点始终是吞吐 vs 内存。
