Java线程异常如何处理？并发异常解析

未捕获的线程异常会静默丢失，因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() 显式获取

给线程设置全局或局部异常处理器

有两种主流方式：为单个线程单独设置处理器，或为整个线程组/应用设置默认处理器。后者对线程池尤其有用。

局部设置更可控，推荐用于关键业务线程：

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()，并配合日志埋点确认异常是否真被处理了。