Java 25 Stable Values 怎么避免懒加载并发重复初始化：候选缓存与失效边界

服务启动时把远程配置、规则表和本地默认值拼成一个对象，最容易踩的坑不是“懒加载没生效”，而是多个请求同时进来时把同一份配置算了好几遍。Java 25 的 StableValue 预览 API 把“最多设置一次”写进了类型语义，适合承载这类只初始化、不主动失效的结果。

先把“只初始化一次”和“可以刷新”分开

配置对象如果在进程生命周期内只需要成功构建一次，传统写法往往是 volatile 字段加双重检查，或者把同步锁藏在一个供应函数里。代码能工作，但调用方还得自己确认可见性、竞态和异常后的状态。

用 StableValue.supplier 写一个懒加载配置

先看最小用法。StableValue.supplier 接收一个普通 Supplier，返回的也是 Supplier。第一次成功调用时，结果被记录；之后的调用直接观察已经设置的内容。

import java.util.concurrent.atomic.AtomicInteger;
import java.util.function.Supplier;

public class StableConfigDemo {
    private static final AtomicInteger LOAD_COUNT = new AtomicInteger();

    private static final Supplier CONFIG =
            java.lang.StableValue.supplier(() -> {
                LOAD_COUNT.incrementAndGet();
                return AppConfig.loadFromFile("/etc/demo/app.properties");
            });

    public static void main(String[] args) {
        AppConfig first = CONFIG.get();
        AppConfig second = CONFIG.get();

        if (first != second || LOAD_COUNT.get() != 1) {
            throw new AssertionError("config was not initialized once");
        }
    }
}

这个例子里的“稳定”不是对象内部字段自动变成不可变，而是 holder 记录的引用只会成功设置一次。AppConfig 自己仍然应该设计成不可变对象，至少不要让外部调用方拿到可随意修改的内部集合。

并发竞争时，真正要检查的是成功调用次数

多个线程同时第一次调用 CONFIG.get()，竞争线程会等待正在计算的调用；成功计算的结果被记录后，其他线程读取同一结果。验收时不要只看“所有请求都返回了”，还要给底层加载器加一个计数器，确认成功构建次数确实为 1。

ExecutorService pool = Executors.newFixedThreadPool(8);
List> futures = new ArrayList();
for (int i = 0; i  future : futures) {
    if (future.get() != expected) {
        throw new AssertionError("different config instance observed");
    }
}
pool.shutdown();

这里不要把“只创建一个对象”扩大解释成“所有并发副作用都自动安全”。supplier 内部如果还要写日志、创建临时文件或更新外部系统，仍要单独审查这些副作用；StableValue 只解决稳定值的设置和可见性语义。

异常不会自动变成熔断状态

加载器第一次抛出异常时，失败结果不会被记录成稳定内容。下一次调用仍可能再次执行 supplier，这对临时文件不可读、配置中心短暂超时的场景很有用，但也意味着故障持续时会重复打外部依赖。

AtomicInteger attempts = new AtomicInteger();
Supplier retryable = java.lang.StableValue.supplier(() -> {
    int attempt = attempts.incrementAndGet();
    if (attempt == 1) {
        throw new IllegalStateException("config source temporarily unavailable");
    }
    return AppConfig.defaults();
});

try {
    retryable.get();
} catch (IllegalStateException expected) {
    // 第一次失败不占用稳定值
}
AppConfig recovered = retryable.get();

如果业务要求“失败三次后五分钟内不再访问”，请在 supplier 外面增加重试预算或熔断器，别依赖 StableValue 猜测失败策略。稳定值一旦成功写入，也没有对应的 remove 或 reset 操作。

预览 API 和内存驻留边界不能漏掉

Java SE 25 文档把 StableValue 标记为 Preview。使用时需要在编译和运行阶段都打开预览选项，例如：

javac --enable-preview --release 25 StableConfigDemo.java
java --enable-preview StableConfigDemo

生产项目要把 JDK 版本、编译参数和运行参数一起写进构建配置，避免本地能编译、容器启动失败。还要留意内存：稳定值的内容会被强引用持有，直到稳定值本身被回收。把带有大字典、连接对象或租户全集的对象塞进去，实际上就选择了长生命周期。

常见问题

StableValue 能像缓存一样清除吗？

不能。它表达的是最多设置一次的内容，没有主动清除或替换操作。需要刷新时应使用明确支持失效和更新的缓存结构。

supplier 抛异常后还会重试吗？

可以再次尝试，因为异常不会记录成内容。但它不提供退避和熔断；是否重试、重试几次由业务代码负责。

并发调用会执行多次加载逻辑吗？

对成功计算而言，StableValue.supplier 保证底层 supplier 至多成功调用一次；竞争线程会等待并复用成功结果。外部副作用仍需自行保证幂等。

Java 21 项目能直接使用 StableValue 吗？

不能把 Java 25 预览 API 当作 Java 21 标准库能力。需要先升级到支持该 API 的 JDK，并在构建和运行时打开预览选项。

上线前的选择检查

如果对象只需要在进程内构建一次、成功后长期复用，而且失败可以由调用方再次触发，StableValue 的语义很贴切。若需求里出现“刷新”“淘汰”“按版本替换”或“失败后静默一段时间”，那已经超出了稳定值的职责。先把生命周期写清楚，再决定是否采用这个 Java 25 预览 API。