先问一句：你在线上有没有碰到过这种情况——某个后台任务线程明明在日志里打印了一长串异常堆栈，但主流程继续往下走，最终数据对不上、状态没更新，排查的时候才发现异常其实发生在子线程？这几乎是做 Java 并发开发必然会撞上的坑。子线程的异常默认不会冒泡到主线程，它只会自己打印一下然后默默退出。你写在主线程外面的 try-catch 根本接不住它。这个点既是 Java 面试的高频题，又是微服务、批处理、定时任务这些场景里最常见的故障源。这篇文章就围绕"主线程捕获子线程异常"这个核心诉求，梳理三种工程上真正可用的方案：UncaughtExceptionHandler、ExecutorService + Future.get()、CompletableFuture 回调处理。我会把每个方案的原理、完整代码、适用边界、容易踩的坑全部说清楚，适合正在做多线程开发、或者为了面试突击 Java 并发的同学直接参考。

1. 先搞清楚：子线程异常为什么传不回主线程

1.1 线程异常传递模型与主线程的隔离

Java 里每个线程的执行入口是Thread.run()方法，你传入的Runnable或者Callable最终都会被它的内部调用逻辑包住。当子线程体内的代码抛出运行时异常时，异常会沿着当前线程的方法调用栈向上抛，但抛出链路的终点就是该线程的run()方法，而不是创建这个线程的main()或者其他主线程。也就是说，主线程里写try-catch是徒劳的，两个线程的异常栈根本不在同一个调用链上，异常也不会自动跨线程传递。

我见过不少新人对这一点产生误解，以为只要在start()外面加上 try-catch 就能兜住子线程异常。真正的机制是：当某个线程因未捕获异常而终止时，Thread类内部会调用一个叫dispatchUncaughtException(Throwable)的私有关键方法，依次查找该线程自己的uncaughtExceptionHandler、线程组设置，最后回落到默认的Thread.getDefaultUncaughtExceptionHandler()。如果一直找不到自定义处理器，默认行为就是把堆栈打印到System.err。这就解释了为什么线上日志里子线程异常看起来"打印了但没人知道"——它确实打印了，但你没有任何代码去接收和处理。

这里有一个理解误区要澄清："主线程捕获子线程异常"本质上是主线程主动去感知、获取或接收子线程抛出的异常，不是主线程通过 try-catch 包裹子线程代码来拦截。想实现这个目标，必须借助线程自身的异常出口机制，或者通过"共享"的异步结果载体把异常传递回主线程。搞明白这一点，三个方案的原理就顺了。

1.2 问题场景：哪些情况最容易踩雷

最常见的踩雷场景有两类。第一类是裸写new Thread() { ... }.start()，子线程里跑一段业务逻辑，比如刷新缓存、推送消息、插入日志。如果这段逻辑抛出NullPointerException或者IllegalStateException，主线程根本不知道任务失败，继续执行后续的数据统计或者发号操作，最终导致结果错误。第二类是用线程池提交任务时误用execute()，任务抛出的异常会在线程池内部被吞掉，你连打印都看不到。有些线程池实现如ThreadPoolExecutor，会对 Worker 线程的异常进行钩子回调，但默认afterExecute不做任何处理，异常直接消失，排查起来极其痛苦。

还有一类场景与"中断"相关：子线程内外层代码只捕获了异常但没恢复中断标志，导致任务卡死或者后续循环无法退出。这些都会放大异常传递问题的破坏力。接下来要讲的三套方案，第一套负责"感知到异常"，第二套负责"拿到异常并等待结果"，第三套负责"异常发生后异步转入处理逻辑"，三者解决的问题有重叠，但侧重点完全不同。

2. 方案一：UncaughtExceptionHandler 兜底感知

2.1 基础实现：给线程绑定异常出口

UncaughtExceptionHandler是 JDK 内建的单方法接口，核心就一个方法：void uncaughtException(Thread t, Throwable e)。当子线程抛出未捕获异常时，JVM 会把它交给你实现的处理器。这个方法在Thread上有个setUncaughtExceptionHandler可供设置。下面是一个最直白的实现示例：

import java.util.concurrent.CountDownLatch; public class UncaughtExceptionDemo { public static void main(String[] args) throws InterruptedException { CountDownLatch latch = new CountDownLatch(1); Thread worker = new Thread(() -> { System.out.println("子线程开始执行任务"); // 模拟真实任务里抛出的一个运行时异常 throw new IllegalStateException("业务处理发生不可恢复异常"); }, "business-worker-01"); worker.setUncaughtExceptionHandler((t, e) -> { System.out.println("主线程感知到异常，线程名: " + t.getName() + ", 异常类型: " + e.getClass().getSimpleName() + ", 异常信息: " + e.getMessage()); // 通知主线程继续往下走，或者标记整个任务失败 latch.countDown(); }); worker.start(); // 主线程在等待的同时还可以做自己的事情 System.out.println("主线程继续执行其他逻辑..."); // 阻塞在这里等待子线程异常处理完成 latch.await(); System.out.println("主线程收到异常通知，开始走补偿逻辑"); } }

关键点在于CountDownLatch。如果主线程不等待，那么异常通知处理可能还没来得及执行，主线程就已经跑完退出了。生产环境里主线程通常是常驻的，比如一个定时任务调度器，此时确实可以不做同步等待，但为了把"感知异常"这件事说完整，我建议你在测试代码里用CountDownLatch或者CyclicBarrier把主线程和异常回调串起来。这样程序的行为才可控、可断言。

这个方案有个很务实的使用场景：线上不想因为某个后台任务抛出异常就让整个 JVM 进程挂掉，又要保证异常有专人记录。替代方式是捕获异常后把它写入内存队列，让专门的监控消费者去做告警和降级，这时候UncaughtExceptionHandler就是最合适的"第一道哨兵"。

2.2 在线程池场景下的统一配置方式

给每一个裸Thread手动设置 handler，在真实项目里并不现实，因为更普遍的是使用线程池。这时候可以从源头定制ThreadFactory。线程池在创建新线程时会调用ThreadFactory.newThread(Runnable r)，我们可以在这里把UncaughtExceptionHandler绑定到每一个被创建出来的线程上：

import java.util.concurrent.*; import java.util.concurrent.atomic.AtomicInteger; public class UncaughtExceptionThreadPoolDemo { public static void main(String[] args) { AtomicInteger seq = new AtomicInteger(1); ThreadFactory factory = r -> { Thread thread = new Thread(r, "batch-worker-" + seq.getAndIncrement()); thread.setUncaughtExceptionHandler((t, e) -> { System.err.println("统一异常出口: 线程 " + t.getName() + " 发生异常, cause=" + e.getCause() + ", message=" + e.getMessage()); // 实际项目中在这里接日志、监控、告警 }); return thread; }; ExecutorService pool = Executors.newFixedThreadPool(4, factory); for (int i = 0; i < 8; i++) { final int index = i; pool.execute(() -> { if (index % 3 == 0) { throw new IllegalArgumentException("参数不合法, index=" + index); } System.out.println("任务执行成功: " + index); }); } pool.shutdown(); } }

相比给每个Thread单独设置，这里的好处显而易见：线程池创建的线程生命周期完全由池统一管理，线程被回收后再次创建时依然会带上 handler，你只用写一次配置，之后所有任务都能覆盖到。再加上线程名可以带编号，日志里定位到具体是哪个池子里哪个线程出的问题，排查效率会高很多。

除了ThreadFactory，还可以继承ThreadGroup并重写uncaughtException。ThreadGroup本质上是线程异常处理的第二层兜底。当我们没有为某个线程显式设置 handler 时，异常会流向线程所属的ThreadGroup.uncaughtException()。它默认实现是先交给父级线程组，最终落到默认 handler。继承ThreadGroup并重写这个方法，同样可以在线程池里生效，但比ThreadFactory稍微隐晦一些。我个人更推荐ThreadFactory方式，因为它更直观、不依赖全局线程组继承关系，且代码审查的人一眼就明白你在干什么。

2.3 这个方案的边界和注意点

第一个注意点：UncaughtExceptionHandler只能感知到"未捕获异常"，也就是那些没有被try-catch拦住的异常。如果子线程里的业务代码已经用 catch 吞掉了异常并且没有再 throw 出来，handler 是永远没机会执行的。所以这套方案更适合做"顶层兜底"，而不是替代业务代码里必要的异常判断。

第二个注意点：使用execute()提交任务给线程池时，ThreadFactory上设置的UncaughtExceptionHandler并不一定会被调用，这取决于线程池的afterExecute钩子实现。实际上，ThreadPoolExecutor在执行任务时如果任务抛了异常，会先把异常吞进 Worker 内部处理，并不一定会走线程的dispatchUncaughtException逻辑。你依然需要在afterExecute里拿到Throwable做额外处理，这个坑下面第 6 章我会专门展开讲。

第三个注意点：handler 本身要尽量简单，不要在里头做耗时操作，比如调用远程告警接口或者写大批量日志。因为uncaughtException是运行在线程即将死亡的临界点，如果在这里阻塞，线程资源回收会被延迟，并发高峰期甚至会产生大量僵尸线程等待。比较稳妥的做法是把异常信息放进一个有界队列，由专门的清理线程异步消费。

3. 方案二：ExecutorService + Future.get() 拿到异常并获取返回值

3.1 用 Callable 替代 Runnable，异常被包装为 ExecutionException

如果说UncaughtExceptionHandler解决的只是"感知异常"，那么Future.get()方案解决的是"拿到异常本身"。它要求你不再使用Runnable，而是改用Callable<T>提交任务。Callable的call()方法可以抛出受检异常，更重要的是，ExecutorService.submit(Callable)会返回一个Future<T>，当子线程内部抛出任何异常时，异常会被保存在Future内部，主线程调用future.get()时会把原始异常包装成ExecutionException再次抛出。

import java.util.ArrayList; import java.util.List; import java.util.concurrent.*; public class FutureCatchesExceptionDemo { public static void main(String[] args) { ExecutorService pool = Executors.newFixedThreadPool(3); List<Future<Integer>> futures = new ArrayList<>(); // 模拟提交一批计算任务，其中一部分会失败 for (int i = 0; i < 6; i++) { final int taskId = i; Future<Integer> future = pool.submit(() -> { if (taskId % 2 == 0) { throw new IllegalArgumentException("任务 " + taskId + " 的参数非法"); } return taskId * 10; }); futures.add(future); } // 所有任务提交完成后，统一在主线程获取结果 for (Future<Integer> future : futures) { try { Integer result = future.get(3, TimeUnit.SECONDS); System.out.println("任务成功, 结果: " + result); } catch (ExecutionException e) { // 关键：真正的异常藏在 cause 里 System.out.println("捕获到子线程异常, 原始异常: " + e.getCause().getClass().getName() + ", 信息: " + e.getCause().getMessage()); } catch (TimeoutException e) { System.out.println("任务执行超时"); } catch (InterruptedException e) { Thread.currentThread().interrupt(); System.out.println("主线程被中断"); } } pool.shutdown(); } }

使用这个方案时，主线程能够精确知道哪个任务挂了、挂的原因是什么、其它任务有没有正常返回结果。这正是工程上做"并行任务聚合"最需要的能力。例如一次请求需要并发调用三个外部接口，某一个接口超时或者返回异常，主流程可以根据返回结果决定整体是降级还是熔断。

有一点容易被忽略：ExecutionException包装的原始异常要通过getCause()获取，不要去getMessage()上死磕。ExecutionException自己的 message 只是固定文案，真正有价值的业务错误信息全部在cause链上。这一点面试官很喜欢考察。

3.2 提交全部任务后统一 get，避免串行化

很多初学者会把"提交一个任务 -> 立刻 get()"串起来写，比如循环体内部先submit()再get()。这样写虽然能捕获到异常，但已经变成了完全串行执行——get()会阻塞当前线程，直到前一个任务运行完，下一个任务才开始提交执行。如果线程池里只有两个线程，那整个执行时间会被无限拉长，并发度约等于零。

正确姿势是先收集 futures，再统一调用 get()。第一轮循环只做submit，把每一个Future放进集合；第二轮循环才逐个get。这样任务在提交那一刻就已经在线程池里并发跑了，主线程是在等待"最早完成"的结果时才会被阻塞。它的副作用是，如果先get的任务执行时间很长，那么即使其它任务已经失败，我们也要等很久才能发现。所以生产代码里应该给get()设置超时时间，避免主线程无限期等一个慢任务。

设置了超时之后，TimeoutException也要当做一种异常处理，因为任务可能还在后台继续运行，但主线程不能无限等待。此时可以向上层返回"部分失败"，或者把任务标记为超时，彻底关掉这个Future的后续依赖。

3.3 阻塞主线程的代价与中断策略

Future.get()本身是阻塞操作，这是它的优点也是缺点。优点在于确定性高：异常拿得到、结果拿得到。缺点在于主线程可能被慢任务拖住。实际业务里如果主线程是 Web 请求线程，那阻塞太久会直接占满 Tomcat 线程，接口 RT 飙升。

一个常见的弥补姿势是加上超时参数，并配合ExecutorService.shutdown()后的优雅关闭。另外要特别注意InterruptedException，线程在get()期间响应中断时会抛出这个异常。此时应该立刻恢复中断标志位，而不是吞掉异常：调用Thread.currentThread().interrupt()把中断状态还回去，这样上层调用者才能感知到"当前线程已被请求取消"。很多老代码在 catch 块里直接 log 一下就结束，导致线程已经处于中断状态却没人知道，后续再进行线程池任务提交时可能引发不可预知的后果。

还有一个小技巧：如果你不需要返回值，只是为了捕获异常，仍然可以submit(() -> { 逻辑; return null; })，拿到Future<Void>后调用get()。这比execute()方案多了一层异常感知能力，代价只是创建了一个未来对象，几乎可以忽略。

4. 方案三：CompletableFuture 异步回调，让异常处理不再阻塞主线程

4.1 supplyAsync + exceptionally / handle 的基本用法

CompletableFuture是Future的增强版，它把"等待结果"从"主线程阻塞等在调用点"变为"结果就绪后触发回调"。这种反转非常适合异步链式调用的场景，也让异常处理有了更舒服的书写方式。下面是一个典型示例：

import java.util.concurrent.*; public class CompletableFutureExceptionDemo { public static void main(String[] args) throws Exception { ExecutorService pool = Executors.newFixedThreadPool(2); CompletableFuture<Integer> future = CompletableFuture.supplyAsync(() -> { // 模拟异步任务 double random = Math.random(); if (random > 0.3) { throw new RuntimeException("远程接口调用失败"); } return (int) (random * 100); }, pool); future .exceptionally(ex -> { System.out.println("子线程异常回调触发, cause=" + ex.getCause().getMessage()); // 返回降级默认值 return -1; }) .thenAccept(result -> { System.out.println("最终结果: " + result); }); // 主线程不用阻塞等待，可以继续做自己的事情 System.out.println("主线程继续做别的事情..."); // 为了演示不立即退出，简单 sleep 一下 Thread.sleep(2000); pool.shutdown(); } }

supplyAsync负责异步执行任务，返回CompletableFuture<Integer>。当任务抛出异常时，这个future会进入"异常完成"状态，然后链路上的exceptionally回调会被触发，入参ex就是CompletionException，它同样是包装层，真正的原始异常需要ex.getCause()获取。exceptionally必须返回一个同类型的降级结果，比如这里返回-1，后续的thenAccept照常消费结果，整条链路不会因为异常而中断。

与exceptionally对应的是handle((result, ex) -> ...)，它不管成功还是失败都会执行，让你在一个回调里同时处理两种情况。如果你的业务逻辑需要在异常之后执行补偿操作，但又想保留原始异常信息，用handle会更好。此外whenComplete也可以拿到两个参数，但它不改变结果值，适合做日志记录动作。

4.2 组合多个异步任务时的异常汇聚

CompletableFuture特别适合做多任务编排。比如我们要并发调用三个下游服务，然后再聚合结果做后续处理，这时可以用allOf()把多个 future 合并成一个。需要注意allOf本身在所有任务都正常完成时返回一个正常完成的 future，但任何子任务失败都会让它进入异常完成状态。借助这个特性，我们可以捕捉到第一个失败异常：

import java.util.Arrays; import java.util.List; import java.util.concurrent.*; import java.util.stream.Collectors; public class AllOfExceptionDemo { public static void main(String[] args) throws Exception { ExecutorService pool = Executors.newFixedThreadPool(3); List<CompletableFuture<String>> futures = Arrays.asList( CompletableFuture.supplyAsync(() -> task("A"), pool), CompletableFuture.supplyAsync(() -> task("B"), pool), CompletableFuture.supplyAsync(() -> task("C"), pool) ); CompletableFuture<Void> all = CompletableFuture.allOf( futures.toArray(new CompletableFuture[0]) ); all.exceptionally(ex -> { System.out.println("至少一个子任务异常: " + ex.getCause().getMessage()); // 返回 null 表示异常已被处理，后续 join 不会继续抛 return null; }).join(); // 聚合所有任务的结果 List<String> results = futures.stream() .map(CompletableFuture::join) .map(String::valueOf) .collect(Collectors.toList()); System.out.println("所有任务结果: " + results); pool.shutdown(); } private static String task(String name) { if ("B".equals(name)) { throw new IllegalStateException(name + " 任务处理失败"); } return name + "-ok"; } }

这里有个细节值得注意：allOf触发异常回调后，个别 future 的状态仍然是异常完成状态，此时调用join()会再次抛出CompletionException。所以我在exceptionally里返回了null来处理异常，这样后续join()才不会重复抛出。如果你不需要聚合所有结果，只是检测失败情况，那这条链路的写法可以更简单。

这个方案的工程价值在于，它把"异常处理"从主线程的阻塞点挪到了回调链中，主线程不会因为某个慢任务而长时间阻塞，同时异常仍然会被后续节点接管。

4.3 CompletableFuture 方案的使用边界

CompletableFuture并不是银弹。默认情况下它使用ForkJoinPool.commonPool()，这个公共线程池的并行度通常是 CPU 核数减一。如果在你的应用里很多人都在用CompletableFuture.supplyAsync而没传自定义线程池，那么所有任务会挤在同一组公共线程中执行，极端情况下出现饥饿，任务迟迟不启动。所以生产环境里强烈建议显式传入线程池对象，比如上面的例子，我用Executors.newFixedThreadPool(2)来控制并发度，避免干扰其它异步任务。

另外，exceptionally的设计让它天然适合"任务失败后降级"的场景，但如果失败需要"传播到上层调用方"——比如上层要根据失败做事务回滚——那么直接用CompletableFuture的回调其实并不妥当，它会把异常包装成CompletionException再传递，处理起来语义不够直观。这种情况下我更推荐用Future.get()方案，让上层通过同步调用的方式明确处理失败。

还有个容易误用的点：join()会抛出未受检异常CompletionException，但get()会抛出受检的ExecutionException。写 try-catch 时别指望着这两者互相替代，捕获类型不一样，代码迁移时容易漏。

5. 三种方案对比与选型建议

5.1 核心维度对比表

还有一层补充对比：异常传递载体不同。UncaughtExceptionHandler的异常不走返回值通道，它只是在线程终止前被回调；而后两者把异常包装进Future状态中，通过Future的读取动作把异常带回主线程。换句话说，如果你想"等待任务完成并拿到结果"，三个方案里Future.get()和CompletableFuture才是正路，第一套只适合做"有感知的旁路日志监控"。

从取舍角度讲，我最常见的组合拳是：用 ThreadFactory 设一个 UncaughtExceptionHandler 做全局兜底，同时使用 Future 或者 CompletableFuture 做业务结果处理。这样即使业务代码里某些环节走了execute()导致异常没抛出来，至少还有一个统一出口记录错误日志，把异常从"无声无息"变成"有迹可循"。

5.2 业务场景选型建议

如果你是在写批处理任务，比如凌晨定时跑报表、算库存、清理过期数据，这类任务的特点是"没人值守、异常不能影响主流程，但又必须留下完整痕迹"，那首选UncaughtExceptionHandler配合线程池的ThreadFactory，再外加大日志告警。它的好处是代码侵入性小，所有任务自动覆盖。

如果你是在处理一次 HTTP 请求，需要并发调用多个下游服务，拿到每个服务的返回结果再聚合输出，那必然选ExecutorService + Future。因为请求主线程必须等待所有下游返回，才能决定 HTTP 响应是什么。这里没有"异步回调"的余地，只能同步等待。注意给 get 设置合理的超时，避免上游接口慢导致整个请求超时。

如果你的架构里已经有事件驱动、消息队列、响应式编程的影子，或者任务节点之间有明确的先后依赖关系——比如 A 完成后取结果去调 B，失败就走降级缓存——那CompletableFuture比前两个方案合适得多。它可以把"分支异常处理"直接内联在链上，代码没有层层 if-else 回调地狱。

5.3 面试官最在意的 execute 与 submit 差异

ThreadPoolExecutor提供了四种提交任务的方法，其中execute(Runnable)与submit(Runnable/Callable)在实际异常处理上差异巨大。execute()提交的任务如果抛出未捕获异常，该异常不会通过Future传递，而是会直接导致执行该任务的 Worker 线程退出，同时线程池中的afterExecute(Runnable, Throwable)钩子会被调用。问题在于这个钩子的默认实现是空的，所以异常看上去就是"消失了"。

submit()提交时，底层会通过FutureTask.run()执行任务，run()内部会把异常捕获并设置到FutureTask的 outcome 字段中，这个字段就是get()时刻抛出ExecutionException的数据来源。所以同样是异常，execute是扔给 JVM 线程自然终止流程，submit是锁进Future里等你读取。

这个差异解释了为什么"题目说主线程捕获子线程异常"时，很多人首先会想到submit + get。实际操作时我会对 team 里的人提出一条要求：能用 submit 就尽量用 submit，哪怕不需要返回值也要把任务提交给 FutureTask，这样异常至少不会凭空消失。如果实在要使用 execute，那必须自定义afterExecute来记录异常。

6. 常见问题与排查技巧实录

6.1 用 execute() 提交任务后异常被吞，怎么捞回来

这个问题工程上太常见了。你要知道，ThreadPoolExecutor执行任务流程中，如果任务本身抛了RuntimeException，runWork()不会直接把异常传播出来让你在调用侧 catch 到，而是走到了 Worker 线程运行结束逻辑。想捞回异常，最直接的方式是重写afterExecute方法，在方法签名里Throwable t参数上做文章。

import java.util.concurrent.*; public class AfterExecuteCatcher { public static void main(String[] args) { ThreadPoolExecutor pool = new ThreadPoolExecutor( 2, 2, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<>() ) { @Override protected void afterExecute(Runnable r, Throwable t) { super.afterExecute(r, t); if (t == null && r instanceof FutureTask) { try { // FutureTask 已经被 run 完成，get 可以快速拿到异常 ((FutureTask<?>) r).get(); } catch (ExecutionException e) { t = e.getCause(); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); } } if (t != null) { System.err.println("任务异常被记录: " + t.getCause()); } } }; pool.execute(() -> { throw new IllegalStateException("这是一个测试异常"); }); pool.shutdown(); } }

这个技巧我建议写入团队规范里。它能保证当你用execute()提交任务时，异常至少被记录下来，防止直接吞掉。FutureTask.get()在已经 run 完成后并不会阻塞，因为FutureTask内部已经持有结果状态，取出异常代价很低。

6.2 UncaughtExceptionHandler 与 Future.get() 同时使用时会冲突吗

从机制上讲，两者并不冲突。当通过submit()提交FutureTask时，FutureTask.run()内部会捕获异常并记录到 outcome 中，既然异常已经被 catch 住，它就不会再传递给Thread.uncaughtExceptionHandler。这意味着如果你用submit()，那些在ThreadFactory里设置的 handler 往往不会触发。而如果用execute()且Runnable未捕获异常，那么异常可能会触发afterExecute或者线程的dispatchUncaughtException流程。

所以实际生产上要清楚优先级：submit()的任务异常走ExecutionException，不走UncaughtExceptionHandler；execute()的任务异常可能走afterExecute，也可能走 handler，具体看线程池的实现。不要把两者当成同一个异常可以同时触发。如果你既要 log 兜底又要业务上拿到异常，那就两个都写，但要知道在submit()场景下，兜底 handler 其实是空的，真正的工作要放在afterExecute或get()上。

6.3 排查实战：从日志到根因的完整路径

有一次线上任务调度失败，现象是每隔几小时就有一次任务悄悄失败，夜里的监控没有触发，第二天发现数据口径不一致。我排查的路径是这样的：先看业务日志，找到子线程名对应的日志片段，但发现只输出了Exception in thread "batch-worker-7"，没有业务调用链的 traceId。因为子线程无法继承主线程的日志上下文，导致异常日志和主线程日志之间无法串联。

这就是我在团队里推广的一个经验：在子线程启动或提交任务之前，把 traceId 通过ThreadLocal传入子线程，或者干脆把 traceId 打进线程名里。比如线程名设计为batch-worker-7-traceId-abcd1234，异常日志里就能直接看到它属于哪一次调度。另外所有submit任务都统一包装成组件内部的submitWithTrace方法，在方法里负责注入 traceId、设置UncaughtExceptionHandler、捕获ExecutionException并输出结构化日志。团队内所有成员不许裸写pool.execute()，括号内建议写明原因。

排查到根因后我发现是下游接口在null指针上直接抛了异常，而afterExecute没有覆盖到那个线程池，异常被吞掉。修复方案就是给线程池加上自定义afterExecute，并且在ThreadFactory中配置UncaughtExceptionHandler作为双重保险。从那以后，同类现象再也没出现过。

6.4 中断状态别乱吞

前面反复提到InterruptedException，这里再专门说一个细节。Future.get()和CountDownLatch.await()被中断时会抛出InterruptedException。很多代码喜欢直接 catch 后log.warn("interrupted")然后结束，这其实是把线程的中断状态给吞掉了，上层线程池无法感知此次中断，可能出现任务取消信号丢失。正确姿势是在 catch 里执行Thread.currentThread().interrupt()。这属于 Java 并发规范中的基本原则，面试也会问，真正做到的人并不多。

另一个相关心得是，当你捕获ExecutionException后不要只打印e.getMessage()。因为包装异常的 message 很可能是通用的，比如"java.lang.RuntimeException: B 任务处理失败"这种，真正定位到代码片段需要完整堆栈。调试期使用e.getCause().printStackTrace()，或者用日志框架输出log.error("...", e.getCause())，保留完整 cause 链。

7. 一个小扩展：自定义异常包装器提升排查效率

三个方案里，最终拿到的原始异常都会带着完整堆栈，但大型项目里堆栈打印多到刷屏，你根本分不清这条异常是从哪个任务冒出来的。所以我会建议在项目里封装一个统一异常出口，把"线程名、任务名、任务 ID、上下文参数、异常对象"包装成一个TaskFailedException，再对外抛出或者写入日志。这样既能保留原始堆栈，又方便在日志检索系统里按字段过滤。

比如定义异常类：

public class TaskFailedException extends RuntimeException { private final String taskName; private final String threadName; private final Object payload; public TaskFailedException(String taskName, String threadName, Object payload, Throwable cause) { super("task=" + taskName + ", thread=" + threadName + ", payload=" + payload, cause); this.taskName = taskName; this.threadName = threadName; this.payload = payload; } }

在Future.get()捕获到ExecutionException后，统一包装成TaskFailedException再抛给上层。上层只需要捕获这一个大类，然后读取taskName、payload去做重试、告警或者降级。这个做法的价值是让"主线程捕获子线程异常"这件事从单纯的技术技巧升级成一套可观测体系。你会在实际运用中体会到日志排查效率的明显提升。

文章写到这里，三个方案的原理、代码、边界、坑基本都覆盖到了。如果时间有限，我的建议是先把Future.get()和ThreadFactory + UncaughtExceptionHandler这两套弄熟，它们覆盖了绝大多数场景；CompletableFuture可以在你开始做异步编排时再深入。并发编程里，异常处理不是炫技，而是保证系统发生后还能被观测、被恢复的关键一环。