Java CompletableFuture 做超时控制:orTimeout、completeOnTimeout,以及别让超时拖垮线程池调用一个第三方接口,对方偶尔抽风一卡就是 30 秒,你的线程死等,并发一高线程池被占满,整个服务雪崩——这是超时控制没做好的经典事故。很多人以为CompletableFuture.get(3, SECONDS)就叫超时,其实那只是「你不等了」,后台任务还在跑、线程还占着。这篇讲清楚get超时和真正的任务级超时区别在哪,怎么用orTimeout/completeOnTimeout,以及为什么超时后线程池仍可能被拖垮。误区:get(timeout) 不是任务超时先看最常见的写法:CompletableFutureStringfutureCompletableFuture.supplyAsync(()-slowCall());try{Stringresultfuture.get(3,TimeUnit.SECONDS);// 只等 3 秒}catch(TimeoutExceptione){// 我以为任务被取消了……其实没有}get(3, SECONDS)抛TimeoutException只代表当前线程不再等待,那个slowCall()还在后台线程里继续跑,直到它自己结束。线程没释放,资源没回收。如果你以为超时就万事大吉,高并发下这些「僵尸任务」会把线程池吃干。Java 9 的正解:orTimeoutorTimeout是 Java 9 加的,它给 future本身加超时:到点还没完成,future 直接以TimeoutException异常完成,你可以链式处理:CompletableFutureStringfutureCompletableFuture.supplyAsync(()-slowCall()).orTimeout(3,TimeUnit.SECONDS)// 3 秒没完成就异常完成.exceptionally(e-{// e 是 TimeoutException,走降级逻辑returndefault value;});Stringresultfuture.join();// 最多等 3 秒,拿到结果或降级值和get(timeout)的区别:orTimeout让 future 进入完成状态,后续的exceptionally、handle都能接住,超时被整合进异步链路里,而不是靠调用方去 catch。只想给个兜底值:completeOnTimeout如果超时时你不想抛异常,只想返回一个默认值,用completeOnTimeout更直接:StringresultCompletableFuture.supplyAsync(()-slowCall()).completeOnTimeout(fallback,3,TimeUnit.SECONDS)// 超时就用 fallback 完成.join();到点还没结果,future 直接以fallback正常完成,不走异常分支。适合「拿不到就给缺省」的读场景,比推荐位、非核心配置。关键坑:超时了,任务线程并没有停这是最容易被忽略、也最致命的一点。orTimeout/completeOnTimeout让future完成了,但那个真正在跑slowCall()的工作线程根本不知道,它还在傻等第三方接口返回:CompletableFuture.supplyAsync(()-{Thread.sleep(30_000);// 模拟慢调用,超时后这行还在跑满 30 秒returndone;},executor).orTimeout(3,TimeUnit.SECONDS);// future 3 秒后异常完成,但 executor 里那个线程要占满 30 秒才释放后果:如果你用的是固定大小线程池,超时请求源源不断进来,每个都占着线程跑满真实耗时,3 秒的「超时」根本没帮线程池减负。超时保护的是调用方的响应时间,不是被调用任务的执行。想真正释放资源,得让底层调用本身可中断/可超时。以 HTTP 为例,给 client 设连接和读取超时才是根治:// 让底层调用自己就能超时,而不是只在外层包 orTimeoutHttpClientclientHttpClient.newBuilder().connectTimeout(Duration.ofSeconds(2)).build();HttpRequestreqHttpRequest.newBuilder(uri).timeout(Duration.ofSeconds(3))// 读取超时,到点底层抛异常、释放线程.build();记住这条:orTimeout是外层的「兜底闹钟」,底层调用的超时才是真正让线程回收的东西,两者要配合用。别用公共 ForkJoinPool 跑阻塞任务supplyAsync(fn)不传 executor 时,默认用公共的ForkJoinPool.commonPool()。它的线程数默认约等于 CPU 核数,是给计算密集任务设计的。你往里塞会阻塞的 IO 任务,几个慢调用就能把公共池占满,连累 JVM 里其他用到 commonPool 的代码(parallelStream 等)一起卡:// 危险:阻塞 IO 跑在公共池,会拖累全 JVM 的并行任务CompletableFuture.supplyAsync(()-blockingIoCall());// 正确:IO 任务用自己的专属线程池,大小按 IO 等待时间调大ExecutorServiceioPoolExecutors.newFixedThreadPool(50);CompletableFuture.supplyAsync(()-blockingIoCall(),ioPool);IO 密集任务用独立线程池,和计算任务、和 JVM 公共池隔离开,一个慢下游最多拖垮它自己那个池,不会波及全局。完整示例:超时 降级 隔离把上面的点拼起来,一个能用于生产的写法:privatestaticfinalExecutorServiceIO_POOLExecutors.newFixedThreadPool(50);publicStringfetchWithFallback(Stringkey){returnCompletableFuture.supplyAsync(()-remoteService.get(key),IO_POOL)// 专属池,隔离.completeOnTimeout(cache.get(key),3,TimeUnit.SECONDS)// 超时用缓存兜底.exceptionally(e-{// 调用出错也兜底log.warn(fetch failed for {}: {},key,e.toString());returncache.get(key);}).join();}外层 3 秒超时保住响应时间,exceptionally接住真实异常,IO 池做隔离。再配合remoteService底层自己的读超时,线程才能及时回收。小结future.get(timeout)只是「当前线程不等了」,后台任务和线程照样占着,不是任务超时。orTimeout让 future 超时异常完成、可链式exceptionally降级;completeOnTimeout直接给兜底值。超时不会停止底层任务线程:真正释放资源要靠底层调用(如 HTTP client)自己的超时。阻塞 IO 别跑在默认commonPool,用独立线程池隔离,避免拖垮全 JVM。生产写法 专属池隔离 orTimeout/completeOnTimeout 兜底 底层超时,四者缺一不可。一句话记忆点:orTimeout保的是你的响应时间,底层超时保的是你的线程池——只做前者,雪崩迟早找上门。