ReaderMX.
ITPUB

4.2秒到460毫秒：我用CompletableFuture让商品详情页“飞”起来了！

I冰河约 7 分钟

上周我们线上出了个尴尬的情况——商品详情页接口的响应时间悄悄爬升到了4.2秒。用户的吐槽很形象：“点个商品详情，咖啡都凉了还没加载出来”。产品经理拿着监控截图过来，半开玩笑地问：“你是不是把服务器电源给拔了？”

排查之后，我发现了一个典型的“串行依赖陷阱”：这个接口依次调用了多个服务——商品信息、库存、评价和推荐商品等，每个服务耗时约400多毫秒。就像多个人在接力跑，每个人都要等前一个人跑完才能出发，总时间自然就累加到了4秒多。

当时我瞬间就意识到：这简直是CompletableFuture的绝佳应用场景！今天就来详细分享一下，如何用这把“异步手术刀”把慢接口“解剖”成闪电般的响应。

一、罪魁祸首：串行调用的“龟速列车”

先看一段典型的“反面教材”代码：

public ProductDetailVO getProductDetail(Long productId){
// 1. 查商品信息（450ms）
    ProductVO product = productService.getById(productId);

// 2. 等商品查完再查库存（470ms）
    StockVO stock = stockService.getByProductId(productId);

// 3. 等库存查完再查评价（490ms）
    CommentSummaryVO comment = commentService.getSummary(productId);

// 4. 等评价查完再查推荐商品（475ms）
    List<ProductVO> recommends = recommendService.getRecommend(productId);

// 5.其他操作 （1915ms）

return ProductDetailVO.builder()
            .product(product)
            .stock(stock)
            .comment(comment)
            .recommends(recommends)
            .build();
}

这段代码的问题在于：明明没有依赖关系的几个查询，却非要排队执行。就像早上起床，明明可以同时烧水、刷牙、煮鸡蛋，却偏要等水烧开再刷牙，刷完牙再煮鸡蛋。

几个服务加起来3800毫秒，加上框架本身的处理时间，轻松突破4秒大关。用户等待的每一秒，都在考验他们的耐心极限。

二、CompletableFuture：不只是Future的升级版

说到异步编程，很多人会想到Future。但Future就像个“半成品”工具箱——能干活，但不顺手。你需要手动检查任务是否完成，处理异常也很麻烦，更别提编排复杂的任务依赖了。

CompletableFuture则是Java 8带来的“瑞士军刀”，它不仅继承了Future的能力，还引入了CompletionStage，支持链式调用和复杂的任务编排。下面用三个核心问题带你快速上手：

2.1 怎么启动异步任务？

启动异步任务就像点外卖：你下单（提交任务），然后可以去干别的，等外卖到了（任务完成）再处理。

// 有返回值的任务 - 像点了个需要送餐的外卖
CompletableFuture<ProductVO> productFuture = CompletableFuture.supplyAsync(() -> {
return productService.getById(productId);
});

// 无返回值的任务 - 像点了份自提的外卖
CompletableFuture<Void> logFuture = CompletableFuture.runAsync(() -> {
    logService.recordAccess(productId);
});

2.2  怎么获取任务结果？

等外卖到了，你有几种取餐方式：

// 1. 死等（不推荐）- 像在店门口一直站着等
ProductVO product = productFuture.get();

// 2. 等一会，不来就走（较安全）
try {
    ProductVO product = productFuture.get(2, TimeUnit.SECONDS);
} catch (TimeoutException e) {
// 超时了，返回默认值
}

// 3. 优雅地等（推荐）- 像在店里坐着等，外卖到了服务员叫你
ProductVO product = productFuture.join();

// 4. 设置回调（最优雅）- 像留个电话，外卖到了打给你
productFuture.whenComplete((result, exception) -> {
if (exception != null) {
        log.error("查询失败", exception);
    } else {
        assembleProductDetail(result);
    }
});

2.3 任务出错了怎么办？

外卖可能送错地址、可能洒了，异步任务也可能失败：

CompletableFuture<StockVO> stockFuture = CompletableFuture.supplyAsync(() -> {
return stockService.getByProductId(productId);
}).exceptionally(ex -> {
// 库存服务挂了？返回个“库存紧张”的默认值
    log.warn("库存服务异常，使用默认值", ex);
return StockVO.defaultStock(productId);
});

这样即使某个服务临时不可用，用户看到的也是“库存紧张”而不是“服务异常”，体验友好多了。

三、进阶玩法：从并行到智能编排

真实业务很少是简单的“一起开始一起结束”，更多是复杂的依赖关系。CompletableFuture的厉害之处在于它能优雅地处理这些关系。

3.1 串行依赖：A做完才能做B

// 先查商品，再根据商品分类查推荐
CompletableFuture<ProductVO> productFuture = CompletableFuture.supplyAsync(() -> 
    productService.getById(productId)
);

CompletableFuture<List<ProductVO>> recommendFuture = productFuture.thenApply(product -> {
// thenApply：拿到商品结果后，用它的分类ID查推荐
return recommendService.getByCategoryId(product.getCategoryId());
});

这里的thenApply就像说：“商品信息查到后，接着用它的分类ID查推荐商品”。

3.2 并行合并：A和B都做完再做C

CompletableFuture<ProductVO> productFuture = supplyAsync(() -> productService.getById(productId));
CompletableFuture<Integer> userLevelFuture = supplyAsync(() -> userService.getMemberLevel(userId));

// 两个都完成后再计算折扣价
CompletableFuture<BigDecimal> finalPriceFuture = productFuture.thenCombine(userLevelFuture, 
    (product, userLevel) -> calculateDiscount(product.getPrice(), userLevel)
);

thenCombine就像餐厅的“套餐”：主食和饮料可以同时准备，但必须都齐了才能上桌。

3.3 多任务协调：等所有人到齐 or 谁先到谁先走

// 等所有任务完成（朋友聚会，等所有人都到了再开饭）
CompletableFuture<Void> allDone = CompletableFuture.allOf(
    productFuture, stockFuture, commentFuture, recommendFuture
);
allDone.join(); // 阻塞直到所有任务完成

// 任何一个完成就继续（点外卖，哪个先到先吃哪个）
CompletableFuture<Object> firstDone = CompletableFuture.anyOf(
    cacheFuture, dbFuture // 同时查缓存和数据库
);
ProductVO product = (ProductVO) firstDone.join();

四、实战优化：三步让接口“起飞”

第一步：基础并行化

把四个串行查询改成并行执行：

public ProductDetailVO getProductDetail(Long productId) {
    // 四个任务同时出发
    CompletableFuture<ProductVO> pFuture = supplyAsync(() -> productService.getById(productId));
    CompletableFuture<StockVO> sFuture = supplyAsync(() -> stockService.getByProductId(productId));
    CompletableFuture<CommentSummaryVO> cFuture = supplyAsync(() -> commentService.getSummary(productId));
    CompletableFuture<List<ProductVO>> rFuture = supplyAsync(() -> recommendService.getRecommend(productId));

    // 等所有人都到齐
    CompletableFuture.allOf(pFuture, sFuture, cFuture, rFuture).join();

    // 取结果（这时候基本都完成了）
return assembleResult(pFuture.join(), sFuture.join(), cFuture.join(), rFuture.join());
}

效果：耗时从4.2秒降到约490毫秒（取决于最慢的那个任务），优化了近90%！

第二步：添加异常容错

给每个任务加上“安全网”：

CompletableFuture<StockVO> stockFuture = supplyAsync(() -> stockService.getByProductId(productId))
    .exceptionally(ex -> {
        log.warn("库存服务异常，使用默认库存", ex);
return StockVO.defaultStock(productId); // 返回“库存紧张”
    });

效果：接口稳定性大大提升，即使某个服务挂掉，用户也能看到页面（尽管部分信息是默认值）。性能损耗几乎可以忽略。

第三步：定制线程池

这里有个关键点：默认线程池不适合高并发场景。

@Configuration
publicclassThreadPoolConfig{
@Bean("ioExecutor")
public Executor ioExecutor(){
// I/O密集型任务：线程数 = CPU核心数 * 2 + 1
int coreSize = Runtime.getRuntime().availableProcessors() * 2 + 1;

        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(coreSize);
        executor.setMaxPoolSize(coreSize * 2);
        executor.setQueueCapacity(1000);
        executor.setThreadNamePrefix("async-io-");
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        executor.initialize();
return executor;
    }
}

// 使用自定义线程池
CompletableFuture<ProductVO> productFuture = supplyAsync(
    () -> productService.getById(productId), 
    ioExecutor // 指定线程池
);

效果：更稳定的性能表现，避免默认线程池在高并发下成为瓶颈。

五、避坑指南：我踩过的那些“坑”

  1. 不要用默认线程池：ForkJoinPool.commonPool()是全局共享的，核心线程数少，高并发下容易打满。就像用小碗接暴雨，很快就溢出了。
  2. 异常处理必须做：异步任务的异常不会自动抛出，如果不处理，失败就“悄无声息”了。每个CompletableFuture都要配“安全网”。
  3. 避免“异步转同步”：别在主线程（如Tomcat工作线程）里调用join()或get()，否则又变回阻塞了。异步的精髓是“不阻塞等待”。
  4. 理清任务依赖：别为了并行而并行。如果任务B必须等任务A的结果，那就乖乖串行。就像做饭，得先有米才能煮饭。
  5. 控制任务数量：一个接口启动几十个异步任务，就像同时点几十份外卖，骑手都不够用。合理控制并发数，分批或合并任务。

六、哪些场景最适合用CompletableFuture？

根据我的经验，这些场景用CompletableFuture效果最明显：

  • 聚合接口：商品详情、订单详情等需要调用多个下游服务的场景
  • 多结果合并：需要多个独立结果计算最终值的场景
  • 超时优先：同时查询主备数据源，谁先返回用谁的
  • 流程编排：有复杂依赖关系的异步任务链

七、总结

通过CompletableFuture的优化，我们把商品详情页接口从4.2秒优化到了460毫秒级别，这不仅是数字的变化，更是用户体验的质的提升。

异步编程不是银弹，但它确实是解决I/O等待问题的利器。关键是要理解业务的任务依赖关系，合理设计并行策略。

下次产品经理再拿着性能监控图来找你时，你可以自信地说：“给我一天时间，我用CompletableFuture让它飞起来！”

Image

KEEP THE THREAD GOING

更多来源文章