Java CompletableFuture 聚合接口优化：用超时兜底把 P95 从 920ms 降到 330ms

很多 Java 聚合接口本身不复杂：查用户、查订单、查优惠、查推荐，最后拼成一个首页响应。但如果这些步骤按顺序调用，接口耗时会被每个下游依赖累加。一个下游偶尔慢 300ms，整条链路就跟着变慢。

本文用一组可复现的指标来讲 CompletableFuture 的一个常见优化：把互不依赖的远程调用并发发起，并给慢依赖设置超时兜底。示例指标来自压测场景：优化前 P95 约 920ms，优化后稳定在 330ms 左右。

基线数据：串行聚合为什么拖慢 P95

先看一个典型聚合接口。它需要分别读取用户资料、订单摘要和推荐商品，三个查询之间没有强依赖，但旧代码按顺序调用：

public HomeView getHome(long userId) {
    UserProfile profile = queryProfile(userId);
    OrderSummary orders = queryOrders(userId);
    RecommendList recommends = queryRecommends(userId);

    return HomeView.of(profile, orders, recommends);
}

单次调用看起来不慢，但压测下会出现这种时间线：

这里的关键不是平均值，而是 P95。串行链路会把几个依赖的尾部延迟叠加起来，用户看到的就是更长的等待。

优化假设：把互不依赖的请求并发发起

优化假设很直接：三个依赖互不等待，就可以并发发起。接口总耗时不再接近三段耗时之和，而更接近最慢的那一段，再加少量聚合开销。

这个假设成立需要两个前提：

• 三个查询没有先后依赖，订单查询不需要推荐结果，推荐查询也不需要订单结果。
• 慢依赖允许降级，例如推荐商品失败时返回空列表或默认列表。

如果下游结果必须全部成功，仍然可以并发，但超时策略要更谨慎；如果允许部分降级，接口体验会更稳定。

改动点：CompletableFuture 加超时兜底

下面是一个简化版本。为避免示例分散，代码直接使用 supplyAsync，生产中建议接入已有的业务线程池和监控。

import java.util.List;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.TimeUnit;

public HomeView getHomeFast(long userId) {
    CompletableFuture profileTask =
        CompletableFuture.supplyAsync(() -> queryProfile(userId))
            .orTimeout(250, TimeUnit.MILLISECONDS);

    CompletableFuture orderTask =
        CompletableFuture.supplyAsync(() -> queryOrders(userId))
            .completeOnTimeout(OrderSummary.empty(), 300, TimeUnit.MILLISECONDS);

    CompletableFuture recommendTask =
        CompletableFuture.supplyAsync(() -> queryRecommends(userId))
            .completeOnTimeout(RecommendList.of(List.of()), 280, TimeUnit.MILLISECONDS);

    UserProfile profile = profileTask.join();
    OrderSummary orders = orderTask.join();
    RecommendList recommends = recommendTask.join();

    return HomeView.of(profile, orders, recommends);
}

这段代码有两类策略：

• orTimeout：超时后让任务失败，适合用户资料这类必须数据。
• completeOnTimeout：超时后返回默认值，适合推荐、提示、补充信息等可降级数据。

注意：超时时间不是拍脑袋设置。它应该来自下游依赖的真实延迟分布、业务可接受等待时间和整体接口目标。

压测方法：固定输入、固定并发、固定观察指标

性能优化要能复查。建议压测时固定三件事：

• 固定输入：使用同一批用户 ID，避免冷热数据差异过大。
• 固定并发：例如并发 50、持续 10 分钟，分别测旧版本和新版本。
• 固定指标：至少记录平均耗时、P95、P99、超时次数、降级次数和错误率。

还要给每个下游依赖单独埋点。否则总接口变快了，但不知道到底是订单、推荐还是用户服务仍在抖动。

结果对比：P95 降低后还要看错误率

优化后时间线会变成并发发起、最慢依赖受超时限制、聚合接口按兜底结果返回：

不要只看 P95 下降。还要确认降级率是否可接受，默认值是否会误导用户，日志里是否能区分“真实空结果”和“超时兜底”。

边界条件：不要把并发优化变成下游压力

CompletableFuture 能缩短调用等待，但不能凭空减少下游成本。落地时要注意这些边界：

• 线程池隔离：不同下游最好有独立预算，避免推荐服务慢时拖住所有异步任务。
• 超时时间分层：必须数据可以稍长，可降级数据要更短。
• 降级结果可识别：日志和指标要能标记兜底来源，便于回查。
• 下游容量保护：并发发起会让瞬时请求变多，需要配合限流和连接池预算。
• 异常处理清晰：可降级和不可降级的异常不能混在一个默认分支里。

总结一下：Java 聚合接口的性能优化，先从基线指标入手，再判断依赖是否可并发，最后用超时和兜底控制尾部延迟。CompletableFuture 不是万能加速器，它真正有价值的地方，是把“等待所有依赖串行完成”改成“并发请求、按业务优先级返回”。