Java中处理CompletableFuture超时应放弃结果而非中断线程，推荐使用orTimeout()抛TimeoutException走异常兜底，或completeOnTimeout()静默返回默认值，二者均不终止任务执行且需配合自定义线程池与超时客户端。
Java 中处理 CompletableFuture 异步任务超时，核心是**不让任务无限等待，同时避免资源泄漏和线程堆积**。关键不在于“中断线程”，而在于“及时放弃结果、返回降级值或抛出可控异常”。JDK 8 原生不支持强制终止运行中任务，但提供了两个轻量、声明式、线程安全的超时方法： orTimeout() 和 completeOnTimeout()。
用 orTimeout() 主动抛异常，走异常兜底逻辑
当任务超时，它会以 TimeoutException 标记为异常完成状态，适合需要明确感知失败并执行降级、日志、告警等操作的场景。
-
语法简洁：直接链式调用
.orTimeout(2, TimeUnit.SECONDS) -
异常可捕获：配合
exceptionally()或handle()处理超时情况 - 不干扰原任务执行：超时后原任务仍在后台运行（需确保其可安全“泄露”，比如无副作用、有资源自动释放）
示例：
CompletableFutureThread.sleep(3000); // 模拟慢任务
return "done";
})
.orTimeout(1, TimeUnit.SECONDS)
.exceptionally(ex -> {
if (ex instanceof TimeoutException) {
System.out.println("调用超时，返回默认值");
return "default";
}
return "error";
});
用 completeOnTimeout() 静默替换结果，适合兜底优先
超时后直接把 CompletableFuture 设置为指定的默认值，任务本身是否继续执行不影响最终结果。语义更偏向“最多等 X 秒，超时就用备选值”。
立即学习“Java免费学习笔记（深入）”；
-
无异常打扰：不抛
TimeoutException，流程更平滑 - 结果确定性强：无论任务是否完成，最终都返回你指定的值（或 null）
- 适合简单降级：如缓存未命中时返回空列表、接口不可用时返回静态文案
示例：
CompletableFuture- > items = CompletableFuture.supplyAsync(this::fetchFromRemote)
.completeOnTimeout(Collections.emptyList(), 800, TimeUnit.MILLISECONDS);
别踩坑：超时 ≠ 线程中断，也不等于任务停止
orTimeout() 和 completeOnTimeout() 都不会调用 Thread.interrupt()，也不会终止正在执行的计算逻辑（比如密集循环、数学运算、IO 等）。它们只是改变 CompletableFuture 的完成状态。
- 如果任务内部有阻塞调用（如
Thread.sleep()、queue.take()），中断标志可能触发InterruptedException—— 但这依赖任务自己响应中断 - 手动轮询
Thread.currentThread().isInterrupted()虽可行，但侵入业务、易遗漏，不推荐作为首选 - 真正要控制任务生命周期，应从源头设计：使用带超时的客户端（如 OkHttp、Feign）、数据库查询加 query timeout、RPC 框架内置超时机制
配套建议：线程池 + 显式超时策略才完整
仅靠超时方法不够，还需配合合理的执行环境：
-
禁用 commonPool：不要依赖
ForkJoinPool.commonPool()，自定义线程池（如ThreadPoolExecutor）并设好队列容量与拒绝策略 -
避免主线程卡死：慎用
join()或get()，尤其在非 IO 线程（如 Web 容器线程）中；优先用thenApply等非阻塞链式回调 - 监控与告警：对高频超时任务打点（如 Micrometer 计数器），便于定位下游稳定性问题
