thenApply是同步转换，输入T输出R；thenCompose是扁平展开，输入T输出CompletableFuture并自动解包。
CompletableFuture.thenApply 和 thenCompose 的区别到底在哪
很多人写完 thenApply 发现返回值又套了一层 CompletableFuture，结果链式调用崩了——这不是 bug，是设计如此。thenApply 是“同步转换”，输入一个 T，输出一个 R；thenCompose 才是“扁平展开”，输入一个 T，输出一个 CompletableFuture<r></r>，它会自动解包一层。
常见错误现象：thenApply(x -> CompletableFuture.completedFuture(x + 1)) 返回的是 CompletableFuture<completablefuture>></completablefuture>，后续 join() 会抛 ClassCastException 或卡死。
- 用
thenApply：做纯内存计算，比如字符串转大写、数字加 1、DTO 转 VO - 用
thenCompose：后面还要发起异步调用，比如查数据库、调 HTTP 接口、再走一次supplyAsync - 别把
thenAccept当thenApply用——前者返回void，无法继续编排
异常处理时，exceptionally 和 handle 哪个更靠谱
exceptionally 只捕获上游抛出的异常，且必须返回和原始类型一致的值（比如上游是 CompletableFuture<string></string>，你就得返回一个 String）；handle 则无论成功失败都进，参数是 (result, throwable)，能统一兜底、打日志、降级返回默认值。
使用场景：exceptionally 适合简单兜底（比如“查不到就返回空字符串”）；handle 更适合生产环境——你往往既想记录异常堆栈，又不想让整个链路因为类型不匹配而中断。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
exceptionally里 throw 新异常？没用，它只接受返回值，不会重新抛出 -
handle中如果对throwable不为空的情况也返回正常值，那上游的异常就被静默吞掉了，小心监控盲区 - 别在
handle里做耗时操作（比如发邮件），它跑在同一个线程上，可能拖慢整个链路
多个 CompletableFuture 怎么等全部完成或任一完成
CompletableFuture.allOf 和 CompletableFuture.anyOf 看似简单，但返回值不是你想要的集合——它们返回的是 CompletableFuture<void></void> 和 CompletableFuture<object></object>，没法直接 get 到结果列表。
性能影响：allOf 是“全成功才成功”，任一失败则整体失败；anyOf 是“任一成功即成功”，但失败的那个异常不会透出，容易掩盖问题。
- 要取全部结果：先用
allOf等完成，再用Stream.of(futures).map(CompletableFuture::join).collect(...) - 要取第一个成功结果：用
anyOf+handle检查每个 future 的状态，或者改用applyToEither配对使用 -
allOf不会传播子 future 的异常，得手动遍历每个 future 的isCompletedExceptionally()判断
线程池传错会怎样：supplyAsync 不带参数的坑
supplyAsync(() -> heavyWork()) 看似简洁，但它用的是 ForkJoinPool.commonPool() ——这个池子大小默认等于 CPU 核心数，一旦 heavyWork() 是 IO 密集型（比如读文件、连 Redis），线程会大量阻塞，整个 commonPool 就卡死，连 Stream.parallel() 都受影响。
兼容性影响：JDK 19+ 对 commonPool 的抢占行为做了限制，但老版本下这个问题更隐蔽，表现为偶发超时、响应变慢，而不是直接报错。
- IO 操作一律显式传自定义线程池：
supplyAsync(() -> db.query(), dbExecutor) - 别复用
Executors.newCachedThreadPool()，它无限创建线程，OOM 风险高；推荐ThreadPoolExecutor配核心/最大/队列三参数 -
thenApply默认仍在前一个 stage 的线程上执行；只有thenApplyAsync才切线程——注意是否真需要切换
最常被忽略的点：编排链中任意一个 stage 用了无参 async 方法，就可能把整个链拖进 commonPool 泥潭。不是代码写得不够链式，而是线程归属没理清。
