CompletableFuture.supplyAsync()是异步链式调用起点，接收Supplier并返回CompletableFuture；须避免手动创建、主线程阻塞、I/O阻塞及混淆thenApply/thenCompose，异常处理优先用handle()，生产环境慎用join()/get()。
CompletableFuture.supplyAsync() 是异步链式调用的起点
直接用 supplyAsync() 启动异步任务，它接收一个 Supplier，返回 CompletableFuture。别用 new CompletableFuture() 手动创建——它不会自动执行，后续 thenApply 等方法也不会触发。
常见错误：在主线程里调用 supplyAsync() 后立刻调用 join()，导致阻塞；或误以为传入的 lambda 会在主线程执行。
- 默认使用
ForkJoinPool.commonPool()，CPU 密集型任务可考虑自定义线程池传入第二个参数 - 如果 Supplier 抛出异常，该异常会被包装为
CompletionException，后续exceptionally()或handle()才能捕获 - 不要在
supplyAsync()的 lambda 中做 I/O 阻塞操作（如数据库查询、HTTP 调用），应改用executor参数指定专用于 I/O 的线程池
thenApply() 和 thenCompose() 的区别必须分清
thenApply() 是「转换」：输入是上一阶段结果，输出是新值，返回 CompletableFuture；thenCompose() 是「扁平化接续」：输入是上一阶段结果，但你返回的是另一个 CompletableFuture，它会自动展开一层，避免嵌套成 CompletableFuture。
典型踩坑场景：连续两次 HTTP 异步调用，第二次依赖第一次返回的 ID：
立即学习“Java免费学习笔记（深入）”；
CompletableFutureidFuture = CompletableFuture.supplyAsync(() -> "123"); CompletableFuture userFuture = idFuture .thenCompose(id -> CompletableFuture.supplyAsync(() -> fetchUserById(id))); // ✅ 正确：返回 CompletableFuture // ❌ 错误写法（会导致类型不匹配）： // .thenApply(id -> CompletableFuture.supplyAsync(() -> fetchUserById(id)))
-
thenApply()适合纯内存计算（如字符串转大写、对象字段映射） -
thenCompose()适合“异步之后再异步”的场景，是链式调用的核心粘合剂 - 两者都支持异步执行（可传入自定义
Executor），否则默认在前一阶段完成的线程上执行（可能不是 ForkJoinPool 线程）
异常处理不能只靠 exceptionally()
exceptionally() 只捕获上游抛出的异常，并返回一个默认值，但它无法感知下游是否失败；而 handle() 接收两个参数（result, throwable），无论成功或失败都会执行，更可控。
常见疏漏：在 thenCompose() 后加 exceptionally()，但没意识到如果 thenCompose() 返回的 CompletableFuture 自身失败，exceptionally() 不会触发——因为异常发生在“子 future”里，父 future 仍算完成（值为 null）。
- 对关键异步步骤，优先用
handle()做统一收口，显式判断throwable != null -
whenComplete()类似handle()，但不支持返回值，适合日志、清理等副作用操作 - 多个
exceptionally()链式调用时，只有第一个生效；若需逐级兜底，得用handle()+ 显式 rethrow
join() 和 get() 在生产环境要谨慎使用
join() 是无检查异常版本的 get()，抛出 CompletionException；get() 抛出 InterruptedException 和 ExecutionException。二者都会阻塞当前线程，破坏异步流的非阻塞特性。
真实项目中，只有两类情况可接受阻塞：
- 测试代码里验证最终结果
- 主程序入口（如 Spring Boot 的
@PostConstruct）需要等待初始化完成
其他所有业务逻辑中，应把后续处理逻辑继续写在 thenAccept()、thenRun() 或组合多个 CompletableFuture（如 allOf()、anyOf()）里。强行 join() 容易引发线程饥饿，尤其在线程池较小或任务耗时波动大的场景下。
