Java并发工具与ConcurrentHashMap解析

“纵有疾风来，人生不言弃”，这句话送给正在学习文章的朋友们，也希望在阅读本文《Java并发工具与ConcurrentHashMap详解》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新文章相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

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 成功。

典型误用场景：

• 用 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 比嵌套 compute 更高效
• 需要原子增减并返回旧值 → map.merge(key, 1L, Long::sum) 比 compute 更语义清晰，且 merge 底层对数字类型做了少量优化

别忽略 LongAdder 的内存开销：它本质是数组+cell，每个线程争用不同 cell，但总内存占用比单个 AtomicLong 高数倍。权衡点始终是吞吐 vs 内存。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Java并发工具与ConcurrentHashMap解析》文章吧，也可关注golang学习网公众号了解相关技术文章。