默认情况下子线程崩溃主线程无法感知，因未捕获异常仅打印堆栈后静默退出；正确做法是在thread构造时或通过自定义threadfactory统一设置uncaughtexceptionhandler，且需确保handler轻量、不抛异常。
子线程崩溃了，主线程完全不知道？
默认情况下，Thread 抛出未捕获异常时，JVM 会调用该线程的 UncaughtExceptionHandler —— 但如果你没显式设置，它就走默认逻辑：打印堆栈到 System.err，然后静默退出。你不会收到通知，监控收不到告警，日志里可能只有一行被截断的错误，排查时根本找不到源头。
真正的问题不是“怎么设 handler”，而是“在哪设、对谁生效、会不会被覆盖”。
- 新线程默认继承父线程的 handler，但仅限于
Thread构造时；后续调用setUncaughtExceptionHandler()不会影响已存在的子线程 -
ExecutorService创建的线程（比如Executors.newCachedThreadPool()）通常用的是ThreadFactory，handler 必须在 factory 里设，而不是给线程池对象本身设 - Spring 的
@Async或TaskExecutor也绕不开ThreadFactory，直接在 bean 定义里配 handler 是无效的
Thread.setUncaughtExceptionHandler() 为什么经常失效？
这个方法只对当前 Thread 实例生效，且必须在 start() 之前调用。一旦线程已启动，再调用就毫无作用 —— JVM 不允许运行中修改 handler。
常见误用：
- 在线程
run()方法里才去Thread.currentThread().setUncaughtExceptionHandler(...)→ 白忙活 - 给线程池对象（如
ThreadPoolExecutor）调用setUncaughtExceptionHandler()→ 该方法根本不存在，编译都过不去 - 只在主线程设 handler，以为能兜住所有子线程 → 不行，除非子线程显式继承或 factory 统一配置
正确姿势是：在创建线程前，通过构造函数或 ThreadFactory 注入 handler。
ExecutorService 场景下怎么统一捕获异常？
核心是自定义 ThreadFactory，把 handler 绑定到每个新建线程上。别碰 execute(Runnable)，它不传播异常；优先用 submit(Callable) + Future.get() 主动取异常，但那是业务层兜底，不是未捕获异常的兜底。
示例关键代码：
ThreadFactory factory = r -> {
Thread t = new Thread(r);
t.setUncaughtExceptionHandler((thread, ex) -> {
log.error("Uncaught exception in thread {}", thread.getName(), ex);
// 这里可以发告警、上报 Sentry、触发降级等
});
return t;
};
ExecutorService es = new ThreadPoolExecutor(1, 1, 0, TimeUnit.SECONDS,
new LinkedBlockingQueue<>(), factory);
- 注意：Lambda 中的
log必须是线程安全的（比如 SLF4J 的Logger实例） - 如果用 Lombok 的
@Slf4j，确保它在工厂外部定义，否则每次新建线程都会尝试初始化 logger，可能引发类加载问题 -
Executors.newSingleThreadExecutor()等工具方法返回的线程池，内部用的是私有 factory，无法注入 handler，必须手写ThreadPoolExecutor
UncaughtExceptionHandler 和 try-catch 的关系
它只兜底「未被任何 catch 捕获」的异常。一旦你在 run() 里写了 try { ... } catch (Exception e) { ... }，哪怕 catch 块是空的，handler 就永远不会触发。
所以它不是替代 try-catch 的方案，而是最后一道防线：
- 第三方库内部抛异常，你没源码、没地方加 catch
- lambda 表达式或匿名 Runnable 中漏了异常处理
- 异步回调链路太深，某一层忘了 throw 或 rethrow
另外，InterruptedException 和 VirtualMachineError（如 OutOfMemoryError）也会进 handler，但前者常被忽略，后者往往意味着进程已不稳定 —— handler 里别做重试或复杂恢复，记日志 + 快速退出更稳妥。
最常被忽略的一点：handler 回调是在异常线程自己的栈上执行的，如果 handler 里又抛异常，JVM 会再次调用 handler —— 可能导致无限递归或线程卡死。务必保证 handler 体足够轻量且绝不抛异常。
