Java computeIfAbsent 递归更新时怎样避免死循环

避免 computeIfAbsent 递归更新问题的关键，不是把 HashMap 换成 ConcurrentHashMap，而是不要在映射计算函数里再次更新同一个 Map。若计算本身依赖其他键，应把依赖求值移到回调外，并单独处理依赖环；不能依赖容器总能替你发现循环。

本文依据 JDK 25 的官方 API 文档，给出一个单线程依赖计算改法，不覆盖所有并发加载器。Map 官方入口：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/Map.html。

先记录重入事实，不把异常当作性能指标

设想一个元数据加载器：计算 A 时需要 B，计算 B 时又访问原缓存。若所有加载都包在同一个 Map 的 computeIfAbsent 中，业务递归就可能把容器重新带入更新状态。即使 A 与 B 是不同键，也不能据此证明回调内更新同一张映射符合契约。

这是原创假设场景，不是线上复盘。排查时建议先记录 Map 的具体实现、JDK 版本、外层键、依赖键与异常堆栈，再找回调经过的调用链。不要先编一个“优化前每秒多少次”的指标；重入规则尚未满足时，吞吐量不能证明写法正确。

图中的缓存 Map 由 computeIfAbsent 关联映射函数，映射函数使用业务加载器，业务加载器读取依赖键。若依赖加载再次更新缓存 Map，就形成需要移除的重入关系；这里描述的是静态调用关系，不是某次运行的线程时序。

同一个API在不同Map中的失败表现不同

Map 的默认实现不保证检测计算函数对映射的修改，也不提供默认的同步或原子性保证。HashMap 的 JDK 25 文档说明，对检测到的回调修改会尽力抛出 ConcurrentModificationException。ConcurrentHashMap 则对可检测到、否则无法完成的递归更新描述 IllegalStateException，并要求计算尽量短小。

所以，标题中的“死循环”不能理解成所有实现都会挂住：有的情况可能抛异常，有的业务递归会不断展开，具体表现还受版本与调用关系影响。正确修复应消除违规重入，而不是捕获容器异常后原样重试，或者指望不同哈希分布让问题暂时消失。

实现文档：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/HashMap.html；https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html。文档中的可检测条件也不等于通用业务环检测器。

把依赖计算移出映射回调

下面完整示例仅供单线程使用：Resolver 持有依赖图 graph、完成缓存 completed、计算中集合 active，以及计数 computedNodes。只有完整算出某键的值才写入 completed；active 表示当前递归路径，不是“曾经访问过”的全部节点。

代码可独立保存为 DependencyDemo.java，在 JDK 25 环境自行试用。本文没有编译、运行或压测；后文结果均为对示例逻辑的推导。

import java.util.HashMap;
import java.util.HashSet;
import java.util.List;
import java.util.Map;
import java.util.Set;

public class DependencyDemo {
    // 仅供单线程使用；依赖图由本例的不可变Map/List构成。
    static final class Resolver {
        private final Map> graph;
        private final Map completed = new HashMap();
        private final Set active = new HashSet();
        private int computedNodes;

        Resolver(Map> graph) {
            this.graph = graph;
        }

        int resolve(String key) {
            Integer cached = completed.get(key);
            if (cached != null) {
                return cached;
            }
            List dependencies = graph.get(key);
            if (dependencies == null) {
                throw new IllegalArgumentException("unknown key: " + key);
            }
            // 当前递归路径已包含该键，拒绝继续；不等待集合自身发现递归。
            if (!active.add(key)) {
                throw new IllegalStateException("dependency cycle at " + key);
            }
            try {
                ++computedNodes;
                int total = 1;
                for (String dependency : dependencies) {
                    // 递归不位于任何Map计算回调中；溢出也明确报错。
                    total = Math.addExact(total, resolve(dependency));
                }
                completed.put(key, total);
                return total;
            } finally {
                // 失败也移除当前路径标记，不缓存本节点的半成品。
                active.remove(key);
            }
        }
    }

    public static void main(String[] args) {
        Resolver acyclic = new Resolver(Map.of(
                "A", List.of("B", "C"),
                "B", List.of("D"),
                "C", List.of("D"),
                "D", List.of()));
        // 计数是本次示例计算次数，不是吞吐量或耗时测量。
        System.out.println("A=" + acyclic.resolve("A"));
        System.out.println("computedNodes=" + acyclic.computedNodes);

        Resolver cyclic = new Resolver(Map.of(
                "X", List.of("Y"), "Y", List.of("X")));
        try {
            cyclic.resolve("X");
        } catch (IllegalStateException error) {
            // 显式报告业务依赖环，不捕获后立即无限重试。
            System.out.println(error.getMessage());
        }
    }
}

这里不再调用 computeIfAbsent。先查询完成值，再用 active 检测当前路径是否重复；依赖成功计算后才缓存本键，finally 负责移除路径标记。异常时已经完成的其他节点可以留在缓存，但当前失败节点不会以半成品写入。这个取舍适用于依赖图和计算规则在 Resolver 生命周期内保持稳定的场景。

比较结构指标，再讨论耗时

先给出可复核的静态基准：无环图有 A、B、C、D 四个不同节点，B 和 C 都依赖 D。按照代码定义，节点值为1加上各依赖的值；因此 D为1，B与C各为2，A为5。A的值不是不同节点数量，D的值在两条依赖中分别参与求和。

这些不是实测数据，也不能推出任何性能提升百分比。若团队进一步比较耗时，应固定同一无环图、同一计算规则和冷热缓存条件，记录依赖计算次数、失败次数及延迟分布；对环单独记录能否明确终止，而不把异常路径混入成功吞吐量。对于非常深的无环图，递归仍可能耗尽线程栈，需另行采用显式栈或拓扑方式处理。

并发共享场景不能直接照搬

示例中的 HashMap、HashSet 和计数均未同步，不能跨线程共享。简单地把 completed 换成 ConcurrentHashMap，也不会让 active、计数或整个递归协议自动线程安全。并发下若将计算移到缓存外再 putIfAbsent，还需接受或防止重复计算，并明确副作用能否重复发生。

若选择用 Future 表示同键正在加载，也必须设计失败清理、取消和依赖环处理，避免线程等待自己或相互等待；本文没有提供这样的并发实现，不承诺一次加载或全局无死锁。

只递归读取已有键可以吗？

与回调内递归更新不是同一个问题。要确认读取不会经由其他方法触发缺失键加载与写入，不能只看表面方法名。

给方法加 synchronized 就能解决吗？

锁并不消除业务依赖环，也不会让回调内更新同一 Map 成为符合约定的写法。仍应先拆开计算与缓存更新职责。

异常被捕获后可以无限重试吗？

不应该。输入依赖与调用结构不变时，原样重试通常不能消除原因；应先修正重入或依赖定义，并为重试设定明确条件。

对这个问题，最有用的改动是把“缺失时算一下”的简写还原成明确协议：完成值缓存、当前路径检测、成功后写入和失败后清理。先让终止条件与更新边界可解释，再讨论并发与性能。