JDK 26 LazyConstant 怎么替代双重检查锁：初始化失败与重试边界

服务启动时不想立刻创建昂贵对象，很多 Java 项目会写一套 volatile + synchronized + 双重检查。这段代码并不长，却很容易把安全发布、空值、异常和重试语义混在一起。JDK 26 的预览 API java.lang.LazyConstant 把一次性延迟初始化做成了标准抽象，但迁移前必须先看清一个边界：常量最多成功初始化一次，计算函数在失败后却可能被后续 get() 再次调用。

变化不只是少写一个 synchronized

传统双重检查锁通常长这样：

final class ClientHolder {
    private static volatile ApiClient client;

    static ApiClient client() {
        ApiClient value = client;
        if (value == null) {
            synchronized (ClientHolder.class) {
                value = client;
                if (value == null) {
                    value = new ApiClient(loadConfig());
                    client = value;
                }
            }
        }
        return value;
    }
}

它依赖 volatile 保证可见性，又依赖内外两次判空避免重复加锁。代码还能工作，但“未初始化”只能借用 null 表示，计算失败是否重试也没有写在抽象层。JDK 26 可以改成：

import java.lang.LazyConstant;

final class ClientHolder {
    private static final LazyConstant CLIENT =
            LazyConstant.of(() -> new ApiClient(loadConfig()));

    static ApiClient client() {
        return CLIENT.get();
    }
}

LazyConstant 是 JDK 26 的预览 API，编译和运行都要启用预览特性，例如使用 --enable-preview --release 26 编译，并在启动时加入 --enable-preview。它适合先在可控服务或组件中试用，不应把预览 API 当成跨多个 JDK 版本稳定不变的接口。

为什么它能安全替代双重检查锁

官方 API 文档给出的并发保证是：多个线程同时调用 get() 时，只会选中一个更新线程执行计算函数，其他线程等待初始化完成；成功初始化与之后读取内容之间建立 happens-before 关系。因此，不需要再手工维护 volatile 字段和同步块。

这里要区分两个概念：

• 最多成功初始化一次：一旦内容写入，后续 get() 永远返回该内容。
• 失败后允许再次计算：如果本次 Supplier 抛出异常，内容没有写入，后续调用可以重新尝试。

所以它不是“计算函数在对象生命周期里最多运行一次”。更准确的说法是：同一时刻只会有一个计算线程，且成功状态只能建立一次。

Supplier 抛异常后会发生什么

假设配置中心短暂不可用，loadConfig() 第一次抛出异常。get() 会把这个 throwable 原样传给当前调用者，LazyConstant 保持未初始化；下一次调用 get() 时，可以再次进入计算。

private static final LazyConstant CLIENT =
        LazyConstant.of(() -> {
            ClientConfig config = loadConfig();
            return new ApiClient(config);
        });

static ApiClient client() {
    try {
        return CLIENT.get();
    } catch (ConfigUnavailableException problem) {
        throw new ServiceStartingException("客户端尚未准备好", problem);
    }
}

这个规则对网络配置、临时凭据和可恢复资源很友好，但也带来副作用风险。Supplier 如果先创建外部资源，随后又抛异常，下一次重试可能再次创建资源。计算逻辑最好满足幂等性，或者把外部资源的提交动作放在所有可失败校验之后。

重试策略应该放在容器外还是 Supplier 内

两种位置的语义不同。把重试放在调用方，单次 get() 失败就会立刻返回，下一次业务请求才触发新计算；把有限重试放进 Supplier，一次 get() 会占用计算线程更久，其他并发调用也会继续等待。

对启动关键配置，可以在 Supplier 内做次数很少、间隔明确的重试；对依赖外部服务且恢复时间不可预测的对象，更适合快速失败，由上层熔断或就绪检查控制下一次调用。不要在 Supplier 里做无上限循环，因为官方明确说明：若计算函数无限阻塞，其他访问同一常量的线程也可能无限等待，API 本身不提供超时或取消。

null、递归和中断三个边界

LazyConstant 不能保存 null

Supplier 返回 null 会触发 NullPointerException。如果“没有值”本身是合法业务结果，应使用 LazyConstant>，让空状态成为明确的数据，而不是初始化标记。

计算函数不能递归读取同一个常量

直接或间接递归调用同一 LazyConstant 会触发 IllegalStateException，且不会完成初始化。多个 LazyConstant 可以形成依赖关系，但依赖图必须无环，例如 B 的 Supplier 读取 A 可以，A 又反向读取 B 就会形成循环。

线程中断不会自动取消初始化

官方文档说明，中断计算线程不会让 get() 自动清除中断标记，也不会自动抛出 InterruptedException。如果 Supplier 调用的是可中断 API，需要在业务代码中明确处理中断和清理。

性能收益需要满足存放方式

初始化完成后，JVM 有机会把内容当作常量折叠，减少后续读取成本。但这个优化依赖 LazyConstant 本身可从 static final 字段，或受信任的 final 字段链稳定到达。把它塞进任意可变容器，不能假设获得同样的优化效果。

还要留意长期引用：LazyConstant 初始化后会强引用内容，只要容器可达，内容就不会被释放。它适合进程级服务、不可变配置和真正的单例资源，不适合把每个租户、每个请求或无限增长的键都做成 LazyConstant。

迁移时按这五项检查

1. 确认旧代码表达的是“一次性延迟值”，不是可刷新缓存。
2. 确认 Supplier 成功时返回非 null，失败副作用可回滚或可幂等重试。
3. 确认依赖关系无环，计算过程没有无限等待。
4. 将 LazyConstant 放在合适的 final 字段上，并评估内容的生命周期。
5. 在预览特性开关下完成并发、异常和服务就绪测试，再决定是否上线。

常见问题

LazyConstant 会缓存异常吗？

不会把异常保存成最终内容。计算函数抛出 throwable 后，当前调用收到异常，常量保持未初始化，后续 get() 可以再次尝试。

能用 isInitialized() 代替 get() 前的判定吗？

isInitialized() 只观察状态，不触发初始化。通常直接调用 get() 更清楚，不要重新写一套“先判断再初始化”的竞态逻辑。

orElse() 会触发 Supplier 吗？

不会。未初始化时它返回传入的备用值；如果其他线程已经完成初始化，则原子地观察并返回常量内容。

它适合替代可定时刷新的配置缓存吗？

不适合。LazyConstant 成功初始化后内容不能删除或替换，可刷新配置应使用版本化快照、原子引用或专门缓存组件。

结语

LazyConstant 真正替代的是“一次性、线程安全、安全发布”的延迟值，而不是所有缓存和重试器。迁移双重检查锁时，最值得审查的不是少了多少同步代码，而是 Supplier 失败后会再次计算、成功内容会长期固定并被强引用这两个边界。