java线程未捕获异常默认静默吞掉，需通过uncaughtexceptionhandler机制统一处理：设全局默认处理器覆盖新线程；为单线程单独设置优先级更高；线程池需重写afterexecute；虚拟线程继承父处理器或批量配置。
Java 中线程未捕获异常默认会被静默吞掉，既不打印日志，也不中断主线程或通知调用方。要统一处理，核心是利用 UncaughtExceptionHandler 机制，配合线程池特定钩子，确保所有异常“有迹可循”。
设置全局默认异常处理器
这是最基础、覆盖范围最广的一层兜底：
- 在
main()方法开头或应用初始化阶段调用一次即可生效 - 它只影响后续新创建的线程，对已启动的线程无效
- 必须记录完整堆栈（推荐用日志框架的
error("msg", e)），仅打印 message 没有意义 - 示例：
Thread.setDefaultUncaughtExceptionHandler((t, e) -> {
log.error("Global uncaught exception in thread: {}", t.getName(), e);
});
为单个线程单独设置处理器
适用于需要差异化处理的场景，比如某类任务失败后要触发告警或清理资源：
- 必须在
thread.start()之前设置，之后调用无效 - 优先级高于全局处理器：一旦线程自己设置了，就不会走默认逻辑
- 适合把异常处理逻辑封装在线程对象上，和业务 Runnable 解耦
- 示例：
Thread t = new Thread(() -> { throw new RuntimeException("boom"); });
t.setUncaughtExceptionHandler((thread, ex) -> {
alertService.send("Thread " + thread.getName() + " failed");
});
t.start();
线程池任务异常必须额外干预
普通线程池（ThreadPoolExecutor）对异常更“沉默”，仅靠 UncaughtExceptionHandler 不够可靠：
-
execute(Runnable)提交的任务：异常不会触发线程的处理器，而是被 FutureTask 内部吞掉 -
submit(Callable)提交的任务：异常被包装进ExecutionException，但必须显式调用future.get()才能暴露 - 真正稳定的方式是继承
ThreadPoolExecutor，重写afterExecute(Runnable r, Throwable t) -
t != null就表示任务执行中抛了未捕获异常，此时可统一打日志、上报监控、统计失败率 - 注意不要在
afterExecute中做耗时操作（如远程 HTTP 调用），否则会阻塞工作线程
虚拟线程的异常处理要点
Project Loom 的虚拟线程也遵循 UncaughtExceptionHandler 机制，但有两点要注意：
- 启动时自动继承父线程的处理器，所以全局设置对其同样生效
- 也可用
Thread.ofVirtual().uncaughtExceptionHandler(...)为一批虚拟线程统一配置，比逐个设置更简洁 - 虽然虚拟线程轻量，但异常堆栈可能被优化压缩，调试时建议开启
-Djdk.tracePinned=true辅助定位
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
