未捕获的线程异常会静默丢失，因Thread默认UncaughtExceptionHandler为空；需显式设置局部或全局处理器，ExecutorService中Runnable异常同样静默，Callable则需Future.get()获取。
未捕获的线程异常会静默丢失
Java 中，如果线程内抛出未捕获的 RuntimeException 或其子类（比如 NullPointerException、ArrayIndexOutOfBoundsException），且没有显式处理，该异常不会传播到主线程，也不会打印堆栈——它就那样消失了。这是最常被忽视的问题：你以为任务执行失败了，但日志里什么都没有。
根本原因在于每个 Thread 对象内部维护一个 UncaughtExceptionHandler，默认实现是空的；JVM 不会帮你打印或上报。
- 现象：使用
new Thread(() -> { throw new RuntimeException("boom"); }).start();后控制台无输出 - 验证方式：在启动前调用
thread.setUncaughtExceptionHandler((t, e) -> System.err.println("Uncaught: " + e));就能看到异常 - 注意：
ExecutorService提交的Runnable也遵循同样规则；而Callable的异常会被包装进ExecutionException，需通过Future.get()显式获取
给线程设置全局或局部异常处理器
有两种主流方式：为单个线程单独设置处理器，或为整个线程组/应用设置默认处理器。后者对线程池尤其有用。
局部设置更可控，推荐用于关键业务线程：
立即学习“Java免费学习笔记（深入）”；
Thread thread = new Thread(() -> {
// 可能抛异常的逻辑
throw new IllegalArgumentException("invalid input");
});
thread.setUncaughtExceptionHandler((t, e) -> {
System.err.println("Thread [" + t.getName() + "] failed: " + e.getMessage());
// 这里可以发告警、记录到 ELK、触发降级等
});
thread.start();
全局设置适用于所有后续创建的线程（不包括已存在的）：
Thread.setDefaultUncaughtExceptionHandler((t, e) -> {
LoggerFactory.getLogger("global-ueh").error("Uncaught in thread {}", t.getName(), e);
});
- 全局处理器只影响「未显式设置过
setUncaughtExceptionHandler」的线程 -
ExecutorService创建的线程通常来自ThreadFactory，若你自定义了工厂，应在newThread方法中主动设置 handler - Spring 的
ThreadPoolTaskExecutor支持配置setThreadFactory，别忘了传入带异常处理逻辑的工厂
ExecutorService 中 Runnable 和 Callable 的异常差异
很多人误以为提交给线程池的任务异常都能统一捕获——其实取决于你用的是 Runnable 还是 Callable。
-
Runnable：异常仍走UncaughtExceptionHandler流程，静默丢失风险同上 -
Callable：异常会被封装进ExecutionException，必须调用Future.get()才能暴露原始异常（e.getCause()） - 常见错误：提交
Callable后忽略Future，导致异常永远不被检查
示例对比：
// Runnable → 异常静默（除非设了 UEH）
executor.submit(() -> { throw new RuntimeException("runnable fail"); });
// Callable → 异常被包裹，必须 get() 才能触发
Future<?> future = executor.submit(() -> {
throw new RuntimeException("callable fail");
});
try {
future.get(); // 此处才真正抛出 ExecutionException
} catch (ExecutionException e) {
Throwable cause = e.getCause(); // ← 真正的 RuntimeException
System.err.println("Real cause: " + cause);
}
异步链路中异常传递容易断掉
当使用 CompletableFuture 或类似异步组合时，异常处理逻辑容易写错位置。比如 thenApply 抛异常，不会进入 exceptionally，除非你显式返回一个已完成的异常 future。
-
thenApply/thenAccept内部抛异常 → 会终止链路，下游thenCompose不执行，但异常不会自动落到exceptionally - 正确做法：在可能出错的方法里 try-catch，或改用
handle统一处理结果和异常 - 特别注意
supplyAsync的 supplier 若抛异常，会直接变成 completed exceptionally 的 future，此时exceptionally才生效
简例：
CompletableFuture.supplyAsync(() -> {
throw new RuntimeException("supply fails");
}).exceptionally(throwable -> {
System.err.println("Caught: " + throwable.getMessage()); // ✅ 这里能捕获
return null;
});
CompletableFuture.supplyAsync(() -> "ok")
.thenApply(s -> {
throw new RuntimeException("thenApply fails"); // ❌ exceptionally 不会触发
})
.exceptionally(e -> {
System.err.println("This won't run");
return null;
});
线程异常处理最麻烦的地方不在“怎么写”，而在“谁来负责检查”——尤其是异步调用层层嵌套后，异常可能卡在某个 Future 里，或被 CompletableFuture 的中间操作吞掉。务必在关键路径上做显式 get() 或 join()，并配合日志埋点确认异常是否真被处理了。 
