Java多线程异常默认不传播至主线程，子线程静默终止仅打印堆栈；需通过UncaughtExceptionHandler、afterExecute或Future.get()显式捕获，否则异常被吞导致排查困难。
Java 多线程环境下的异常处理不能套用单线程思维——子线程抛出的未捕获异常默认不会传给主线程，也不会中断程序运行，而是静默终止，只在控制台打印堆栈。这种“无声崩溃”正是排查困难的根源。
线程异常不传播是 JVM 的默认设计
每个线程有独立调用栈，异常无法跨栈自动传递。即使主线程用 try-catch 包裹 thread.start()，也捕获不到子线程内部的 RuntimeException。JVM 在线程因未捕获异常退出时，会调用其 UncaughtExceptionHandler，但默认实现只是 System.err.println()，不报警、不记录、不通知。
三种典型场景的异常行为要分清
- 直接 new Thread().start()：异常走 UncaughtExceptionHandler 流程；没设置处理器就只打印堆栈，线程结束，主线程无感知
- ExecutorService.submit()：异常被封装进 Future，必须显式调用 future.get() 才触发 ExecutionException；不调用 get() 就永远“看不见”
- ExecutorService.execute()：异常不经过 Future，直接触发线程的 UncaughtExceptionHandler，和裸线程行为一致
可靠捕获必须主动设置处理点
靠默认机制等于放弃监控。实际项目中应至少覆盖以下两层：
- 全局兜底：
Thread.setDefaultUncaughtExceptionHandler捕获所有未显式设置处理器的线程异常，适合统一日志、告警 - 线程池定制：
ThreadPoolExecutor.afterExecute是最稳的钩子——无论 submit 还是 execute 提交的任务，只要抛了异常（包括 get() 抛的 ExecutionException），都会进入这里，可做统一记录、重试或熔断
别忽略受检异常和 InterruptedException
Runnable.run() 不允许 throws 声明受检异常，所以业务中若调用可能抛 IOException/SQLException 的方法，必须在 run 内部 try-catch；而 InterruptedException 是线程协作的关键信号，捕获后通常应恢复中断状态（Thread.currentThread().interrupt()），否则上层中断逻辑会失效。
立即学习“Java免费学习笔记（深入）”；
