异步方法返回Future本身不提升吞吐量，关键在于调用方不阻塞、线程复用与任务并行编排；需明确方法职责、避免默认线程池瓶颈、链式编排任务、统一异步异常处理。
直接用异步方法返回 Future 或 CompletableFuture 本身不提升吞吐量，关键在于**让调用方不阻塞等待、复用线程资源、并行编排任务**。真正起作用的是背后的执行模型和调用方式——不是“返回 Future”这个动作，而是“如何设计方法签名+如何调度执行+如何消费结果”这一整套配合。
明确方法职责：返回 CompletableFuture 而非阻塞获取结果
把耗时操作（如远程调用、文件读取、数据库查询）封装为异步方法，返回 CompletableFuture<T>，而非同步返回 T 或先 get() 再返回。这样调用方拿到的是“未来会有的结果”，可立即继续处理其他逻辑。
- ✅ 正确示例：
public CompletableFuture<Order> fetchOrderAsync(String orderId) - ❌ 反模式：
public Order fetchOrder(String orderId) { return future.get(); }—— 这等于把异步变同步，完全抵消优势
避免默认线程池瓶颈：显式指定专用线程池
supplyAsync 和 runAsync 默认使用 ForkJoinPool.commonPool()，它共享且无界，I/O 密集型任务容易拖垮整个应用。应按任务类型划分线程池：
- I/O 型（HTTP、DB）：用固定大小线程池，如
Executors.newFixedThreadPool(20)，防止线程饥饿 - CPU 密集型：线程数 ≈ CPU 核心数，避免上下文切换开销
- 示例：
CompletableFuture.supplyAsync(() -> apiClient.call(), ioExecutor)
链式编排代替顺序等待：用 thenCompose/thenCombine 并行化
多个依赖关系的任务，不要写成 future1.get(); future2.get();，而应组合执行：
立即学习“Java免费学习笔记（深入）”；
- 串行依赖（B 依赖 A 结果）→ 用
thenCompose：避免中间阻塞 - 并行无关（A 和 B 可同时跑）→ 用
CompletableFuture.allOf(f1, f2).join()或f1.thenCombine(f2, (a,b) -> ...) - 任意一个完成即响应 → 用
CompletableFuture.anyOf(...)，适合降级或兜底场景
异常与完成状态统一处理：用 exceptionally / handle 替代 try-catch + get
同步方式中常出现 try { result = future.get(); } catch (Exception e) { ... }，这仍会阻塞。异步设计应把错误处理也放入非阻塞链路：
-
future.exceptionally(throwable -> fallbackValue)：返回兜底值，不中断链路 -
future.handle((result, ex) -> { ... })：统一处理成功/失败，适合日志、指标上报等 - 避免在回调里再调
join()或get()，否则前功尽弃
