TimeoutException 并非线程池直接抛出，而是调用 Future.get(long, TimeUnit) 等带超时方法时，因任务未完成而由调用方主动抛出的受检异常。
TimeoutException 不是线程池直接抛出的异常
Java 的 TimeoutException 是一个受检异常（java.util.concurrent.TimeoutException），它本身**不会由线程池自动抛出**，而是由调用方在等待结果超时时主动 throw —— 典型场景是 Future.get(long, TimeUnit) 或 CompletableFuture.orTimeout()。线程池（如 ThreadPoolExecutor）只负责执行任务，不干预任务内部是否超时。
常见误解是“线程池抛了 TimeoutException”，实际是：你调用了带超时的获取方法，而任务没在规定时间内完成，于是 get() 主动抛出 TimeoutException，和线程池本身的运行状态无关。
-
submit(Runnable)返回的Future调用get(1, TimeUnit.SECONDS)→ 任务未结束则抛TimeoutException -
invokeAll(Collection extends Callable<t>>, long, TimeUnit)</t>中任意一个任务超时 → 返回的List<future>></future>中对应项为已取消的Future，但方法本身不抛TimeoutException；需手动检查isCancelled() -
CompletableFuture.supplyAsync(...).orTimeout(1, TimeUnit.SECONDS)→ 超时后返回一个以TimeoutException完成的CompletableFuture，不是直接 throw
线程池中任务抛出的异常默认会被吞掉
如果你提交的是 Runnable 或 Callable，且任务内部抛了未捕获异常（比如 NullPointerException），而你又没显式处理 Future.get()，那这个异常就“消失”了——它被封装进 Future，但无人提取，JVM 不会打印，也不会中断线程池。
这和 TimeoutException 的行为完全不同：TimeoutException 是你主动等出来的；而任务内异常是被动发生的，必须主动拉取才能看到。
立即学习“Java免费学习笔记（深入）”；
- 对
Runnable：异常会出现在Future.get()时包装为ExecutionException，原始异常是其getCause() - 对
Callable：同上，但更常见；若用CompletableFuture，可用exceptionally()或handle()捕获 - 线程池的
afterExecute(Runnable, Throwable)钩子可用于兜底记录未捕获异常，但仅对Runnable有效；Callable的异常不会传入该钩子
正确组合超时 + 异常处理的典型写法
真正健壮的异步调用，需要同时覆盖三种情况：任务成功、任务失败、任务超时。不能只 catch TimeoutException 就完事。
try {
String result = future.get(3, TimeUnit.SECONDS);
System.out.println("Success: " + result);
} catch (TimeoutException e) {
System.err.println("Task timed out");
future.cancel(true); // 中断正在运行的任务（仅当任务响应中断）
} catch (ExecutionException e) {
Throwable cause = e.getCause();
System.err.println("Task failed: " + cause.getClass().getSimpleName());
// 处理具体业务异常，如 IOException、CustomValidationException 等
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
System.err.println("Waiting thread was interrupted");
}
注意：future.cancel(true) 是否生效，取决于任务代码是否检查 Thread.interrupted() 或响应中断（比如在循环中调用 Thread.sleep()）。纯计算型任务若不主动响应，中断无效。
使用 CompletableFuture 时的 timeout 和异常陷阱
CompletableFuture 提供了更函数式的超时与异常处理，但容易忽略链式调用中异常传播的断裂点。
-
orTimeout()后若不接exceptionally()，超时会变成CompletionException并中断后续thenApply链 -
completeOnTimeout()是“超时就用默认值完成”，不抛异常，适合降级场景；而orTimeout()是“超时就用TimeoutException完成”，需显式处理 - 多个异步任务用
allOf()组合时，任一任务失败或超时都会导致整个CompletableFuture<void></void>以异常完成，但无法直接知道是哪个子任务出问题 —— 需用whenComplete()或分别监听每个 future
超时判定基于任务开始时间，不是提交时间；如果线程池满、任务排队久，orTimeout(1, SECONDS) 实际可能在提交后 2 秒才开始计时，这点容易被忽略。
