一、事故现场

线上有个订单详情接口。页面需要展示这些信息：

订单基本信息 使用者信息 物流信息 优惠券信息 售后状态

一开始是串行查询：

public OrderDetail getOrderDetail {
Order order = orderService.getOrder;User user = userService.getUser);Logistics logistics = logisticsService.getLogistics;Coupon coupon = couponService.getCoupon;AfterSale afterSale = afterSaleService.getAfterSale;return buildDetail;}

接口 RT 偏高，开发同学决定改成并行：

public OrderDetail getOrderDetail {
CompletableFuture orderFuture =
CompletableFuture.supplyAsync -> orderService.getOrder);CompletableFuture userFuture =
CompletableFuture.supplyAsync -> userService.getUserByOrderId);CompletableFuture logisticsFuture =
CompletableFuture.supplyAsync -> logisticsService.getLogistics);CompletableFuture couponFuture =
CompletableFuture.supplyAsync -> couponService.getCoupon);CompletableFuture afterSaleFuture =
CompletableFuture.supplyAsync -> afterSaleService.getAfterSale);怎么说呢，CompletableFuture.allOf(
orderFuture,userFuture。logisticsFuture,couponFuture,afterSaleFuture
).join;return buildDetail(
orderFuture.join,userFuture.join。logisticsFuture.join,couponFuture.join,afterSaleFuture.join
);}

刚上线时效果很好：接口从 800 ms 降到 300 ms。但高峰期来了以后监控开始报警：

CPU 持续 ↑
接口 RT 飙升
Tomcat 线程开始堆积
下游服务偶发超时
ForkJoinPool.commonPool-worker 线程大量出现

最终定位到一个点： supplyAsync 没传线程池，默认用了 ForkJoinPool.commonPool.

二、问题藏在没传 Executor 里

很多人用 supplyAsync 时只写：

CompletableFuture.supplyAsync -> querySomething);

但这个方法有两个版本：

• No executor: supplyAsync
• Spae executor: supplyAsync

If you omit executor,it falls back to JVM‑level default:

ForkJoinPool.commonPool;

This is pitfall.

三、为什么 commonPool 容易出事？- 使用者痛点提醒，

• User experience suffers when CPU saturates.
• The common pool is meant for CPU‑bound tasks – quick splits and merges.
• Your business often runs IO‑heavy work .
• An IO task can block a worker thread for seconds.
• A single slow external service can starve all or async tasks.
• The result?Entire service feels sluggish or even down.

四、并行不是免费午餐 - 使用者对性能期望的误区！

• You think parallelism automatically reduces latency.
• A request still makes same number of downstream calls.
• The only change is that y happen concurrently.
• If your QPS is high and each request spawns multiple async calls,downstream services may receive a burst of concurrent requests y cannot handle.
• This “parallel pressure” can cause cascading failures and timeout spikes for your own service.
.

五、最小复现 - 快速验证你的程序是否容易卡住！

public String remoteCall {
try {
Thread.sleep;// simulate slow call
} catch {
Thread.currentThread.interrupt;说起来，}
return "ok-" + i;}
public void testCommonPool {
List futures = new ArrayList<>;for {
int index = i;futures.add -> remoteCall));}
CompletableFuture.allOf).join;}

• The threads you see will be “ForkJoinPool.commonPool-worker” many times over.
.
• Your RT will spike because join waits on blocked workers.
. User sees long wait times and error logs piling up—exactly what happens in production!.

六、正确写法：一定要传业务专属线程池！

• No more naked `supplyAsync`!
.
CompletableFutur…`supplyAsync -> query,orderDetailExecutor);`​
java @Configuration public class OrderAsyncConfig { @Bean public ThreadPoolTaskExecutor orderDetailExecutor { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor;executor.setCorePoolSize;// 根据业务调优 executor.setMaxPoolSize;executor.setQueueCapacity;按理说，executor.setThreadNamePrefix;// 防止OOM，遇满直接回退到调用者线程 executor.setRejectedExecutionHandler);executor.initialize;按理说，return executor;} } java @Resource private Executor orderDetailExecutor;public OrderDetail getOrderDetail { CompletableFutur…order= supplyAsync=>orderService..getOrder,orderDet…Exec，);// ，同理为其他服务创建 future CompletableFutur…老实说，allOf.join;return build;}
• Tune thread count & queue size per workload.
.
• No contamination of common pool → no cross‑service interference.. ---

  七、线程池不是越大越好——你可能把压力迁移到了下游！

  - If your pool maxes out at N threads,you might launch up to N concurrent downstream calls per request. - If downstream services only handle M - Size your pool based on *entry QPS*。*per‑request async count*,*average task duration*,*downstream capacity*,and *timeout policy*. - Focus on overall system stability rar than chasing a single endpoint’s latency metric.

  八、join 会把请求线程拖死 —— 超时保护必不可少！其实，

  I don't know *** this happened!My app's cpu usage skyrockets!😠

  示例

  java // 给每个 Future 设置超时/降级策略 CompletableFutur…user= supplyA...orTimeout;

  CompletableFutur…coupon= supplyA...completeOnTimeout。200,TimeUnit.MILLISECONDS);

  如果优惠券是非主要字段。就可以在超时后返回空对象，而不是让整个订单详情页卡住。

  ---

  ---

  提示如果你正面临 Java 后端线上难题，请关注我。下一篇将讨论 Redis 延迟双删还是读到脏数据？一次缓存一致性事故。

  此系列会持续更新 Spring 事务、线程池、JVM、MySQL、Redis 与 MQ 的真实踩坑案例与复现。