Map.computeIfAbsent 并发修改异常如何避免？

Question

在高并发场景下，使用 `Map.computeIfAbsent` 方法时，若传入的 mappingFunction 触发了对当前 Map 的进一步读写操作（如嵌套调用 compute、put 等），可能导致 `ConcurrentModificationException` 或死锁。尽管 `computeIfAbsent` 保证方法级别的线程安全（如使用 `ConcurrentHashMap`），但它不支持递归或重入式修改。常见问题示例如：在 `computeIfAbsent` 的 lambda 中再次调用 `computeIfAbsent` 形成循环依赖，或在计算函数中修改了同一 map 的其他条目，引发内部结构不一致。如何正确避免此类并发修改异常，确保线程安全与操作原子性？

Answer 1

1. 问题背景与核心概念解析

在高并发Java应用中，Map.computeIfAbsent 是一个常用的原子操作方法，尤其在使用 ConcurrentHashMap 时被广泛用于缓存、懒加载等场景。该方法保证在多线程环境下对单个键的“检查-计算-插入”过程是线程安全的。

然而，其线程安全性仅限于当前操作的键。若在传入的 mappingFunction 中再次对同一 Map 执行读写操作（如嵌套调用 computeIfAbsent、put、get 等），则可能引发以下问题：

• ConcurrentModificationException：某些非并发 Map 实现（如 HashMap）在迭代过程中被修改会抛出此异常；
• 死锁或活锁：在 ConcurrentHashMap 中，多个线程在不同桶上持有锁并相互等待，形成循环依赖；
• 数据不一致或无限递归：嵌套调用导致状态未完成时又被触发，破坏内部结构一致性。

2. 典型错误示例分析

以下代码展示了常见的误用模式：

ConcurrentHashMap<String, Object> cache = new ConcurrentHashMap<>();

Object getValue(String key) {
    return cache.computeIfAbsent(key, k -> {
        // 错误：在 mappingFunction 中再次调用 computeIfAbsent
        if (k.equals("A")) {
            return cache.computeIfAbsent("B", this::expensiveComputation);
        }
        return expensiveComputation(k);
    });
}

上述代码在高并发下可能导致：

问题类型	触发条件	后果
死锁	线程T1持A锁请求B，线程T2持B锁请求A	程序挂起
递归调用栈溢出	循环依赖无终止条件	StackOverflowError
性能退化	频繁重试CAS失败	CPU飙升

3. 深层机制剖析：ConcurrentHashMap 的分段锁与 CAS 原理

ConcurrentHashMap 在 JDK 8+ 使用 synchronized 对每个桶（bin）加锁，而非全局锁。当调用 computeIfAbsent 时，JVM 会对对应桶加锁，确保该桶上的操作原子性。

但关键在于：mappingFunction 执行期间，锁仍未释放。因此，若在函数内访问其他键，可能尝试获取另一个桶的锁，从而与其他线程形成交叉等待。

Mermaid 流程图展示两个线程间的潜在死锁路径：

graph TD
            A[线程T1: computeIfAbsent(A)] --> B[获取桶A的锁]
            B --> C[执行mappingFunction]
            C --> D{调用 computeIfAbsent(B)}
            D --> E[尝试获取桶B的锁]

            F[线程T2: computeIfAbsent(B)] --> G[获取桶B的锁]
            G --> H[执行mappingFunction]
            H --> I{调用 computeIfAbsent(A)}
            I --> J[尝试获取桶A的锁]

            E -- 等待T2释放B锁 --> J
            J -- 等待T1释放A锁 --> E

4. 正确规避策略与设计模式

为避免上述问题，应遵循以下原则：

1. 禁止在 mappingFunction 中直接修改当前 Map：包括 put、remove、compute 等操作；
2. 拆分逻辑层级：将复杂依赖关系前置处理或延迟到外部协调；
3. 使用双重检查 + 显式同步控制：适用于需动态初始化且存在依赖的场景；
4. 引入外部协调器或服务层：如使用 ForkJoinPool.commonPool() 异步加载，避免阻塞主线程；
5. 采用不可变中间对象过渡：先计算结果，再提交更新；
6. 利用 CompletableFuture 实现异步级联加载，解耦依赖计算过程。

5. 推荐解决方案示例

以下是基于 CompletableFuture 的安全实现方式：

ConcurrentHashMap<String, CompletableFuture<Object>> asyncCache = new ConcurrentHashMap<>();

public CompletableFuture<Object> getOrComputeAsync(String key) {
    return asyncCache.computeIfAbsent(key, k -> CompletableFuture.supplyAsync(() -> {
        // 安全地执行耗时计算，可包含跨 key 查询（但不应写回同一 map）
        if (k.equals("A")) {
            return getValueFromExternalService("A");
        }
        return expensiveComputation(k);
    }));
}

该方案优势：

• 避免在同步上下文中修改 map；
• 利用异步执行解除阻塞依赖；
• 天然支持级联加载和超时控制；
• 提升系统吞吐量与响应性。

6. 监控与诊断建议

在生产环境中，可通过以下手段监控此类风险：

监控项	工具/方法	检测目标
线程阻塞时间	JFR (Java Flight Recorder)	长时间等待锁
CAS 失败频率	自定义指标埋点	map 冲突热点
Stack trace 抓取	Async-Profiler	递归调用链
GC 与 CPU 使用率	Prometheus + Grafana	异常资源消耗

同时建议启用 JVM 参数 -XX:+PreserveFramePointer 以提升 native stack 可读性。