concurrenthashmap 是为高并发重新设计的独立实现，非 hashmap 线程安全版；替换需关注 null 限制、弱一致性迭代器及复合操作原子性，不可仅改类型声明。
ConcurrentHashMap 不是 HashMap 的“线程安全版”，而是为高并发场景重新设计的独立实现。直接替换不能只改类型声明，需结合使用方式、语义差异和线程协作逻辑来调整——否则可能引入隐蔽问题，比如 null 值误用、迭代器行为变化或弱一致性误判。
关键替换前提：确认你真需要 ConcurrentHashMap
不是所有多线程 Map 场景都适合 ConcurrentHashMap：
- 仅读多写少（如配置缓存），且写操作不频繁 → 可用 Collections.synchronizedMap(new HashMap())，简单够用
- 写操作极少，但要求强一致性（如计数器必须精确）→ 注意 ConcurrentHashMap 的 size() 是估算值，应改用 LongAdder 或显式锁
- 单线程或线程封闭（ThreadLocal）→ 仍用 HashMap，无必要加并发开销
- 真正高频并发读写（如订单状态映射、实时指标聚合）→ ConcurrentHashMap 才是正解
替换时必须处理的语义差异
以下三点不改，代码可能“编译通过但运行出错”：
- 禁止 null 键或 null 值：HashMap 允许 key=null 或 value=null；ConcurrentHashMap 调用 put(null, v) 或 put(k, null) 会直接抛 NullPointerException。需提前校验或用 Optional 包装
- 迭代器不 fail-fast，而是弱一致：ConcurrentHashMap 的 keySet().iterator() 可能跳过刚插入的元素，也可能返回已删除的旧值。若业务依赖“遍历时看到最新全量状态”，就不能直接遍历，应改用 forEach() + action 或转成快照（如 new HashMap(map)）再处理
- 复合操作非原子：比如 “先检查 key 是否存在，再 put” 在 HashMap 中可用 containsKey()+put 实现，但在 ConcurrentHashMap 中这两步不构成原子性。必须改用 computeIfAbsent()、merge() 或 putIfAbsent() 等内置原子方法
典型 unsafe → safe 改写示例
常见错误写法（看似线程安全，实则仍竞争）：
// ❌ 危险：两步操作，中间可能被其他线程修改
if (!concurrentMap.containsKey("user:123")) {
concurrentMap.put("user:123", new User());
}
正确写法（利用内置原子方法）：
// ✅ 安全：CAS 保证整个过程不可分割
concurrentMap.computeIfAbsent("user:123", k -> new User());
// 或更明确地控制创建逻辑
concurrentMap.putIfAbsent("user:123", new User()); // 若已存在，不覆盖
再比如计数累加：
// ❌ 错误：get + put 组合非原子，结果可能丢失
Integer count = map.get("error");
map.put("error", count == null ? 1 : count + 1);
// ✅ 正确：用 merge 原子更新
map.merge("error", 1, Integer::sum);
性能与初始化建议
ConcurrentHashMap 的默认参数面向通用场景，但线上常需调优：
- 初始容量设为预估 size / 并发度：避免扩容时多线程争抢。例如预估存 10 万条，平均 8 线程写入，可设 new ConcurrentHashMap(12800)（100000 ÷ 8 ≈ 12500，向上取 2 的幂）
- 避免在循环内反复调用 size()：它内部是分段统计+重试，开销比 HashMap 大得多。如需精确总数，考虑用 mappingCount()（返回 long，更准确）或另起计数器
- 大量只读场景，可配合 computeIfAbsent 做懒加载：既避免初始化竞争，又节省内存，比如缓存解析后的 JSON 对象
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
