本文介绍在多线程环境下安全初始化并复用 ListenableFuture 的正确方式，解决因 synchronized 方法过早释放锁导致的重复异步计算问题，核心采用 volatile + 双重检查锁（DCL）模式。
本文介绍在多线程环境下安全初始化并复用 `listenablefuture` 的正确方式，解决因 `synchronized` 方法过早释放锁导致的重复异步计算问题，核心采用 volatile + 双重检查锁（dcl）模式。
在使用 ListenableFuture 实现延迟、异步的“获取或创建”逻辑时，一个常见误区是直接对返回 Future 的方法加 synchronized——这只能保证方法入口互斥，却无法保护 Future 内部真正耗时的异步任务（如 buildResult()）不被并发触发。正如示例所示：第一个线程返回 Future 后立即释放锁，第二个线程随即进入并重复调用 createResult()，最终导致多次执行 buildResult()，违背单例初始化语义。
正确的解决方案是将同步粒度从“方法调用”下沉到“Future 实例的首次创建”，即采用 双重检查锁（Double-Checked Locking, DCL） + volatile 引用 模式：
private volatile ListenableFuture<result> resultFuture;
public ListenableFuture<result> getOrCreateResult() {
// 第一次检查（无锁）：快速命中已初始化的 Future
if (resultFuture != null) {
return resultFuture;
}
// 加锁后再次检查（防止竞态）
synchronized (this) {
if (resultFuture == null) {
resultFuture = createResult(); // 仅在此处真正启动异步链
}
}
return resultFuture;
}</result></result>
✅ 关键设计说明：
-
volatile修饰resultFuture是必需的：它禁止指令重排序，并确保所有线程能立即看到该引用的最新值（JMM 保证），避免因 CPU 缓存不一致导致某线程读到未完全构造的Future对象； - 两次
null检查缺一不可：第一次减少锁竞争开销，第二次防止多个线程同时通过第一层检查后重复初始化； -
createResult()仅被调用一次，其内部完整的异步链（futureComputation1 → futureComputation2 → ... → buildResult()）也只会执行一遍，后续所有调用均共享同一个Future实例及其结果。
⚠️ 注意事项：
- 不要将
synchronized应用于返回Future的方法本身（如原代码），否则无法控制异步任务的执行时机； - 若
createResult()可能抛出异常，建议增强健壮性：捕获异常后置resultFuture = null（或使用AtomicReference封装状态），避免失败后永久阻塞后续请求； - 在更复杂的场景中（如支持刷新、超时或依赖注入），可考虑使用
Suppliers.memoizeWithExpiration()或 Guava 的LoadingCache替代手写 DCL。
综上，该方案以最小侵入性实现了线程安全的惰性异步初始化，兼顾性能与正确性，是构建高并发、响应式服务组件的推荐实践。
