Java ConcurrentHashMap computeIfAbsent 里为什么不能递归更新同一键

这个异常通常不是锁没加对，而是把“计算一个缺失值”和“再次修改同一张并发 Map”写进了同一个 computeIfAbsent 回调。ConcurrentHashMap 要求映射函数在计算期间不要修改该 Map；如果实现能够判断出递归更新可能永远无法完成，就会抛出 IllegalStateException，当前键的映射也不会因此建立。

为什么同一键的递归更新会被判定为不安全

可以把一次调用想成“为键 A 预留一次计算机会”：键不存在时，Map 进入计算状态，执行映射函数，函数返回非空值后才建立映射。如果函数还没有返回，就再次要求 Map 计算键 A，内层调用必须等外层完成，外层又必须等内层返回，等待链无法闭合。

这也是 JDK API 使用 IllegalStateException 描述该情况的原因。它不是普通的业务异常，也不是说 Lambda 不能递归，而是说递归更新触碰了这个原子计算的提交边界。官方文档同时要求计算函数短小，并且不要在计算期间修改该 Map。

先区分同键递归、不同键更新和普通递归

下面的例子故意只展示问题边界。它没有依赖多线程，单线程也足以触发同键递归：

import java.util.concurrent.ConcurrentHashMap;

public class RecursiveComputeDemo {
    public static void main(String[] args) {
        ConcurrentHashMap cache = new ConcurrentHashMap();

        // 映射函数尚未返回，就再次请求同一个键的计算。
        cache.computeIfAbsent("A", key -> {
            // 这个更新嵌套在外层原子计算中，可能被判定为递归更新。
            return cache.computeIfAbsent(key, ignored -> 1);
        });
    }
}

需要注意三种操作不是一回事：

“没有多线程”并不能证明写法安全；这里的问题首先是回调的重入关系，其次才是并发可见性。若映射函数自身抛出运行时异常，当前映射也不会被建立，调用方应按失败路径处理，而不是把半成品继续放进缓存。

把计算和缓存发布拆成两个阶段

如果业务对象存在父子依赖或表达式引用，不要用共享缓存承担递归调用栈。更稳妥的做法是：递归期间只操作本次请求的 local 和 visiting，发现环时立即报出可解释的错误；递归成功后，再把最终值写入共享缓存。

import java.util.HashMap;
import java.util.HashSet;
import java.util.Map;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;

public class TwoPhaseResolver {
    private final ConcurrentHashMap cache = new ConcurrentHashMap();

    public int resolveAndPublish(String key) {
        // 每次解析拥有自己的访问集合，避免把递归状态塞进共享 Map。
        Map local = new HashMap();
        Set visiting = new HashSet();
        int value = resolve(key, local, visiting);

        // 计算完成后才进入共享缓存，竞争时保留先发布的值。
        return cache.putIfAbsent(key, value) == null ? value : cache.get(key);
    }

    private int resolve(String key, Map local,
                        Set visiting) {
        Integer saved = local.get(key);
        if (saved != null) {
            return saved;
        }
        if (!visiting.add(key)) {
            // 同一请求再次遇到 key，明确报告循环依赖。
            throw new IllegalArgumentException("循环依赖: " + key);
        }

        int value = key.length(); // 示例中的纯计算，真实项目替换为业务解析。
        visiting.remove(key);
        local.put(key, value);
        return value;
    }
}

这个示例的关键不在于 putIfAbsent 能消除所有重复计算，而在于共享 Map 的写入发生在递归结束之后。若项目需要多个键一起发布，应先形成完整的局部结果，再统一设计发布策略；不要在某个键的 computeIfAbsent 回调里偷偷写其他键。

用检查清单选择正确的替代写法

另外，ConcurrentHashMap 不允许 null 键和值；如果计算结果可能为空，应把“缺失”“计算失败”和“合法空结果”用独立状态表达。不要用返回 null 来掩盖递归失败，也不要为了绕开异常把共享 Map 换成普通 HashMap 后继续并发访问。

相关问题

computeIfAbsent 的映射函数会执行几次？

对缺失键，ConcurrentHashMap 的契约是一次调用中至多为该键应用一次函数；函数若抛出异常，映射不会建立。不要把副作用操作放进函数里来“顺便执行”。

只调用 get 会不会触发这个异常？

单纯读取不是更新操作，通常不会形成同键递归；但如果读取结果又驱动回调继续写同一 Map，仍应按完整调用链检查重入关系。

为什么不用 synchronized 包住递归调用？

加锁不能改变 computeIfAbsent 对映射函数的约束，也不能让未完成的外层计算自动拥有内层结果。先拆开计算与发布，通常比扩大锁范围更容易验证。

排查这类异常时，先找出映射函数内部的所有 Map 写操作，再确认递归状态是否应属于本次请求。只要共享缓存只负责保存已经算完的值，computeIfAbsent 的原子语义才不会和业务递归互相缠住。