java线程未捕获异常默认静默吞掉，需显式设置uncaughtexceptionhandler；单个线程处理器须在start()前设置，全局处理器应在main()开头注册；线程池中execute异常可被处理器捕获，submit异常需get()才暴露，最可靠方式是重写afterexecute。
Java 中线程抛出的未捕获异常默认会被静默吞掉，既不打印日志，也不中断主线程或通知调用方——这是线上问题难以排查的常见根源。关键在于：异常不会跨线程传播，必须显式设置捕获机制。
给单个线程设专属处理器
适用于需要为特定任务定制处理逻辑（如重试、告警、资源清理）的场景：
- 必须在 thread.start() 之前 调用
setUncaughtExceptionHandler，启动后再设无效 - 处理器签名是
(Thread t, Throwable e) → void，可直接访问线程名和完整异常对象 - 同一个线程只能有一个处理器，后设的会覆盖前设的
- 优先级高于全局处理器，设了它就不会走默认兜底逻辑
设置全局默认处理器
作为第一道防线，覆盖所有未单独设置处理器的线程：
- 在
main()开头或应用初始化阶段调用一次即可生效 - 只影响后续新建的线程，已启动的线程不受影响
- 务必记录完整堆栈（例如用
e.printStackTrace()或日志框架的error("msg", e)），否则等于没做 - 适合统一日志、监控上报等基础兜底能力
线程池任务异常不能只靠 UncaughtExceptionHandler
ThreadPoolExecutor 对 execute(Runnable) 和 submit(Callable) 的异常处理机制完全不同：
-
execute()提交的任务：异常会触发线程的UncaughtExceptionHandler，但前提是异常真的“逃到线程顶层”——而FutureTask.run()内部把异常吞进setException()，导致处理器收不到 -
submit()提交的Callable：异常被包装进ExecutionException，必须显式调用future.get()才能暴露，否则照样静默 - 最可靠方式是继承
ThreadPoolExecutor，重写afterExecute(Runnable r, Throwable t)——只要t != null，就是任务执行时抛出的真实异常
其他补充手段
根据实际场景搭配使用，提升健壮性：
- 在
Runnable或Callable实现类内部加try-catch，主动捕获并记录，是最直接可控的方式 - 用
ThreadFactory为线程池创建的每个线程统一设置UncaughtExceptionHandler，适合标准化线程行为 - 对可能中断的阻塞操作（如
sleep、wait、join），必须显式处理InterruptedException，它不会被UncaughtExceptionHandler捕获
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
