CompletableFuture 不能直接用 get() 阻塞等待，因其会阻塞线程、破坏异步模型、引发超时泄漏；应优先使用 thenApply 等非阻塞回调，必须阻塞时需确保线程池可扩容或改用 join()。
CompletableFuture 为什么不能直接用 get() 阻塞等待
多数人第一次用 CompletableFuture 时，会下意识调用 get() 等待结果，但这是高风险操作：它会阻塞当前线程，若在主线程或 IO 密集型线程池中调用，极易导致线程耗尽、响应延迟飙升。尤其在 Spring WebFlux 或 Vert.x 这类非阻塞框架里，get() 直接破坏异步模型。
更隐蔽的问题是超时控制——get() 默认无限等待，get(long, TimeUnit) 抛出 TimeoutException 后，底层任务仍可能在后台运行，造成资源泄漏或重复提交。
- ✅ 正确姿势：用
thenApply、thenAccept、handle等非阻塞回调链处理结果 - ✅ 必须阻塞时，确保线程池可扩容（如自定义
ForkJoinPool.commonPool()大小），或改用join()（不抛受检异常，但仍有阻塞问题） - ❌ 避免在 Servlet 容器主线程、Netty EventLoop、Spring WebMvc 的 Controller 方法体里调用
get()
如何正确组合多个异步任务：thenCompose vs thenCombine
两个异步任务需要串行依赖（B 依赖 A 的结果）还是并行合并（A 和 B 独立执行，最后合结果）？选错方法会导致嵌套 CompletableFuture 或提前触发。
thenCompose 用于“扁平化”链式调用：它接收一个返回 CompletableFuture 的函数，自动展开一层，避免 CompletableFuture；而 thenCombine 接收另一个已完成的 CompletableFuture，适合并行任务汇合。
立即学习“Java免费学习笔记（深入）”；
- 串行依赖（如查库 → 调第三方 API）：用
thenCompose，例如dbQuery().thenCompose(result -> callApi(result)) - 并行无依赖（如查用户 + 查订单）：用
thenCombine，例如userFut.thenCombine(orderFut, (u, o) -> new Profile(u, o)) - ⚠️ 注意：如果误用
thenApply返回新CompletableFuture，会产生双重封装，后续join()会得到未完成的内部 future
异常处理必须显式指定：exceptionally 和 handle 的区别
CompletableFuture 的异常不会自动传播到下游，未捕获的异常会让整个 chain “静默失败”——下游 thenApply 根本不执行，也无日志，极难排查。
exceptionally 只在上游异常时触发，返回替代值；handle 则无论成功或异常都执行，接收 (result, throwable) 二元参数，更适合统一记录日志或兜底逻辑。
- 仅需兜底值（如缓存降级）：用
exceptionally(t -> defaultData) - 需区分成功/失败做不同处理（如打点、告警、重试）：用
handle((r, t) -> { if (t != null) { log.error("fail", t); return fallback(); } return r; }) - ⚠️
whenComplete不影响结果值，只做副作用（如清理资源），且不接收返回值，别拿来当handle用
线程调度陷阱：默认用 commonPool，但 IO 任务必须换线程池
CompletableFuture 所有异步方法（如 supplyAsync、thenApplyAsync）默认使用 ForkJoinPool.commonPool()，它是 CPU 密集型设计（线程数 ≈ CPU 核心数）。一旦在其中执行数据库查询、HTTP 调用等阻塞 IO 操作，commonPool 线程会被长期占用，导致后续任务排队甚至死锁。
- ✅ IO 任务必须传入自定义线程池：
supplyAsync(() -> db.query(), ioExecutor)，其中ioExecutor建议用new ThreadPoolExecutor(10, 50, 60L, TimeUnit.SECONDS, new SynchronousQueue()) - ✅ CPU 密集型计算（如加解密、图像处理）可继续用
commonPool，或指定ForkJoinPool实例 - ⚠️
thenRun/thenAccept等无Async后缀的方法，在前序任务同一线程中同步执行——若前序耗时长，会阻塞后续逻辑，务必注意调用位置
thenApply 就以为万事大吉，结果某次网络超时后整个链路停摆，却找不到任何错误日志。 
