企业官网建设流程全解析

先别急着写代码，我先把话放这儿：凡是写过CompletableFuture并发调用的朋友，十有八九都踩过超时这个坎儿。CompletableFutureTimeout听起来不过是“加一个超时参数”的小事，真正做起来却会牵扯到线程池、任务状态、异常传播、定时调度器这一整套底层机制。我在真实项目里因为超时设置缺失吃过几次大亏，线上线程池被拖死、调用方无限等待、链路雪崩，每一起事故都够写一篇复盘。这篇文章就把我从这个坑里爬出来的完整经验记录下来，包含方案选型、源码级原理解读、真实场景改造和避坑手册，适合所有在用CompletableFuture做异步编排、或者正被超时问题折磨的 Java 开发。

1. 超时问题为何如此难缠：先搞清 CompletableFuture 的“默认行为”

1.1 从 Future 到 CompletableFuture：异步设计的美好与现实

以前我们用FutureTask或者ExecutorService.submit()拿结果，核心动作就是future.get()。这个方法有重载，可以传超时时间，但绝大多数人写业务代码时根本不会传，直接get()一路等到天荒地老。CompletableFuture出来后，异步编排能力大幅增强，thenApply、thenCompose、allOf、anyOf这些组合方法让代码看起来非常优雅，但我也观察到：正因为 API 太顺滑了，很多人在构建完链路之后忘记给这条链路加一个“截止时间”。

CompletableFuture默认的“不超时”行为是一颗隐藏的雷。你supplyAsync提交一个任务到线程池，如果这个任务本身因为下游服务慢、锁竞争、网络抖动而卡住，那么任何依赖这个 future 的后续操作都会被迫等待。get()会阻塞当前线程，join()也是一样，只是把受检异常包装成CompletionException而已。更隐蔽的是thenApply这类依赖方法：它们会在源 future 完成时立刻执行，但源 future 不完成，整条链就一直挂在那里。

有一个真实的线上事故非常典型。某服务用一个固定大小的线程池执行外部接口调用，开发者写了类似future.get()的代码，没有传超时。某天依赖的下游接口响应时间从 80ms 飙升到 30 秒，这个线程池里的线程全部被get()占住，后续请求排队，队列再被打满，最后触发拒绝策略，整条业务链路大范围报错。事后看监控，线程池活跃线程数直接是一条直线顶到上限，持续了十几分钟。这个事故最大的教训就是：异步不是不做超时控制的理由，恰恰相反，异步场景比同步场景更需要显式的超时约定。

1.2 两个维度的超时：任务侧与等待侧

提到超时，我建议你先分清楚两个维度，因为它们经常被混为一谈。

第一个维度是等待侧超时。调用方在某个时间点前必须拿到结果，拿不到就走降级或者报错。典型的做法就是future.get(2, TimeUnit.SECONDS)，这是最朴素的等待侧超时。

第二个维度是任务侧超时。任务本身应该知道自己有 deadline，到点后主动放弃执行，或者被通知停止。CompletableFuture里的orTimeout就属于这一侧，它通过给 future 注册一个定时任务，到点后把 future 置为异常完成状态。

这两个维度是独立存在的。你可以在等待侧加超时，但任务本身还在线程池里跑着；你也可以在任务侧通过orTimeout让 future 超时完成，但底层那个supplyAsync提交的任务如果没有配合中断或取消逻辑，依然不会停。这也是后面我要重点讲的：超时完成不等于任务终止。很多刚接触CompletableFuture的开发者会误以为orTimeout能把正在运行的任务“掐死”，其实它只是把 future 这个“结果容器”的状态改变了，真正干活的线程并不感知。

1.3 为什么默认不超时是个设计缺陷

从设计哲学上看，CompletableFuture追求的是“异步非阻塞”，大量回调都是事件驱动的。但如果你在业务代码里用get()把一个线程死死压住等结果，就等于把异步模型退化成同步阻塞模型，线程池资源被无意义占用。这也是为什么很多人说“CompletableFuture虽好，用不好还不如不用”。

我见过不少代码评审里，大家只关注thenApply和thenCompose用得对不对，却很少有人追问“这个 future 如果永远不完成会怎样”。实际上，分布式系统里“永远不完成”是常态，上下游任何一个节点出问题，你的 future 就可能进入无响应状态。没有超时机制，整个链路就没有韧性。所以下面要讲的三种超时方案，不是可选项，而是必选项。

2. 三种超时实现方案逐一拆解：get、orTimeout、completeOnTimeout 怎么选

2.1 方案A：get(timeout) 最朴素的阻塞兜底

先看最常见的写法：

CompletableFuture<Order> future = CompletableFuture.supplyAsync( () -> orderService.queryOrder(orderId), orderExecutor ); try { Order order = future.get(2, TimeUnit.SECONDS); return order; } catch (TimeoutException e) { log.warn("query order timeout, orderId={}", orderId); return Order.defaultOrder(); } catch (ExecutionException e) { log.error("query order failed", e.getCause()); throw new BizException("order query error"); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new BizException("interrupted"); }

这种方案的优点是直观、心智负担小，但缺点也很明显：get(timeout)是阻塞调用，当前线程必须等到 future 完成或超时才能继续。如果你是在thenApply回调里嵌套调用get()，还会造成线程池里的工作线程被二次阻塞，进一步加剧线程饥饿。

另外，InterruptedException的处理很容易被忽略。很多人直接e.printStackTrace()就完事了，但没有恢复中断状态，线程池里的线程如果带着中断标记继续被复用，后续任务可能出现各种诡异行为。我在实际编码里只要捕获InterruptedException，第一件事一定是Thread.currentThread().interrupt()。

2.2 方案B：orTimeout 非阻塞式状态变更

Java 9 给CompletableFuture加了两个杀手级方法：orTimeout和completeOnTimeout。先说orTimeout：

CompletableFuture<Order> future = CompletableFuture.supplyAsync( () -> orderService.queryOrder(orderId), orderExecutor ) .orTimeout(2, TimeUnit.SECONDS) .exceptionally(ex -> { if (ex instanceof TimeoutException) { return Order.defaultOrder(); } throw new CompletionException(ex); });

orTimeout做的事情非常巧妙：它在内部注册了一个定时任务，到点后如果 future 还没完成，就把 future 以TimeoutException异常完成。注意这个“如果还没完成”的条件——如果任务在超时之前已经正常完成，定时任务会发现 future 已完成，什么也不做。

这个方案最大的好处是非阻塞。调用线程不会被卡住，超时的判断完全交给事件驱动。你可以继续把orTimeout的结果传给下一个thenApply，整条链路是流畅的。我在实际项目里，只要是异步链路上的单点 future，通通会给它挂一个orTimeout。

但这里有个异常传播的细节需要特别注意。orTimeout让 future 以TimeoutException完成，但这个异常不会自动触发exceptionally或者handle之前的thenApply。我在代码里用exceptionally捕获时专门做了类型判断，因为一个 future 所在的链路里可能既有时限异常，又有业务异常，区分不了就全部降级，会把真正的错误吞掉。

2.3 方案C：completeOnTimeout 降级填充

completeOnTimeout跟orTimeout长得几乎一样，但语义完全不同：

CompletableFuture<Order> future = CompletableFuture.supplyAsync( () -> orderService.queryOrder(orderId), orderExecutor ) .completeOnTimeout(Order.defaultOrder(), 2, TimeUnit.SECONDS);

超时后，future 不是以异常完成，而是以你传入的默认值正常完成。这个默认值会顺着后续的thenApply一路走下去，整个链路不会感知到超时，只会拿到一个降级后的结果。

有些场景下我非常喜欢completeOnTimeout。比如展示型接口里，某个推荐位的数据拿不到时，完全可以用一个空对象顶上，用户侧没有感知，只是内容少了一块。但如果涉及资金、库存这类核心数据，用默认值填充就要格外谨慎，宁可让接口报错也不能给用户一个错误的结果。

这里有一个很反直觉的点：你调用completeOnTimeout之后，原 future 并不会变成默认值，返回的是一个新的 future。很多人在链式调用中忽略这个返回值，结果发现降级根本没生效。我在代码评审里专门提过这个点，凡是用completeOnTimeout必须接住返回值，并基于这个新 future 继续后续操作。

2.4 一张对比表格看清本质区别

这么一对比就能发现，真正适合大多数异步编排场景的是orTimeout和completeOnTimeout，get(timeout)更像一个应急补丁。下面我就从源码角度解释orTimeout到底是怎么做到“到点自动完成”的。

3. 原理深挖：orTimeout 的调度机制和异常传播链路

3.1 Delayer：藏在 CompletableFuture 里的定时调度器

orTimeout的实现其实不复杂，但非常精巧。我直接说结论：它用了一个名为Delayer的静态定时调度器，本质上是一个持有ScheduledThreadPoolExecutor的单例。这个调度器专门用来执行“延迟让 future 超时完成”这类任务。

当你调用orTimeout(2, TimeUnit.SECONDS)时，底层大致做了这么几件事：

// 简化后的逻辑 if (result == null) { // 还没完成，注册一个延迟任务 Delayer.delay(new Timeout(this), timeout, unit); } return this;

Timeout是一个Runnable，它在到达指定时间后执行，内部尝试调用completeExceptionally(new TimeoutException())。注意这里有个关键的 CAS 逻辑：completeExceptionally只有在这个 future 还处于未完成状态时才会成功。如果任务提前完成，这个“补刀”就会失败，不会影响正常结果。

用生活类比来解释，Delayer就像一个闹钟管理员。你告诉它“两分钟之后提醒我超时”，它到点就真的去敲你那个 future 的门。但如果你的 future 已经提前把事情办完了，它就扑了个空，也无所谓。

这个设计有一个好处：定时任务本身不会阻塞业务线程池。Delayer用的是独立的小线程池，配置的核心线程数很少，专门跑这类控制逻辑。所以orTimeout对业务线程池的侵占可以忽略不计。

3.2 TimeoutException 的传播：exceptionally 与 handle 的捕获细节

orTimeout让 future 以TimeoutException异常完成后，异常会沿着依赖链传播。thenApply不会执行，exceptionally和handle会接收到异常。这里要特别提醒一个我踩过的坑：如果你在orTimeout之后没有接任何异常处理，超时异常会一直冒泡到调用方，而且它在join()时会被包装成CompletionException，里面裹着TimeoutException。

所以如果你用join()拿结果，日志里看到的堆栈信息会把人绕晕：

java.util.concurrent.CompletionException: java.util.concurrent.TimeoutException

这时候你排查方向会有两个：一是为什么任务没在限定时间内完成，二是为什么TimeoutException没有被子链路处理掉。我在代码评审中给出的标准模板是：orTimeout后必须立刻接exceptionally或handle，不要让超时异常往下游冒。下面这个写法是我的常用模板：

CompletableFuture<Order> orderFuture = CompletableFuture .supplyAsync(() -> orderClient.query(orderId), businessExecutor) .orTimeout(800, TimeUnit.MILLISECONDS) .handle((order, throwable) -> { if (throwable != null) { log.warn("query order fallback, orderId={}, err={}", orderId, throwable.toString()); return Order.defaultOrder(); } return order; });

handle比exceptionally更稳妥一点，因为它不仅能捕获异常，还能拿到正常结果，且不需要在exceptionally里做类型判断。当然，如果你明确只想在业务异常时降级、超时异常时返回一个特定值，那就用exceptionally配合instanceof TimeoutException判断，完全没问题。

3.3 最容易踩的坑：已经完成的 Future 上调用 orTimeout 是无效的

这个坑极其隐蔽，我一度以为是orTimeout的 bug，后来读了源码才明白是设计如此。

如果一个 future 已经进入完成状态（正常完成或异常完成），你再调用orTimeout会直接返回当前 future，不会注册任何定时任务。因为源码里第一关就是检查result != null，已完成的话根本没有必要设置超时。

但问题来了：如果你在链式调用的最末端调用orTimeout，前面所有阶段都已经执行完了，这个超时就是摆设。我举一个真实场景：

CompletableFuture.supplyAsync(() -> service.callA(), executor) .thenApply(a -> service.callB(a)) .thenApply(b -> service.callC(b)) .orTimeout(1, TimeUnit.SECONDS);

这段代码里，orTimeout虽然写在最后，但它实际控制的是整条链的超时吗？不是。orTimeout作用在最后一个thenApply返回的 future 上，这个 future 依赖前两个阶段。如果callA就卡住了，那么后续thenApply压根不会执行，最后一个 future 也一直处于未完成状态，这时orTimeout是真正生效的。所以这段代码反而是对的。

但如果你写成下面这样：

CompletableFuture<String> f = CompletableFuture.supplyAsync(() -> service.callA(), executor); f.thenApply(a -> service.callB(a)); f.orTimeout(1, TimeUnit.SECONDS);

f这个 future 只代表callA的结果，超时也只对callA生效，后面的thenApply不在管辖范围内。这种“把返回值丢了”的写法在真实代码里非常多，CompletableFuture链式操作每一步都会产生新 future，你要对哪条链设超时，就必须把orTimeout挂在那条链最终返回的 future 上，并且接住返回值。

3.4 从源码看 completeOnTimeout 与 orTimeout 的共通逻辑

completeOnTimeout的底层结构跟orTimeout几乎一致，唯一区别是完成时的动作。orTimeout调completeExceptionally(new TimeoutException())，completeOnTimeout调complete(value)。就这一个差异，导致整个链路的语义完全不同。理解这一点后，你就不需要在记忆层面区分两者了，只要问自己：超时后你想让 future 失败，还是想让它带值成功？选对应的方法即可。

不过还有一个细节要记住：这两个方法都是 Java 9 才加的。如果你的项目还停留在 Java 8，那只能用get(timeout)+ 自研方案。现在很多公司虽然主版本写着 Java 8，但实际运行环境和编译目标早就切到 Java 11 以上了，能用新 API 尽量用，自研超时方案的维护成本远超想象。

4. 实际业务场景重构：从无超时到有超时的完整改造路径

4.1 场景一：RPC 调用，用默认值兜底

先看一个最常见的场景：调用下游订单服务拿数据，下游偶尔抖动。改造前：

CompletableFuture<Order> future = CompletableFuture.supplyAsync( () -> orderRpcClient.queryOrder(orderId), orderTaskExecutor ); return future.get(); // 没有超时，线程可能被卡死

改造后我通常会用orTimeout+exceptionally的组合：

CompletableFuture<Order> future = CompletableFuture .supplyAsync(() -> orderRpcClient.queryOrder(orderId), orderTaskExecutor) .orTimeout(1, TimeUnit.SECONDS) .exceptionally(ex -> { if (ex instanceof TimeoutException) { log.warn("order query timeout, use default, orderId={}", orderId); return Order.defaultOf(orderId); } throw unwrapCompletionException(ex); // 业务异常继续往外抛 }); return future.join();

改造后有三个明显变化：

• 线程池线程被卡死的概率大幅下降，因为超时是事件驱动，不需要调用线程傻等。
• 超时和业务异常被区分开，超时走降级，业务异常继续抛，不会混为一谈。
• 日志里能明确看到“timeout”字样，后续排查问题时定位速度比之前快很多。

当然，这里exceptionally里重新抛出的异常，也会导致调用方join()时看到CompletionException。如果你想保留原始异常类型，可以在join()之后统一解包。但我个人经验是：这里的核心诉求是“快速失败”和“有日志”，没必要为了异常类型的精确性把代码搞复杂。

4.2 场景二：缓存击穿，返回旧缓存

缓存场景里，最怕的是缓存过期时大量请求同时回源，把数据库或下游服务打爆。这里超时降级的目标不是“快速失败”，而是“返回一个还说得过去的值”，所以completeOnTimeout更合适。

思路是这样：正常逻辑是查缓存，没有则回源数据库，然后把结果写回缓存。但回源操作不能没有上限。我给回源操作加一个超时，超时后返回一个旧缓存值（哪怕这个值已经过期，也比报错强）。

CompletableFuture<ProductInfo> sourceFuture = CompletableFuture .supplyAsync(() -> productDao.queryFromDb(productId), dbExecutor) .completeOnTimeout(lastCachedProduct, 500, TimeUnit.MILLISECONDS); ProductInfo result = sourceFuture.join(); if (result == lastCachedProduct && lastCachedProduct == null) { throw new BizException("product not found and db timeout"); }

这里我故意做了个判断：如果超时后返回的旧缓存是 null，说明连旧缓存都没有，这时候再返回默认值就没有意义了，必须抛异常。这个细节很多人会漏掉，会导致超时时静默返回 null，下游 NPE。

4.3 场景三：allOf 并行聚合，整体超时控制

多个CompletableFuture并发执行，最后allOf聚合，这是非常常见的编排模式。但allOf返回的 future 是所有子任务的“合成体”，它本身也不会主动超时。如果其中一个子任务卡死，整个allOf卡死。改造方案是在allOf上再套一层orTimeout：

CompletableFuture<List<Object>> futures = CompletableFuture .allOf(f1, f2, f3) .thenApply(v -> Stream.of(f1, f2, f3) .map(CompletableFuture::join) .collect(Collectors.toList())) .orTimeout(2, TimeUnit.SECONDS) .exceptionally(ex -> { log.warn("parallel aggregate timeout or failed, err={}", ex.toString()); return Collections.emptyList(); });

这里有一点要特别注意：allOf会等待所有子任务，但你给聚合 future 设置了超时，不代表子任务不被执行。超时后，那三个子任务如果还没完成，join()依然会阻塞，因为你是在thenApply里同步join()的。所以这里不能简单地认为是“2 秒后整体结束”，更准确的理解是“2 秒后聚合 future 以异常完成，后续exceptionally返回空列表，但线程池里的子任务还在跑”。

如果你希望超时后不再等待那些慢任务，就不能用allOf+join()，而是要用anyOf结合时间判断，或者干脆给每个子任务单独加orTimeout。我在实际项目中更倾向于给每个子任务单独设超时，这样就算有一个任务特别慢，它自己的 future 也会先超时完成，不会拖累整体。

4.4 依赖编排场景：不同阶段不同超时

有一类场景是任务之间有时序依赖，比如先查用户信息，再用用户信息查订单列表，最后查推荐位。三个阶段的最佳响应时间不一样，一个统一的超时时间反而是不合理的。

我的处理方式是给每个阶段单独设梯度超时：

CompletableFuture<User> userFuture = CompletableFuture .supplyAsync(() -> userService.getUser(uid), userExecutor) .orTimeout(300, TimeUnit.MILLISECONDS); CompletableFuture<List<Order>> orderFuture = userFuture .thenCompose(user -> CompletableFuture .supplyAsync(() -> orderService.listByUser(user), orderExecutor) .orTimeout(800, TimeUnit.MILLISECONDS)); CompletableFuture<List<Recommend>> recFuture = orderFuture .thenCompose(orders -> CompletableFuture .supplyAsync(() -> recommendService.build(orders), recExecutor) .orTimeout(500, TimeUnit.MILLISECONDS));

这种梯度超时的设计，核心目的是避免“上游一个 300ms 的小查询变成下游 3s 的隐形炸弹”。每一层都设一个阈值，任何一层卡住都会在本地快速失败，后续层也不会被拖下水。

不过这也有代价：整条链的最坏耗时是各个阶段超时时间之和，不是最大值。因为thenCompose是串行的。如果你需要的是整体 deadline，那就必须再对最终返回的 future 套一层orTimeout，以总时长兜底：

CompletableFuture<List<Recommend>> guarded = recFuture .orTimeout(1200, TimeUnit.MILLISECONDS);

这种“单点超时 + 整体兜底”的双层设计，我在生产环境验证下来是最稳的组合。既能快速定位是哪一段出了问题，又能保证最外层响应时间可控。

5. 线上避坑与问题排查手册

5.1 超时没有取消任务：线程池可能被“幽灵任务”占满

这是我最想强调的一点，也是线上最容易踩进去的大坑。

orTimeout让 future 超时完成，但那个实际执行的任务如果还在Thread.sleep()、在等锁、在调外部接口，它是完全感知不到 future 已经超时的。它会继续占用线程池里的一个线程，直到自己真正跑完。

设想一个场景：线程池核心线程数 10，10 个任务全部卡在下游 30 秒超时（假设下游也有超时），而你给 future 设置的orTimeout是 2 秒。那么 2 秒后这 10 个 future 都超时了，调用方降级返回，但线程池里这 10 个线程仍然被占着，30 秒内无法处理新请求。后续请求全部排队，系统 RT 飙升。

我遇到过类似的问题，最终的处理不是去掉orTimeout，而是同时要求任务内部必须配合中断检查。具体做法是：在supplyAsync内部，把网络调用也加上超时，并响应线程中断。如果你用的是CompletableFuture+ 阻塞队列，可以考虑用LinkedBlockingQueue.poll(timeout)替代take()。如果你控制不了下游调用的内部实现，那就必须把线程池的“最大线程数”和“队列容量”设计得足够保守，宁可丢弃请求，也别让线程被慢任务占满。

另外，CompletableFuture.cancel()也不是银弹。它只能取消那些还没开始执行或supplyAsync还没提交的任务，如果任务已经在线程里跑起来了，cancel(true)的中断信号未必能中断一个不响应 interrupt 的任务。所以不要把“超时”和“取消任务”混为一谈。

5.2 线程池隔离：不要让超时控制影响核心业务线程池

超时控制本身也要依赖线程资源。orTimeout内部用的是Delayer那个静态调度器，不是你的业务线程池，所以这一层没有污染问题。但如果你在业务线程池里执行一个get(timeout)，那这个等待行为本身就会占用业务线程。所以我在设计时有一个原则：能不用阻塞式等待，就不用阻塞式等待。

另一个容易踩的点是，有些开发者习惯用Executors.newFixedThreadPool创建线程池，而且不设置线程工厂和拒绝策略。这类线程池在超时场景下问题很大：线程池里线程全部被慢任务占住后，新任务进入队列，队列满后触发AbortPolicy直接抛异常。你本来是想用orTimeout快速失败，结果连失败的机会都没有，请求直接挂在提交任务这一步。

我现在的习惯是：任务类线程池不设队列，或者把队列长度设得很小，配合CallerRunsPolicy或者自定义拒绝策略。异步任务如果满到要被拒绝，说明系统的并发承载已经到瓶颈，这时候宁可丢弃也不该继续堆积。

5.3 一次排查记录：为什么某个 future 一直没超时

说一个真实的排查案例。当时监控上看到一个接口在极端情况下会卡到十几秒，但代码里明明加了orTimeout(2, TimeUnit.SECONDS)。排查了很久，最后发现orTimeout挂在了一个已经完成的 future 上。

代码长这样：

CompletableFuture<Void> f = CompletableFuture.runAsync(() -> init(), executor); f.whenComplete((v, e) -> log.info("init done")); // 这里以为设置了超时 f.orTimeout(2, TimeUnit.SECONDS);

问题出在whenComplete返回的新 future 没人接收，而orTimeout只对f生效。f本身就是一个runAsync返回的 future，只代表init()这个阶段。whenComplete创建的新 future 才是真正包含后续动作的。如果init()本身很快，f早就完成了，orTimeout当然没有任何意义；真正需要加超时的是whenComplete返回的那个新 future，但它被丢掉了。

这类问题在代码评审里非常难发现，因为编译不报错、运行不报错，只有压测或极端场景下才会暴露。我的建议是：凡是链式调用，不能丢失返回值；凡是需要超时保护的链路，orTimeout必须挂在该链路最终返回的 future 上，并且接收返回值。

5.4 接口返回时，用 getNow 还是 join？

最后一个常见问题是，future 已经通过orTimeout设置了超时，但你在获取结果时又调了join()，这时如果前面的exceptionally已经处理了异常，join()是能正常返回的；但如果exceptionally里重新抛了异常，join()会抛出CompletionException，这会在接口层产生 500 错误。

我建议在接口返回前统一用一个“安全获取”的工具方法：

private static <T> T safeGet(CompletableFuture<T> future) { try { return future.join(); } catch (CompletionException e) { Throwable cause = e.getCause(); if (cause instanceof TimeoutException) { // 超时在这里统一处理 log.warn("future timeout"); return null; } throw e; } }

这样可以把超时异常收敛到出口处，而不是散落在业务代码的各个exceptionally里。当然，如果你的业务代码已经在exceptionally阶段把超时和业务异常都处理掉了，那join()基本不会抛异常，这个工具方法不是必须的。

5.5 问题排查速查表

6. 最后的几条硬核经验

写到这里，把我在生产环境摸爬滚打出来的几条经验收个尾。

第一，每个异步任务都值得拥有自己的超时。不要依赖全局配置或框架兜底，框架层可能有超时，但那是整个调用的最大容忍时间，不等于每个异步节点都应该跑那么久。给每个节点设一个符合业务预期的超时，整体链路才会可控。

第二，超时时间的选择不能拍脑袋。我一般会看历史 P99 耗时，如果 P99 是 200ms，超时设 800ms 到 1s 比较合理。太小容易误杀慢请求，太大起不到保护作用。更稳妥的做法是把超时时间做成配置项，线上随时可以调整，不需要发版。

第三，日志里的超时必须要有辨识度。我现在要求团队所有超时降级日志统一带上timeout关键字和任务标识，这样告警和排障时可以一秒定位。否则一堆query order fallback的日志，你根本分不清是超时降级还是业务异常降级。

第四，能用 Java 9 的新 API 就尽量用。orTimeout和completeOnTimeout解决的是非常核心的异步超时诉求，纯手写的自研方案在正确性、性能和边界处理上很难跟 JUC 里的实现相媲美。我刚趟这条路的时候，也花了很多时间试图自己写定时触发逻辑，最后还是老老实实用标准 API 了。

说实话，CompletableFutureTimeout这个话题听起来小，但每个细节背后都对应着一次线上教训。把超时控制这件事做好，并发代码的鲁棒性会提升一大截。希望这篇文章能帮你少走几步弯路，尤其别在最基本的“返回值接住”“任务取消不等于超时”这两件事上翻车。