Thread.setDefaultUncaughtExceptionHandler未生效的根本原因是设置时机过晚或仅对后续线程生效，且主线程异常不走该处理器；需在main开头设置，并单独为主线程、线程池、框架线程（如@Async）、UI线程分别配置handler。
Thread.setDefaultUncaughtExceptionHandler 为什么没生效
根本原因通常是：设置时机太晚，或只对后续创建的线程生效，而异常已发生在主线程或提前启动的线程里。
- 必须在
Thread启动前调用Thread.setDefaultUncaughtExceptionHandler，比如放在main方法最开头 - 它只影响「未显式设置
setUncaughtExceptionHandler」且「未重写run中 try-catch」的线程 - 主线程（
main线程）的异常默认由 JVM 处理，不会走这个全局 handler；若要捕获，需单独对Thread.currentThread()设置 - 第三方库（如 Spring、Netty）可能自行设置了线程异常处理器，覆盖了你的全局设置
如何真正捕获所有线程的未处理异常
靠单一 setDefaultUncaughtExceptionHandler 不够，得组合使用：
- 对主线程单独设：在
main开头执行Thread.currentThread().setUncaughtExceptionHandler(...) - 对线程池统一管理：用
ThreadFactory包装，确保每个新线程都带 handler，例如Executors.defaultThreadFactory()不行，得自己实现 - Spring 环境下，还要注意
@Async创建的线程——它用的是ThreadPoolTaskExecutor，需重写其threadFactory属性 - Android 或 JavaFX 等特殊环境，UI 线程有独立异常机制（如
Looper.getMainLooper().getThread().setUncaughtExceptionHandler(...)），不能漏掉
UncaughtExceptionHandler 的常见误用场景
很多人以为设了就能“兜底一切”，结果线上照样崩溃无声——问题出在 handler 自身逻辑上：
- handler 里抛出新异常会被 JVM 直接忽略，不会打印日志也不会终止进程，导致“看似捕获实则丢弃”
- 做耗时操作（如网络上报、文件写入）可能阻塞线程退出，甚至引发死锁；应尽量只做轻量记录（
System.err.println或异步日志器） - 没保留原始堆栈：错误地只打印
e.getMessage()，丢失关键上下文；务必用e.printStackTrace(System.err)或日志框架的logger.error("", e) - 多线程并发调用 handler 时，若内部用了非线程安全的资源（如
SimpleDateFormat），会静默失败
一个稳妥的全局异常捕获模板
不是复制粘贴就能用，重点是理解每行的约束条件：
立即学习“Java免费学习笔记（深入）”；
public class GlobalExceptionHandler implements Thread.UncaughtExceptionHandler {
@Override
public void uncaughtException(Thread t, Throwable e) {
// 避免递归：防止 logger 内部再抛异常导致无限调用
if (e == null) return;
String threadName = t.getName();
String msg = String.format("[%s] Uncaught exception: %s", threadName, e);
System.err.println(msg);
e.printStackTrace(System.err); // 必须显式打印，否则看不到堆栈
// 日志上报建议走异步队列，不在此处阻塞
}
}
// main 方法中：
public static void main(String[] args) {
Thread.setDefaultUncaughtExceptionHandler(new GlobalExceptionHandler());
Thread.currentThread().setUncaughtExceptionHandler(new GlobalExceptionHandler());
// 启动你的应用...
}
复杂点在于：不同线程来源（手动 new、线程池、框架回调）需要各自适配，没有一劳永逸的 hook 点。别指望设一次就万事大吉。
