Java线程出现未捕获异常时会发生什么？会静默失败吗？

核心结论 #

没有自定义UncaughtExceptionHandler的场景下，线程不会完全静默失败，但默认行为极易被忽略，绝大多数业务场景下都会出现「看起来静默失败」的表现。

默认未捕获异常的处理逻辑 #

当线程抛出未被业务代码捕获的异常时，JVM会按优先级匹配处理器：优先找线程自身绑定的UncaughtExceptionHandler，没有就找线程组的处理器，还没有就用JVM全局默认的处理器。
JVM自带的默认处理器行为非常简单：

• 把异常的栈轨迹打印到System.err标准错误流
• 直接终止当前抛出异常的线程，不会影响其他正常存活的线程，也不会直接导致整个进程退出

容易被误认为「静默失败」的核心原因 #

• 大部分线上服务的日志配置只会收集业务日志框架（如Logback、Log4j）的输出，或者仅捕获System.out标准输出流，默认打印到System.err的异常栈不会被落盘存储，排查时根本找不到对应日志
• 抛出异常的线程直接终止后，如果没有做线程存活状态、任务执行状态的监控，业务侧只会感知到对应的异步逻辑没有执行结果，完全找不到根因，看起来就像线程悄无声息就挂了

异步线程/线程池场景的高频踩坑点 #

线程池场景下的异常处理规则和单独线程有差异，也是静默失败的重灾区：

• 用execute()方法提交任务时，抛出的未捕获异常会正常触发UncaughtExceptionHandler的逻辑
• 用submit()方法提交任务时，抛出的异常会被封装到返回的Future对象中，只有主动调用get()方法时才会抛出ExecutionException，这种场景下连默认的System.err打印都不会触发，属于完全的静默失败

排查建议 #

• 先确认业务用到的自定义线程、线程池是否配置了UncaughtExceptionHandler，检查处理器逻辑中是否有异常落日志的实现
• 排查线程池任务的提交方式，确认是否存在submit()提交后没有调用get()、也没有捕获异常的场景
• 临时排查阶段可以给JVM设置全局默认的UncaughtExceptionHandler，统一把所有未捕获异常输出到指定的错误日志中，快速定位问题

内容的提问来源于stack exchange，提问作者HellishHeat