CompletableFuture提升吞吐量的关键是并行执行+非阻塞回调+合理线程池控制：将独立I/O操作（如查库、调第三方、读Redis）并行发起，用supplyAsync+自定义线程池、thenCombine/allOf合并结果，避免get()/join()阻塞主线程，并配置超时、异常兜底与隔离线程池。
用 CompletableFuture 提升吞吐量，关键不是“加个 async 就完事”，而是把串行等待变成并行执行 + 非阻塞回调 + 合理资源控制。它不改变单次调用的耗时，但能显著减少请求整体响应时间、释放 Tomcat 线程、提高单位时间处理请求数。
把多个独立 I/O 操作并行跑起来
很多接口慢，是因为查库、调第三方、读 Redis 这几件事是挨个等的。只要它们彼此不依赖，就该并行发起：
- 用 supplyAsync 分别提交任务，传入自定义线程池（别用默认 ForkJoinPool）
- 用 thenCombine 或 allOf + join 合并结果，而不是逐个 get
- 例如：查用户信息、查订单列表、查物流状态，三者可同时发起，总耗时≈最长那个（比如 120ms），而非相加（比如 360ms）
避免在主线程里调用 get() 或 join()
CompletableFuture 的威力在于“不卡主线程”。一旦你在 Controller 或 Service 里写了 future.get()，就退化成同步阻塞，Tomcat 线程被占着不动，吞吐量反而下降：
- 用 thenApply、thenAccept 或 thenCompose 把后续逻辑注册为回调
- 需要返回值给前端？用 thenApplyAsync 继续异步处理，最后用 CompletableFuture.completedFuture 包装结果
- 真要等结果（极少数场景），至少设超时：future.orTimeout(2, TimeUnit.SECONDS)
配对合适的线程池，别让异步变“假异步”
异步任务跑在哪？线程池配置不对，再好的编排也白搭：
立即学习“Java免费学习笔记（深入）”；
- I/O 密集型任务（查库、HTTP 调用）：核心线程数建议 = CPU 核数 × (1 + 平均等待时间 / 平均计算时间)，通常 8–32 之间，配合有界队列（如 ArrayBlockingQueue(1000)）
- 拒绝策略别用默认 AbortPolicy，推荐 CallerRunsPolicy（压力大时降级为同步，保可用）或自定义丢弃+告警
- 不同业务类型建议隔离线程池：支付、消息、报表各用各自的，防止单一任务拖垮全局
加一层安全阀：超时与异常兜底
不设超时的异步任务，等于埋雷。一个下游卡死，可能让整个线程池慢慢被占满：
- 用 orTimeout 设置任务级超时（注意：计时从 supplyAsync 调用开始，不是线程拿到任务时）
- 用 exceptionally 或 handle 统一捕获异常，返回兜底数据或明确错误码，别让异常穿透到上层
- 复杂场景可组合重试逻辑（比如用 thenCompose 嵌套 retry 逻辑），但别无脑重试，优先保障主链路
