computeIfAbsent能安全解决高并发下重复初始化和死循环问题：它原子性地执行“判断+计算+插入”，仅首线程构造对象，其余线程等待其结果；新版ConcurrentHashMap还避免自递归死锁，改抛IllegalStateException。
Java 中 computeIfAbsent 是 ConcurrentHashMap 提供的线程安全方法，它能天然避免高并发下重复初始化和死循环问题——关键在于其原子性语义：**只执行一次计算，且阻塞其他线程等待结果，而非让多个线程同时构造新对象**。
为什么普通双重检查锁 + Map.putIfAbsent 仍可能出问题
很多人用 putIfAbsent 配合外部同步或双重检查来缓存对象，但容易忽略两个隐患：
- 如果构造逻辑本身耗时、有副作用（如远程调用、IO），
putIfAbsent只保证“写入”原子，不控制“计算”是否并发执行；多个线程可能同时通过检查、各自构造实例，再由putIfAbsent丢弃多数结果——浪费资源，甚至引发重复注册、重复订阅等业务错误。 - 若构造过程意外递归调用自身（例如初始化中又触发相同 key 的获取），而 map 实现不支持重入（如早期
ConcurrentHashMap在 compute 过程中对同一 key 再 compute 会死锁），就可能卡死或抛IllegalStateException。
computeIfAbsent 如何安全解决这两个问题
computeIfAbsent 将“判断是否存在 + 计算 + 插入”三步合并为一个原子操作，并在内部维护 pending 状态。当多个线程同时请求同一 key：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 仅第一个线程真正执行 mappingFunction；
- 其余线程被挂起，**等待第一个线程完成并直接返回其结果**，不会重复执行构造逻辑；
- 即使 mappingFunction 内部再次调用
computeIfAbsent(key, ...)（即自递归），从 JDK 8u292+ 开始的ConcurrentHashMap已修复该场景，会抛IllegalStateException而非死锁，明确暴露设计缺陷，便于及时修正。
正确使用姿势与注意事项
要真正发挥 computeIfAbsent 的优势，需注意以下几点：
立即学习“Java免费学习笔记（深入）”；
- 必须使用 ConcurrentHashMap：HashMap、Collections.synchronizedMap 等不支持该方法的并发语义，调用会抛 UnsupportedOperationException 或失去线程安全保证。
- mappingFunction 必须无副作用、幂等、快速完成：它可能被多次调用（虽然只有一次生效），若含 IO、锁、修改外部状态，会导致不可预测行为；建议只做纯内存对象创建（如 new Bean()、Collections.unmodifiableList(...)）。
- 避免在 mappingFunction 中再次访问同一 key 的 computeIfAbsent：虽然新版已防死锁，但逻辑上属于设计错误，应重构为先查后构造，或拆分依赖。
- 返回 null 不会被缓存：如果 mappingFunction 返回 null，map 不会存储该映射，下次 get 仍会再次调用函数——这点常被误用，需确保构造逻辑总返回有效对象。
一个典型安全示例
比如按 class 加载定制序列化器：
private final ConcurrentMap<Class<?>, Serializer<?>> serializers = new ConcurrentHashMap<>();
public <T> Serializer<T> getSerializer(Class<T> type) {
return (Serializer<T>) serializers.computeIfAbsent(type, cls -> {
// ✅ 纯构造：无 IO、无锁、不递归调用 computeIfAbsent
if (cls == String.class) return new StringSerializer();
if (cls == Integer.class) return new IntegerSerializer();
return new DefaultSerializer<>(cls);
});
}
