Java Map.computeIfAbsent 为什么不能在映射函数中递归修改

排查 Java 集合初始化异常时，Map.computeIfAbsent 里递归调用自身很容易被误认为是“缓存递归”。真正的问题是：映射函数执行完之前，外层键的结果还没有完成写回；如果函数再次修改同一个 Map，甚至再次计算同一个 key，就破坏了这个方法的计算边界。

官方地址：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/Map.html

处理原则是把映射函数当成只负责计算并返回值的函数。递归结果先放在外部计算域，等依赖关系全部算完后，再由独立阶段统一写入 Map。不要在 mappingFunction 内调用当前 Map 的 put、remove 或再次调用同一个 computeIfAbsent。

• 同一个 key 递归：外层结果尚未写回，内层仍可能读到缺失值，递归没有稳定出口。
• 修改其他 key：即使不递归同一个 key，也属于在映射计算期间修改当前 Map，结果依赖具体实现。
• 只返回新对象：这是 computeIfAbsent 期望的使用方式，返回后由 Map 完成写入。

先确认触发信号：递归的是谁，修改的是谁

值工厂里最危险的写法通常有两类。一类是同键递归，外层正在计算 node，函数又请求 node；另一类是函数内部先计算一个值，再用 put 把它或其他键写入当前 Map。两者都让映射函数承担了“计算”和“修改容器”两个职责。

Map cache = new HashMap();

// 反例：同一个 key 的外层结果尚未写回，函数又请求同一个 key。
int value = cache.computeIfAbsent("node", key -> {
    // 这里不是读取已经完成的缓存，而是重新启动同一个计算。
    return cache.computeIfAbsent(key, ignored -> 1) + 1;
});

看到 ConcurrentModificationException、IllegalStateException 或递归栈增长时，先记录 Map 的具体实现、外层 key、函数内是否调用过写方法，以及异常发生前是否已经插入过其他键。不要先把异常名称当成跨实现的统一契约。

按 Map 的计算边界定位原因

Java SE 的 Map 文档把默认语义描述成：先读取 key；如果没有值，就调用映射函数；函数返回非空值后才写入 Map。文档同时明确要求映射函数不要在计算期间修改当前 Map。也就是说，函数内部不能假设外层调用已经把当前 key 放进了 Map。

因此，同键递归没有“命中正在计算的值”这一步。它会再次进入缺失分支；如果映射函数始终继续递归，就没有自然的收敛条件。即便递归请求的是另一个 key，函数期间的 put 或 remove 也会让当前 Map 的结构在一次计算中间改变。

根据实现识别异常差异

Map 接口只给出边界和建议，不保证每个实现都以同一异常报告。普通非并发实现可以尽力检测映射函数修改 Map，并抛出 ConcurrentModificationException；并发实现如果检测到递归会让计算无法结束，则可以抛出 IllegalStateException。这也是为什么换成 ConcurrentHashMap 不能把副作用写法变成合法写法。

Map cache = new HashMap();

try {
    // 映射函数只返回值，不在当前 Map 上执行 put/remove。
    Integer value = cache.computeIfAbsent("orders", key -> 3);
    System.out.println(value);
} catch (RuntimeException ex) {
    // 记录实现类型和 key，便于区分 Map 约束与业务异常。
    System.err.println(cache.getClass().getName() + " key=orders " + ex);
}

复查时重点看三件事：第一，函数是否捕获异常后又继续写入；第二，异常前是否产生了其他 key 的部分结果；第三，业务是否错误地依赖某个实现“刚好抛出”的异常。异常只是发现违规边界的信号，不应成为流程控制协议。

把副作用移出映射函数

如果递归关系确实需要缓存，先让递归函数返回结果，再在调用方完成一次明确写入。这样计算过程不会让 computeIfAbsent 同时承担依赖展开、容器变更和异常回滚。

Map cache = new HashMap();

// 计算函数只从输入和已准备好的依赖得到结果，不修改 cache。
Function calculate = key -> key.length();

String key = "orders";
Integer computed = calculate.apply(key);
// 计算成功后才写入；写入阶段与递归计算阶段分开。
cache.putIfAbsent(key, computed);

System.out.println(cache.get(key));

对真正的依赖图，可以使用独立的临时结果表承载“已计算”和“正在计算”状态：遇到正在计算的节点就明确返回循环依赖错误，遇到已完成节点才复用结果，最后再把成功结果提交到最终 Map。这个设计比依赖异常类型更稳定。

回滚路径、告警确认与复盘项

修复上线前先清理已经产生的部分缓存，避免旧的半成品继续被读取。若初始化失败，宁可让本次调用返回明确错误，也不要把不完整对象写进最终 Map。日志至少带上 Map 实现名、根 key、当前递归节点和“计算/提交”阶段；监控上则关注递归深度、失败次数与缓存部分写入数量。

常见问题

只递归读取其他 key，也一定会报错吗？

不应依赖“必然报错”或“必然成功”。只要映射函数修改了当前 Map，就违反了接口建议；不同实现的检测方式和结果可能不同。把递归计算放到外部状态中更可控。

computeIfAbsent 适合做什么？

它适合把一个缺失 key 映射成一个新对象，例如创建集合或准备一次性值。映射函数应尽量短小、无副作用，并直接返回要保存的对象。

最终判断可以压缩成一句话：computeIfAbsent 的函数是“算值”，不是“改 Map”。递归依赖需要单独的计算状态和提交阶段，普通 Map 与并发 Map 的异常差异只能帮助定位，不能替代这个设计边界。