ListenableFuture 更适合老项目迁移，因其不依赖JDK 8+函数式特性、兼容JDK 7及Spring 4.x/Dubbo 2.6等旧框架，避免NoSuchMethodError，且通过ListeningExecutorService和Futures.addCallback实现线程模型友好、无额外性能开销的异步回调。
为什么 ListenableFuture 比 CompletableFuture 更适合老项目迁移
Guava 的 ListenableFuture 是 Java 8 之前最成熟的异步回调方案，它不依赖 CompletableFuture 那套函数式链式调用，而是靠显式注册监听器，对已有线程模型、Executor 管理方式更友好。如果你的项目还在用 JDK 7，或者用了 Spring 4.x / Dubbo 2.6 这类不支持 CompletableFuture 作为 RPC 返回类型的框架，硬切 CompletableFuture 会卡在接口契约层。
常见错误现象：ExecutionException: java.lang.NoSuchMethodError: java.util.concurrent.CompletableFuture.completedFuture——这是 JDK 7/8 混用时典型的版本错位，ListenableFuture 能绕过这类问题。
- 使用场景：RPC 客户端（如 Thrift、gRPC Java 同步 stub 封装）、定时任务结果聚合、Spring
AsyncTaskExecutor回调扩展 -
ListenableFuture是接口，必须配合ListeningExecutorService创建，不能直接 new - 性能上无额外开销，监听器是弱引用持有，不会阻止 GC；但要注意监听器执行线程由注册时传入的
Executor决定，不是原任务线程
如何正确创建并添加监听器（别漏掉 ListeningExecutorService）
直接用 Executors.newCachedThreadPool() 得到的是普通 ExecutorService，无法生成 ListenableFuture。必须用 Guava 提供的包装器。
示例：
立即学习“Java免费学习笔记（深入）”；
ListeningExecutorService service = MoreExecutors.listeningDecorator(
Executors.newFixedThreadPool(4)
);
ListenableFuture<String> future = service.submit(() -> {
Thread.sleep(100);
return "done";
});
Futures.addCallback(future, new FutureCallback<String>() {
@Override
public void onSuccess(String result) {
System.out.println("got: " + result);
}
@Override
public void onFailure(Throwable t) {
t.printStackTrace();
}
}, service); // 注意：这里要传 Executor，不是主线程
- 漏掉
MoreExecutors.listeningDecorator()是最高频错误，会导致编译失败或运行时报ClassCastException -
Futures.addCallback()第三个参数是执行回调的Executor，别传directExecutor()除非你确认回调逻辑极轻量且无阻塞 - 如果想让回调在主线程执行（比如 Android 或 Swing），用
MoreExecutors.directExecutor()，但注意这会把回调压进提交任务的线程，可能造成阻塞
cancel() 行为和异常传播与 CompletableFuture 不同
ListenableFuture.cancel(true) 会尝试中断正在执行的任务线程，但**不保证立即停止**；而 CompletableFuture.cancel() 默认只标记为取消，不中断线程。这点在超时控制里特别关键。
常见错误现象：调用 future.cancel(true) 后，日志里仍看到任务后续输出，甚至引发 InterruptedException 未被捕获而吞掉。
- 任务体里必须主动检查
Thread.interrupted()或捕获InterruptedException，否则中断信号会被忽略 -
onFailure()中拿到的异常可能是CancellationException，也可能是原始任务抛出的异常，取决于 cancel 是否发生在任务完成前 - Guava 不提供类似
orTimeout()的便捷方法，超时需手动组合ScheduledExecutorService+cancel()
和 Spring、Dubbo 等框架集成时的兼容要点
Spring 4.2+ 的 @Async 方法返回类型可以是 ListenableFuture，但返回值必须声明为接口，不能是 Guava 内部实现类（如 AbstractFuture）。
Dubbo 2.6.x 默认只识别 java.util.concurrent.Future，要支持 ListenableFuture 需配置：com.alibaba.dubbo.rpc.protocol.FutureAdapter 并重写适配逻辑——但这一步容易被跳过，导致消费者收不到回调。
- Spring Boot 2.x 默认启用
AsyncConfigurer自动装配，但若自定义了TaskExecutor，务必用MoreExecutors.listeningDecorator()包一层再注入 - 不要在
onSuccess()里直接 throw 异常：它不会传播给上游，只会打印到日志，建议用log.error显式记录 - 多个监听器共存时，执行顺序不确定，别依赖先后；如有顺序要求，得串成链式调用，而不是注册多个独立监听器
最容易被忽略的是监听器的生命周期管理：没做清理的长期运行服务里，监听器对象可能因持有外部引用而泄漏，尤其当监听器是匿名内部类且引用了 Activity、Fragment 或 ServletContext 时。
