TimeoutException 是 Java 中表示等待超时的信号异常，由 Future.get()、tryLock() 等方法在超时后主动抛出，本身不管理超时逻辑；它仅说明“未等到结果”，不保证任务终止或资源释放。
TimeoutException 是什么，它真代表超时吗
Java 中的 TimeoutException 是一个受检异常（java.util.concurrent.TimeoutException），但它本身不触发、不测量、也不管理任何超时逻辑——它只是被其他类「抛出来」的信号。真正做超时控制的是 Future.get(long, TimeUnit)、Lock.tryLock(long, TimeUnit)、CompletableFuture.orTimeout() 这些方法。一旦它们内部判定超时，就抛出这个异常。
常见误解是：捕获了 TimeoutException 就等于“处理了超时”。其实不然——它只说明“某次等待没等到”，但后续资源是否释放、任务是否取消、线程是否还在跑，全靠你自己补。
-
Future.get()抛出TimeoutException后，Future仍处于未完成状态，任务可能仍在后台执行 -
CompletableFuture.orTimeout()会主动 cancel 底层任务（前提是任务支持中断） -
tryLock()抛出该异常后，锁肯定没拿到，但你要自己决定是否重试或降级
怎么安全地捕获并响应 TimeoutException
直接 catch (TimeoutException e) 很容易漏掉关键动作。重点不是“抓到异常”，而是“抓到之后做什么”。以下操作应成对出现：
- 总是配合
Future.cancel(true)（如果用的是Future）来尝试中断正在运行的任务 - 若使用
CompletableFuture，优先用orTimeout()+exceptionally()，避免手动调get() - 在
catch块里记录带上下文的日志，例如："API call to payment-service timed out after 2s, requestId=abc123" - 不要静默吞掉异常；即使走降级逻辑，也要明确标记为 fallback 路径
CompletableFuturefuture = CompletableFuture.supplyAsync(() -> { Thread.sleep(5000); return "done"; }).orTimeout(1, TimeUnit.SECONDS); future.exceptionally(ex -> { if (ex instanceof TimeoutException) { log.warn("Fallback triggered: service unavailable", ex); return "fallback-result"; } return null; });
TimeoutException 和 InterruptedException 的关系别搞混
这两个异常经常一起出现，但语义完全不同：InterruptedException 表示当前线程被其他线程中断（Thread.interrupt()），而 TimeoutException 是纯业务层面的“等太久了”。关键区别在于：
本书将PHP开发与MySQL应用相结合，分别对PHP和MySQL做了深入浅出的分析，不仅介绍PHP和MySQL的一般概念，而且对PHP和MySQL的Web应用做了较全面的阐述，并包括几个经典且实用的例子。 本书是第4版，经过了全面的更新、重写和扩展，包括PHP5.3最新改进的特性（例如，更好的错误和异常处理），MySQL的存储过程和存储引擎，Ajax技术与Web2.0以及Web应用需要注意的安全
-
Future.cancel(true)会尝试中断任务线程，此时任务内部若调用Thread.sleep()或Object.wait()等，就会抛InterruptedException，而不是TimeoutException - 你 catch
TimeoutException的地方，通常也得准备处理可能随之而来的InterruptedException（比如在 finally 里清理资源时又 sleep） - 不要把两者都往同一个 fallback 逻辑里塞——超时降级和中断恢复是不同策略
真实场景中容易被忽略的三个点
生产环境里，TimeoutException 最常暴露的不是超时设置不合理，而是配套动作缺失：
- HTTP 客户端（如 OkHttp、RestTemplate）配置了 read timeout，但没配 connect timeout，结果 DNS 卡住几十秒才失败，根本没走到
TimeoutException那一步 - 数据库连接池（如 HikariCP）的
connection-timeout触发的是SQLException，不是TimeoutException，别指望统一 catch - 自定义线程池提交任务后，用
Future.get()等结果，却忘了线程池本身拒绝策略（如AbortPolicy）可能直接抛RejectedExecutionException，跟超时无关
超时从来不是单点配置问题，它是调用链上每一层的协作契约。你看到 TimeoutException 的那一刻，实际已经晚了一步——前面每个环节的 timeout、retry、circuit-breaker 都该有明确约定。
