CompletableFuture.orTimeout 超时了任务却还在跑：一次 30 分钟 commonPool 线程耗尽的排查与「超时即停」的正确姿势

作者谢若衡-858

CompletableFuture线程池超时ForkJoinPoolResilience4j性能调优

作者：谢若衡-858｜中间件研发｜8 年经验栈：JDK 17.0.9、Spring Boot 3.1.5、OkHttp 4.12.0、Resilience4j 2.2.0

一、现象：orTimeout 3 秒后"超时"了，但服务 30 分钟后才"死"

去年 11 月，我们的订单聚合服务（4 台 ECS，8C16G，JDK 17）上线了一个"一屏聚合"接口：并行调 4 个下游（用户中心、订单服务、物流追踪、优惠券），用 CompletableFuture.allOf 等待全部完成，外层套 orTimeout(3000, MILLISECONDS)，超时后降级返回已到达的部分。

代码看起来没毛病：

CompletableFuture<UserInfo> userF = CompletableFuture.supplyAsync(() -> userClient.get(uid));
CompletableFuture<LogisticsInfo> logiF = CompletableFuture.supplyAsync(() -> logisticsClient.get(orderId));
CompletableFuture<CouponInfo> couponF = CompletableFuture.supplyAsync(() -> couponClient.get(uid));
CompletableFuture<OrderInfo> orderF = CompletableFuture.supplyAsync(() -> orderClient.get(orderId));

CompletableFuture.allOf(userF, logiF, couponF, orderF)
    .orTimeout(3000, TimeUnit.MILLISECONDS)
    .join();

上线第一天，物流侧的 MySQL 出现慢查询（一条 JOIN 4 张表的查询 P99 从 210ms 飙到 47s），我们监控看到 orTimeout 正常触发，接口 P99 稳定在 3.1s（就是那个 3s 超时），降级率从 0.3% 涨到 41%，看起来一切在控制之中。

但 30 分钟后，整个服务 4 台实例全部不可用——不只是聚合接口，连健康检查、定时对账、HTTP 回调都卡死了。JStack 抓下来，所有 7 个 commonPool 线程全部阻塞在 logisticsClient.get() 内部的 SocketInputStream.read() 上。

算一笔账：

接口 QPS 约 120（4 台分摊，每台 30 QPS）
每个请求产生 1 个物流调用，卡住 47s
每台实例：30 × 47 ≈ 1410 个任务在飞
但 commonPool 只有 8 - 1 = 7 个线程
7 个线程全被物流慢任务占满后，其他所有任务（包括其他 3 个下游的调用、健康检查、Spring 的 @Scheduled 任务）全部排队

这就是为什么 orTimeout "成功"超时了，但服务还是死了——超时只完成了 Future 的状态，没有停掉线程里的活。

二、根因：CompletableFuture 的 complete ≠ cancel，而且它物理上无法 cancel

2.1 orTimeout 到底做了什么

看 JDK 17 的 CompletableFuture.orTimeout 源码（简化）：

public CompletableFuture<T> orTimeout(long timeout, TimeUnit unit) {
    if (unit == null) throw new NullPointerException();
    return (isDone()) ? this
        : (AltResult)(d = new AltResult())
            .uniWaitForTimeout(this, timeout, unit,
                new TimeoutException("Timed out after " + timeout + " " + unit));
}

核心就一句话：注册一个延迟任务，到期后调用 complete(TimeoutException)。complete() 把内部状态从 NEW 翻成 COMPLETED，通知所有 thenApply / whenComplete / join 的回调链。

它不会调用 Thread.interrupt()，不会释放线程池里的任务，不会关闭 TCP 连接。

2.2 cancel(true) 也救不了

有人会说"那我 cancel(true) 不就行了"。不行。看 CompletableFuture.cancel 的 Javadoc 原文：

Note that in either case, the underlying task (if any) is not interrupted.

CompletableFuture 没有持有执行它的 Thread 引用，cancel 只是改状态。这和 java.util.concurrent.Future 不同——FutureTask.cancel(true) 会调 Thread.interrupt()，但那是因为你把任务包在 FutureTask 里、跑在 ExecutorService 的线程上，有线程句柄。

CompletableFuture 是"无主"的：它不知道自己在哪个线程上、也不知道自己在哪个队列里，所以物理上无法取消。

2.3 commonPool 的"公地悲剧"

所有没传 executor 的 CompletableFuture.supplyAsync / runAsync、所有 parallelStream、所有 ForkJoinTask，默认都跑在 ForkJoinPool.commonPool 上。这个池的线程数 = Runtime.getRuntime().availableProcessors() - 1（JDK 8+）。

8C 机器 → 7 个线程。这 7 个线程是全 JVM 共享的。一个慢物流调用卡住 1 个线程 47s，等于全 JVM 有 1/7 的并发能力被一个下游吃掉了。

三、正确做法：超时必须在 I/O 层兜底，线程池必须隔离

3.1 第一原则：给每个下游 HTTP 调用设置 read timeout

这是最根本的修复。不管上层怎么"超时"，只要 TCP 层的 read 不超时，线程就永远不释放。

OkHttp（4.12.0）：

OkHttpClient client = new OkHttpClient.Builder()
    .connectTimeout(1, TimeUnit.SECONDS)
    .readTimeout(2, TimeUnit.SECONDS)    // ← 关键：2s 读不到数据就断开
    .writeTimeout(2, TimeUnit.SECONDS)
    .build();

Spring Cloud OpenFeign（Spring Boot 3.1.x）：

feign:
  client:
    config:
      logistics-client:
        connectTimeout: 1000
        readTimeout: 2000

设置了 read timeout 后，物流侧即使卡 47s，客户端在 2s 后就会收到 SocketTimeoutException，线程释放，连接关闭。orTimeout(3s) 变成真正的兜底，而不是唯一的防线。

MySQL 侧同理：

SET SESSION max_execution_time = 5000;  -- 5s，MySQL 5.7.8+

或者在 HikariCP 里：

spring:
  datasource:
    hikari:
      connection-timeout: 3000   # 拿连接超时
      validation-timeout: 2000   # 连接校验超时

3.2 第二原则：每个下游调用用独立线程池

// 每个下游一个池，互相隔离
private final ExecutorService userPool = new ThreadPoolExecutor(
    4, 4, 0, TimeUnit.MILLISECONDS,
    new SynchronousQueue<>(),
    r -> { Thread t = new Thread(r); t.setName("user-" + t.getId()); t.setDaemon(true); return t; },
    new ThreadPoolExecutor.AbortPolicy());

private final ExecutorService logisticsPool = new ThreadPoolExecutor(
    4, 4, 0, TimeUnit.MILLISECONDS,
    new SynchronousQueue<>(),
    r -> { Thread t = new Thread(r); t.setName("logistics-" + t.getId()); t.setDaemon(true); return t; },
    new ThreadPoolExecutor.AbortPolicy());

// 使用
CompletableFuture<LogisticsInfo> logiF =
    CompletableFuture.supplyAsync(() -> logisticsClient.get(orderId), logisticsPool);

这样即使物流全卡死，也只会卡死 logisticsPool 的 4 个线程，不会波及 user / coupon / order 的调用。

3.3 第三原则：如果一定要用"超时取消"，用 Resilience4j TimeLimiter

Resilience4j 2.2.0 的 TimeLimiter 内部会把任务提交到一个独立 executor，超时后调用 Future.cancel(true)——因为它是通过 ExecutorService 跑的，有线程句柄，能 interrupt。

ExecutorService dedicated = Executors.newFixedThreadPool(4);
TimeLimiter timeLimiter = TimeLimiter.ofConfig(
    TimeLimiterConfig.custom()
        .timeoutDuration(Duration.ofSeconds(2))
        .cancelRunningFuture(true)   // ← 关键：超时后 cancel(true)
        .build());

CompletableFuture<LogisticsInfo> logiF = timeLimiter.executeFutureSupplier(
    () -> CompletableFuture.supplyAsync(() -> logisticsClient.get(orderId), dedicated));

注意 cancelRunningFuture(true)——默认是 false，不取消。

3.4 监控：commonPool 必须可观测

ForkJoinPool commonPool = ForkJoinPool.commonPool();
Gauge.builder("commonPool.activeThreads", commonPool, ForkJoinPool::getActiveThreadCount).register(meterRegistry);
Gauge.builder("commonPool.queuedTasks", commonPool, ForkJoinPool::getQueuedTaskCount).register(meterRegistry);

设告警：activeThreads >= parallelism 且 queuedTasks > 100，持续 1 分钟即触发。

四、踩过的坑与反直觉之处

坑 1：orTimeout 和 completeOnTimeout 都不取消任务。 两者都只改 Future 状态。orTimeout 额外抛 TimeoutException，completeOnTimeout 返回一个默认值，仅此而已。我在 code review 里把 orTimeout 当"超时取消"用，review 也没人提——因为它看起来就像"超时后一切结束了"。

坑 2：CompletableFuture.cancel(true) 也不取消。 传 true 也不调 interrupt()。Javadoc 里写得很清楚："the underlying task (if any) is not interrupted"。这和 FutureTask.cancel(true) 的行为完全不同，是很多人踩的坑。

坑 3：commonPool 的线程数比你想的少。 8C 机器只有 7 个线程（availableProcessors() - 1），16C 机器 15 个。如果你同时用了 parallelStream、CompletableFuture（无 executor）、ForkJoinTask，它们全部共享这 7 个线程。一个慢任务就能让全 JVM 的异步操作排队。

坑 4：SynchronousQueue + AbortPolicy 是"要么跑要么拒"，没有缓冲。 如果下游全卡，新请求直接 RejectedExecutionException，这比排队堆积好——至少不会把线程池拖死。但你要在业务层 catch 住这个异常做降级。

坑 5：MySQL 的 max_execution_time 对 SELECT ... FOR UPDATE 不生效。 如果你用的是事务内的锁查询，这个参数不管用，得靠 lock_wait_timeout（默认 31536000s ≈ 365 天）。

五、结论与可复用清单

CompletableFuture.orTimeout / completeOnTimeout 只保证"调用方按时拿到结果"，不保证"任务按时停止"。 超时兜底必须在 I/O 层（HTTP read timeout、DB statement timeout）做。
永远不要在业务代码里 CompletableFuture.supplyAsync(supplier) 不传 executor。 默认 commonPool 是全 JVM 共享的公地，一个慢任务拖死所有人的并发。
每个下游调用用独立线程池 + SynchronousQueue + AbortPolicy，故障隔离到池级别。
如果必须"超时即取消"，用 Resilience4j TimeLimiter + cancelRunningFuture(true)，它底层走 ExecutorService，有线程句柄能 interrupt。
监控 commonPool 的 activeThreadCount 和 queuedTaskCount，设告警阈值。
给所有 HTTP 客户端设置 connect/read/write timeout，这是超时的最后防线，也是第一道防线。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。