毫秒级聚合的关键在于避免阻塞、隔离线程池、设置超时与异常兜底：禁用join和commonPool，改用非阻塞组合、自定义IO线程池、orTimeout及exceptionally，按SLA分级编排而非盲目allOf。
CompletableFuture 本身不提供“全链路”能力，它只负责单次异步任务的编排与组合；真正的毫秒级聚合效果，取决于你是否切断了线程阻塞、是否规避了 commonPool、是否对每个远程调用做了超时熔断——而不是靠堆 API。
为什么 allOf + join 会拖垮 P99 延迟
常见错误是写成这样：CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).thenApply(v -> futures.stream().map(CompletableFuture::join).collect(...))。问题在于 CompletableFuture::join 是同步阻塞调用，一旦某个服务响应慢（比如 2s），整个聚合阶段就会卡住，P99 直接上天。
- 必须改用
thenCombine或thenAcceptBoth类非阻塞组合方式，让结果就绪即参与计算 - 如果必须等全部完成，应提前为每个
supplyAsync配置独立超时，例如用orTimeout(800, TimeUnit.MILLISECONDS)（JDK 9+）或手动 wrap 超时逻辑 -
allOf返回的是CompletableFuture<void></void>，它不携带结果，强行用join提取是反模式
IO 密集型任务必须绕开 ForkJoinPool.commonPool()
默认的 supplyAsync(Runnable) 会把所有 HTTP/RPC 调用扔进 ForkJoinPool.commonPool()，而它的线程数 = CPU 核数 − 1，专为 CPU 密集型设计。IO 线程一阻塞，池子就迅速耗尽，后续任务排队，延迟雪崩。
- 所有远程调用必须显式传入自定义线程池：
supplyAsync(() -> httpCall(), ioExecutor) -
ioExecutor建议用ThreadPoolExecutor，核心线程数设为 20–50（视 QPS 和平均 RT 调整），队列用ArrayBlockingQueue防 OOM - 千万别用
Executors.newCachedThreadPool()，它无限创建线程，GC 和上下文切换开销巨大
异常传播会中断整个链路，必须每层兜底
一个未处理的 CompletionException 会直接终止后续所有 thenApply，导致部分结果丢失、聚合失败。这不是“某环节出错”，而是整个编排图被炸断。
- 每个
supplyAsync后紧跟exceptionally(e -> fallbackValue)，返回兜底数据而非抛异常 - 慎用
handle((r, e) -> {...})：它总被执行，但需手动判空r和e，易漏逻辑 - 聚合前加
whenComplete((result, ex) -> log.debug("aggregated: {}", result))，确认结果完整性
扇出 + 分支选择比“全量等待”更贴近真实业务
商品详情页里，“用户评价”和“物流轨迹”哪个先到，其实不影响主流程渲染；强求两者都到，反而放大了最慢依赖的拖累效应。
- 用
applyToEither获取最快响应：ratingFuture.applyToEither(logisticsFuture, r -> enrichWith(r)) - 用
acceptEither做副作用（如埋点）：ratingFuture.acceptEither(logisticsFuture, r -> metrics.record("first-arrived", r.type())) - 真正需要“全量”的场景极少，多数是“主干 + 可选补充”，应按 SLA 分级编排，而非一刀切
allOf
毫秒级聚合的关键不在 CompletableFutures 多少层嵌套，而在于每一层是否真的不阻塞、不共享、不甩锅。commonPool 的线程、没设超时的 RPC、没兜底的异常——这三样任何一个没处理干净，P99 就不可能稳在 400ms 内。
