掌握completablefuture关键在理解任务流转与线程执行归属；需分清thenapply（同线程同步转换）、thencompose（串行依赖扁平化）、thencombine（并行结果合并）；必须自定义io/cpu双线程池；异常须用exceptionally或handle处理；聚合操作要按语义选用allof、thenacceptboth或thencombine。
掌握 CompletableFuture 进阶技巧，关键不在背方法名，而在理解“任务阶段如何流转”和“线程在哪执行、谁负责兜底”。真正卡住人的从来不是语法，而是上线后线程池打满、异常静默丢失、上下文错乱、组合逻辑死锁这些场景。下面从四个实操维度讲清楚。
搞懂 thenApply、thenCompose、thenCombine 的分工边界
这三个方法名字像，但语义完全不同，选错一个就会埋下嵌套地狱或阻塞风险：
-
thenApply：同步转换结果，比如
String → Integer或格式化字段，回调在前一个任务完成的**同一线程**执行（不新开线程） -
thenCompose：用于串行依赖，比如“查用户ID → 再用ID查订单”，它把上一个异步结果作为参数，返回一个新的 CompletableFuture，避免
CompletableFuture<completablefuture>></completablefuture>嵌套 - thenCombine：用于并行独立任务的结果合并，比如“查用户信息”和“查订单列表”同时发起，等两个都完成再组装成 DTO，两个任务无依赖、可并发
线程池必须自定义，且要分场景配两套
别用 ForkJoinPool.commonPool() —— 它是全局共享的，IO 任务一旦占满，连 Stream.parallel() 都会卡住。生产环境至少准备两套线程池：
-
IO 密集型池（如调用 HTTP、DB）：线程数建议设为
2 × CPU 核数或根据下游平均 RT + QPS 反推，用LinkedBlockingQueue防止拒绝任务 -
CPU 密集型池（如加解密、JSON 解析）：线程数 ≈ CPU 核数，用
SynchronousQueue减少队列开销 - 所有
supplyAsync/runAsync调用都显式传入对应池，不依赖默认值
异常不能靠 try-catch 包裹，要用 handle 或 exceptionally
CompletableFuture 的异常不会自动抛出到主线程，join() 或 get() 才会暴露，但此时调用栈已丢失。正确做法是：
- exceptionally：只关心“出错了怎么办”，返回默认值，适合兜底（如查不到用户就返回空对象）
-
handle：统一处理成功和失败，参数是
(result, throwable)，适合打日志 + 返回结构化错误码 - 切忌在 lambda 里吞异常（比如
catch (Exception e) { }），那等于让错误彻底消失
组合多个任务时，分清 allOf、anyOf、thenAcceptBoth 的适用时机
聚合多接口是高频场景，但不同语义要用不同 API：
-
allOf：等全部完成，但不返回结果，需手动
future.get()拿每个值；适合“只关心是否全部成功”的通知类场景 - thenAcceptBoth：两个已完成的 CF 结果一起消费，无返回值；适合“查完用户+查完订单后发消息”这类副作用操作
- thenCombine：两个 CF 都完成，合并结果并返回新值；适合“用户 + 订单 → 用户订单详情页”这种构造型逻辑
- 注意：
allOf返回的是CompletableFuture<void></void>，不能链式取值，别误当结果容器用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
