thread.setdefaultuncaughtexceptionhandler仅捕获未被try-catch处理的非主线程异常；主线程异常jvm直接退出，该handler无效；线程池需自定义threadfactory显式设置handler，否则不生效。
Thread.setDefaultUncaughtExceptionHandler 能捕获哪些异常
它只管「未被 try-catch 拦下的、且发生在非主线程里的异常」。主线程（main thread）抛出的未捕获异常，JVM 会直接打印堆栈并退出，setDefaultUncaughtExceptionHandler 对它完全无效；而子线程里只要没显式处理，就会落到这个 handler 上。
常见错误现象：Exception in thread "pool-1-thread-1" java.lang.NullPointerException 这类日志突然消失，或者你加了 handler 却发现某些崩溃没被拦截——八成是主线程崩了，或者线程池用的是 ThreadFactory 但没把 handler 传进去。
- 必须在子线程启动前设置，否则对已存在的线程无效
- 如果线程自己调用了
setUncaughtExceptionHandler，会覆盖全局设置 - ForkJoinPool、Executors 创建的线程池默认不继承全局 handler，得靠自定义
ThreadFactory
如何让线程池里的线程也走全局 handler
Executors 的默认线程工厂不会把 setDefaultUncaughtExceptionHandler 的逻辑带进去，所以你看到 ThreadPoolExecutor 启动的线程崩溃后静默失败，不是 handler 失效，而是压根没被设上。
实操建议：写个简单的 ThreadFactory，在 newThread 里手动把当前的全局 handler 绑上去：
立即学习“Java免费学习笔记（深入）”；
ThreadFactory factory = r -> {
Thread t = new Thread(r);
t.setUncaughtExceptionHandler(Thread.getDefaultUncaughtExceptionHandler());
return t;
};
然后传给 ThreadPoolExecutor 或 Executors.newFixedThreadPool(n, factory)。别依赖 Executors.defaultThreadFactory()，它不干这事。
- 不要在
run()里 try-catch 后吞掉异常再忽略——这会让 handler 彻底失效 - Spring 的
@Async默认用的是 SimpleAsyncTaskExecutor，每次新建线程，也得配自定义TaskExecutor才能生效 - Android 里
Looper.getMainLooper()主线程有自己的一套异常机制，和这个无关
handler 里该做什么，不该做什么
它本质是个兜底出口，适合做日志记录、上报、状态标记；不适合做恢复操作，因为线程已经处于不可控状态，interrupt()、join() 都可能卡死或无效。
典型误用：System.exit(1) 写在 handler 里——这会让整个 JVM 退出，连正在跑的定时任务、网络连接、关闭钩子都来不及执行。
- 优先用异步方式记录日志，避免阻塞线程销毁流程
- 别在 handler 里启动新线程或调用远程接口，超时或失败会直接丢失上下文
- 如果要触发告警，建议写入本地文件或内存队列，由独立线程后续消费
- 注意 handler 是同步执行的，耗时越长，线程销毁越慢，可能影响线程池复用
为什么有时候 handler 看起来“没生效”
最常被忽略的是：JVM 在 shutdown 过程中，新创建的线程即使抛异常，也不会触发 UncaughtExceptionHandler。比如你在 Runtime.addShutdownHook 里起线程，然后它崩了——那异常就真的没人管了。
另一个隐形坑：ExecutorService.shutdownNow() 会中断所有线程，此时抛出的 InterruptedException 不算“未捕获异常”，它会被线程自身检查并吞掉，根本到不了 handler。
- 测试 handler 是否生效，一定要在普通子线程里主动 throw 新异常，而不是依赖中断或 JVM 关闭流程
- 某些监控 SDK（如 Sentry、Arthas）会劫持异常分发链，可能覆盖或干扰你的 handler
- Java 9+ 的
Thread.ofVirtual()创建的虚拟线程，不支持UncaughtExceptionHandler
真正难搞的从来不是设 handler 这一行代码，而是确保它在整个应用生命周期里始终被正确的线程看到，并且不被其他机制绕过或覆盖。
