Java Map.computeIfAbsent 返回 null 怎么处理：缓存未命中、递归更新与并发边界

订单详情缓存偶尔出现“查过一次，下一次还要查数据库”的现象，代码却没有抛异常。排查后常见的线索是：映射函数在数据不存在时返回了 null，而 Map.computeIfAbsent 把这个结果解释成“不要写入映射”。

先看一个容易被忽略的 null 结果

下面的示例模拟商品不存在时的查询。第一次调用没有异常，第二次却再次进入查询函数，这不是缓存失效，而是 computeIfAbsent 的约定：只有计算结果非 null，才会建立新的键值映射。

Map cache = new HashMap();

Product product = cache.computeIfAbsent(1001L, id -> loadFromDatabase(id));
System.out.println(product); // null
System.out.println(cache.containsKey(1001L)); // false

Product again = cache.computeIfAbsent(1001L, id -> loadFromDatabase(id));
// loadFromDatabase 又会被调用

这里的 containsKey 结果才是关键证据：Map 里没有 1001 这个键。不要把“函数返回了 null”理解成“Map 里写入了一个 null 值”。

把“没有数据”设计成可缓存的结果

如果数据库中的空结果很稳定，反复查询反而会放大压力。比较直接的做法是缓存一个不可混淆的哨兵对象；读取时再把哨兵转换成业务上的空结果。

record Product(long id, String name) {}
record Lookup(Product value) {
    static Lookup missing() { return new Lookup(null); }
    boolean isMissing() { return value == null; }
}

Map cache = new HashMap();
Lookup result = cache.computeIfAbsent(id, key -> {
    Product found = loadFromDatabase(key);
    return new Lookup(found); // 对象本身非 null，空结果也能被缓存
});

if (result.isMissing()) {
    return Optional.empty();
}
return Optional.of(result.value());

生产代码里也可以使用 Optional 作为 Map 的值，但要先统一团队约定：Map 里存的是 Optional.empty()，还是业务封装对象。不要一部分调用方期待 null，另一部分调用方期待 Optional。

映射函数里不要再次改同一个 Map

computeIfAbsent 的函数应该只负责根据键计算值。把“顺手写入另一个键”的逻辑塞进去，代码看似省了一行，实际会引入递归更新和可读性问题。

Map counts = new HashMap();

// 不建议：计算 a 时又更新同一个 Map
counts.computeIfAbsent("a", key -> {
    counts.put("b", 2);
    return 1;
});

对普通 HashMap，这种写法容易让维护者误判更新顺序；对 ConcurrentHashMap，映射函数执行期间再次修改同一张表还可能触发递归更新异常。需要预热多个键时，应该在外层按明确顺序填充，或者先计算普通对象，再一次性合并。

ConcurrentHashMap 下要检查什么

换成 ConcurrentHashMap 只解决了 Map 结构本身的并发访问问题，不会自动让映射函数变成事务。函数可能因为竞争被多个线程触发，不能把它当成只执行一次的副作用容器。

ConcurrentHashMap cache = new ConcurrentHashMap();

Product value = cache.computeIfAbsent("sku-1001", key -> {
    // 这里应尽量只做可重复、边界清楚的查询或构造
    return loadFromDatabase(key);
});

• 函数不要修改同一个 ConcurrentHashMap 的其他映射。
• 函数内部访问外部服务时，要设置超时并控制重试，否则锁定的计算路径会拖长。
• 如果加载动作必须全局只发生一次，应增加独立的请求合并或任务状态设计，别只依赖 Map 方法名。

另外，映射函数抛出异常时，通常不会留下成功映射；下一次调用仍可能再次尝试。因此，失败是否缓存也要由业务结果类型明确表达，而不是依赖异常路径碰巧形成的行为。

用小测试固定边界

这类问题适合用三个测试把语义钉住：null 不写入、空结果可命中、计算函数不递归更新。

@Test
void nullResultDoesNotCreateMapping() {
    Map map = new HashMap();
    map.computeIfAbsent("missing", key -> null);
    assertFalse(map.containsKey("missing"));
}

@Test
void sentinelMakesMissingResultCacheable() {
    Map map = new HashMap();
    map.computeIfAbsent("missing", key -> Lookup.missing());
    assertTrue(map.containsKey("missing"));
    assertTrue(map.get("missing").isMissing());
}

如果映射函数连接数据库或远程服务，测试里再加一个调用计数器，分别验证成功、明确空结果和异常三条路径。这样以后把 HashMap 换成 ConcurrentHashMap 时，行为变化会更早暴露。

常见问题

computeIfAbsent 返回 null 会抛 NullPointerException 吗？

一般不会。返回 null 表示不建立新的映射，但具体 Map 实现对 null 键和值的支持仍需遵守各自约定。

Map 里能不能直接缓存 null？

可以用 put 的 Map 实现允许 null 值，但 computeIfAbsent 不会把计算得到的 null 当作可缓存值。

ConcurrentHashMap 为什么不建议映射函数里再 put？

计算函数可能处于该键的更新流程中，再改同一张表会造成递归更新、异常或难以推断的副作用。

空查询结果一定要缓存吗？

不一定。数据变化频繁时可以设置短 TTL 或不缓存；重点是用明确策略决定，而不是让 null 的默认语义替你做决定。

把 null 语义写进缓存契约

使用 computeIfAbsent 前，先回答两个问题：空结果是否需要缓存，以及计算函数是否包含不可重复副作用。需要缓存空结果就返回非 null 的业务封装；需要并发加载就把超时、重试、失败状态单独设计。这样一来，Map 只是存储工具，真正的缓存行为仍由业务契约掌控。