Future.get()阻塞导致假异步，真正回调需用CompletableFuture链式方法（如thenAcceptAsync）并指定线程池，注意异常处理、超时控制、Spring上下文丢失及ThreadLocal传递问题。
Java里用Future做异步回调，为什么常卡住不返回？
因为Future.get()是阻塞的，哪怕任务已提交，没显式调用get()就不会触发回调逻辑——它本身不是回调，只是异步结果容器。
常见错误：在主线程直接future.get()，等于变相同步，失去异步意义；或忘记处理ExecutionException导致线程静默失败。
- 真正想实现“任务完成自动通知”，得配合
CompletableFuture或手动轮询+超时控制 - 若必须用
Future，建议搭配isDone()轮询 +Thread.sleep()（仅调试），生产环境禁用 -
ExecutorService.invokeAll()适合批量任务，但返回的List仍需逐个get()，不自动回调
用CompletableFuture写真正的非阻塞回调
CompletableFuture才是Java 8后推荐的异步回调方案，支持链式注册回调、异常传播、组合依赖等。
关键点：回调方法（如thenAccept、whenComplete）默认在执行任务的线程中运行；若要指定线程池，必须用带Async后缀的方法（如thenAcceptAsync）。
立即学习“Java免费学习笔记（深入）”；
-
thenApplyAsync(..., executor)：转换结果并交由指定线程池处理 -
exceptionally()捕获上游异常，避免整个链路中断 - 不要在
thenRun里抛异常——它无返回值，异常会丢失，改用whenComplete
CompletableFuture.supplyAsync(() -> fetchFromDB(), dbPool)
.thenApplyAsync(data -> process(data), computePool)
.exceptionally(t -> fallbackData())
.thenAccept(result -> sendToClient(result));
回调里再起线程？小心线程泄漏和上下文丢失
在thenAccept或whenComplete中直接new Thread(...).start()，会导致无法被线程池管理，且ThreadLocal（如Spring的RequestContextHolder）默认不会继承。
- 统一用
CompletableFuture的Async方法 + 预定义线程池，别手动生成线程 - 若必须传递
ThreadLocal，用ThreadPoolExecutor的beforeExecute+afterExecute钩子，或改用TransmittableThreadLocal（阿里TTTL） - HTTP请求类回调（如调第三方API）务必设超时：
orTimeout(3, TimeUnit.SECONDS)，否则可能永久挂起
Spring项目里怎么让回调自动注入Bean？
纯CompletableFuture回调方法是静态上下文，@Autowired字段为null——因为回调执行时已脱离Spring代理和IoC容器管理。
- 正确做法：把业务逻辑封装成
@Service类的方法，回调中通过ApplicationContext.getBean(XxxService.class)获取（不优雅但有效） - 更优解：用Spring的
@Async注解方法返回CompletableFuture，此时方法内可正常注入Bean，且自动使用TaskExecutor - 注意
@Async失效场景：同一类内调用、非public方法、未启用@EnableAsync
复杂点往往不在语法，而在回调执行时的线程归属、上下文生命周期、以及错误是否真的被观测到——这些地方一漏，问题就变成“看起来跑完了，但数据没更新，日志也没报错”。
