Java子线程异常默认不传播至主线程，需显式设置UncaughtExceptionHandler；线程池中Runnable异常被静默吞掉，Callable异常需调用future.get()才暴露；最稳妥方案是重写afterExecute()主动捕获并上报。
子线程抛异常，主线程完全不知道？
Java 默认不会把子线程的未捕获异常传播回主线程，Thread.run() 里崩了，控制台可能只打一行 Exception in thread "Thread-0" java.lang.NullPointerException，然后静默结束——主线程照常运行，监控收不到告警，日志里也难追溯。
根本原因是：每个线程有独立的异常分发机制，Thread 的默认异常处理器只是往 System.err 打印，不中断、不上报、不通知。
- 必须显式设置
Thread.setUncaughtExceptionHandler()，否则等于“放弃治疗” - 匿名内部类或 lambda 启动的线程，容易漏掉这步（因为没显式 new Thread）
- 使用
Executors.newFixedThreadPool()这类工厂方法时，底层线程复用，异常处理器需在ThreadFactory中统一指定，不能靠启动时临时设
线程池中异常被吞掉的三种典型场景
线程池不是“自动兜底”的安全网，它对异常更克制：任务是 Runnable 时，异常直接被 ThreadPoolExecutor.afterExecute() 吞掉；是 Callable 时，异常包装成 ExecutionException 塞进 Future，但你不调 get() 就永远看不到。
-
submit(Runnable)→ 异常仅打印，不阻塞、不抛出、不触发拒绝策略 -
execute(Runnable)→ 异常同样静默，且不会触发afterExecute()的默认日志（除非重写） -
submit(Callable)→ 必须显式调用future.get()才能暴露原始异常，否则ExecutionException被压在Future里
示例：executor.submit(() -> { throw new RuntimeException("boom"); }); —— 这行代码执行完就完了，没人知道 boom 了。
立即学习“Java免费学习笔记（深入）”；
怎么让线程池真正“看见”异常？
核心思路就一条：别依赖默认行为，主动接管异常生命周期。最稳妥的是重写 ThreadPoolExecutor.afterExecute()，它会在每个任务执行后被回调，无论成功还是抛异常。
- 重写时检查
Throwable t参数是否非 null，非 null 即表示任务执行中抛了未捕获异常 - 不要只打日志，建议同步上报监控（如调用
Metrics.counter("task.error").increment()） - 如果业务要求强一致性，可在
afterExecute()里触发熔断或告警，但避免阻塞线程池工作线程 - 注意：该方法在任务线程中执行，不是专门的“异常线程”，所以不要做耗时操作（如发 HTTP 请求）
简短示意：
protected void afterExecute(Runnable r, Throwable t) {
if (t != null) {
log.error("Task failed", t);
alertService.send("thread-pool-task-failed", t.getMessage());
}
}
为什么 try-catch 包裹 Runnable 不够用？
包一层 try-catch 看似简单，但它只解决“当前层”异常，对异步嵌套、回调链、CompletableFuture 链式调用中的异常无效。比如你在 run() 里 catch 了，但里面又起了新线程、发了异步 HTTP、或者用了 CompletableFuture.supplyAsync()，那些新分支的异常依然会丢失。
- catch 只覆盖当前栈帧，无法跨线程传递上下文
- 现代 Java 异步模型（如
CompletableFuture、VirtualThread）有自己的异常处理路径，不能靠外层 try-catch 一锅端 - 线程池配置了
ThreadFactory时，若没在 factory 中设置UncaughtExceptionHandler，新创建的线程仍走默认静默逻辑
真正要管住异常，得在源头（线程创建）、中间（任务调度）、终点（结果获取）三处设防，而不是只盯着一个 run() 方法。
复杂点在于：不同线程模型（平台线程 vs 虚拟线程）、不同异步抽象（Future vs CompletionStage vs Reactive）的异常传播契约完全不同，同一套处理逻辑很难通用。最容易被忽略的是虚拟线程——它默认共享调用方的异常处理器，但一旦你手动 set，就可能和平台线程行为不一致。
