Java ConcurrentHashMap计算函数避免重复初始化的写法

我在给本地配置、连接池客户端做按 key 懒加载时，最容易踩到的坑是把“先 get、再 new、最后 put”当成完整方案。多个线程同时发现 key 不存在，就可能各自完成一次昂贵初始化，最后只有一个对象留在 Map 里。更稳妥的写法是把初始化函数直接交给 ConcurrentHashMap.computeIfAbsent。

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

对于同一个缺失 key，computeIfAbsent 会把“检查、计算、建立映射”作为一次原子调用处理；key 已有非空值时不会调用计算函数。它解决的是按 key 的重复初始化，不等于允许把任意耗时任务长期放在 Map 的更新路径里。

一、先判断计算函数是否适合这个场景

ConcurrentHashMap 适合多个线程共享读取、按 key 更新的场景。它不允许 null key 和 null value，因此 null 可以表示“当前没有结果”。如果你的需求是“同一个用户编号只创建一次客户端”“同一个租户只加载一次规则”，计算函数和 key 的粒度就很匹配。

相反，如果函数要访问外部服务、等待很长时间，或者要同时修改这张 Map 的其他 key，就应先重新设计。官方文档明确提醒：计算期间其他更新可能被阻塞，函数要短小，而且不能在计算中修改这张 Map。

二、把按 key 的初始化放进 computeIfAbsent

最小实现只需要保留一个共享 Map，并让 Lambda 根据 key 创建对象。下面的 createClient 代表一次真正的初始化，调用方拿到的始终是当前映射值。

import java.util.concurrent.ConcurrentHashMap;

final class ClientRegistry {
    private final ConcurrentHashMap clients = new ConcurrentHashMap();

    ApiClient clientFor(String tenantId) {
        // 同一个 tenantId 的首次初始化由 Map 的计算操作协调。
        return clients.computeIfAbsent(tenantId, this::createClient);
    }

    private ApiClient createClient(String tenantId) {
        // 初始化函数只创建并完整配置对象，不回写 clients。
        return new ApiClient(tenantId, 3000);
    }
}

record ApiClient(String tenantId, int timeoutMillis) {}

注意“只成功一次”是针对同一个 key 的映射计算，不是说整个 Map 只能同时初始化一个 key。不同 key 可以有并发计算，但哈希冲突和内部更新仍可能带来等待，所以不要把它理解成无限并行。

三、处理 null、异常和失败重试

计算函数返回 null 时，Map 不会保存该 key；函数抛出运行时异常或错误时，异常会交给调用方，映射也不会建立。这种语义适合“加载失败后下一次允许重试”，但前提是初始化函数本身没有不可重复的外部副作用。

ApiClient clientFor(String tenantId) {
    return clients.computeIfAbsent(tenantId, key -> {
        // 先把外部响应转换成完整对象，失败时抛出异常而不是缓存半成品。
        ApiClient client = loadFromConfig(key);
        if (client == null) {
            throw new IllegalStateException("missing client config: " + key);
        }
        return client;
    });
}

private ApiClient loadFromConfig(String tenantId) {
    // 示例只表达失败边界；真实代码应记录可检索的 key 和原因。
    return new ApiClient(tenantId, 3000);
}

不要用返回 null 表示“暂时失败但稍后继续共享同一个加载过程”，因为它不会留下占位状态。若必须让并发请求共同等待一次加载，可以把 CompletableFuture 或自定义状态对象作为 value，并明确失败后的移除和重试策略。

四、控制计算函数的耗时与副作用

有三个实用边界。第一，函数内不要调用 clients.put、remove 或再次对同一个 Map 做递归计算，避免递归更新和难以判断的锁等待。第二，不要在函数里做没有超时的网络访问；可以存放 Future，再由 Future 负责等待和超时。第三，初始化完成后再返回对象，不能先放入一个字段未准备好的可变对象。

如果业务必须记录“这次是不是首次创建”，不要从返回值是否为空推断，因为已有值和新计算值都可能是非空。可以让初始化对象携带状态，或在调用前后用独立的指标记录；不要把一个跨线程共享的可变布尔标记塞进 Lambda。

五、用检查清单确认最终写法

• key 是否真的是你要保证单次初始化的边界？
• value 是否永远非 null，失败是否应该让下一次重试？
• 计算函数是否短小、可重复、不会回写同一 Map？
• 耗时加载是否需要 Future、超时、失败清理和监控？
• 是否把“避免重复初始化”和“限制所有线程总并发”分开设计？

相关问题

computeIfAbsent 能保证不同 key 的函数同时执行吗？

它主要保证同一个 key 的原子计算，不应把不同 key 的执行时序当作业务契约。实际吞吐还会受到哈希分布、冲突和函数耗时影响。

初始化失败后会不会缓存 null？

不会。返回 null 不建立映射；抛异常也不会留下该次映射，后续调用可以重新尝试，但应避免每次都重复触发昂贵或有副作用的外部操作。