当线程池里的任务抛出异常时，异常信息经常"消失"了，控制台看不到任何报错。这就是线程池默认行为带来的坑。今天我们就来搞清楚怎么"接管"这些异常。
一、问题现象：异常被"吞掉"了
先看一段典型代码，感受一下问题：
ExecutorService executor = Executors.newFixedThreadPool(2); executor.submit(() -> { System.out.println("任务开始执行..."); int result = 10 / 0; // 这里会抛 ArithmeticException System.out.println("任务执行完毕: " + result); }); executor.shutdown();运行结果：
任务开始执行...然后就没了……没有异常堆栈，程序也没崩溃，仿佛什么都没发生。
这就是线程池默认把异常给"吞"了。
原因：
submit()方法返回一个Future对象，异常被封装在Future里。如果你不调用future.get()，异常就不会被抛出来。
二、自定义异常处理的 4 种方式
方式 1：在任务内部 try-catch（最基础）
这是最直接的办法，把异常处理逻辑写在任务里：
executor.submit(() -> { try { int result = 10 / 0; } catch (Exception e) { System.out.println("任务出错了: " + e.getMessage()); // 这里可以记录日志、发送告警等 } });优点：简单直观，每个任务自己管自己。
缺点：每个任务都要写 try-catch，代码重复，容易漏。
方式 2：包装一个统一的任务包装器
把 try-catch 逻辑抽出来，封装成一个工具方法：
public class TaskWrapper { public static Runnable wrap(Runnable task) { return () -> { try { task.run(); } catch (Exception e) { System.out.println("【统一捕获】任务异常: " + e.getClass().getName() + " - " + e.getMessage()); e.printStackTrace(); // 这里可以接入日志框架，比如 log.error(...) } }; } } // 使用 executor.submit(TaskWrapper.wrap(() -> { int result = 10 / 0; }));优点：统一处理，不用每个任务都写 try-catch。
缺点：每次提交任务都要包一层，稍微麻烦。
方式 3：自定义 ThreadFactory，设置未捕获异常处理器（推荐）
这是线程池级别的统一处理，也是最优雅的方式之一。
// 1. 自定义 ThreadFactory，给每个线程设置 UncaughtExceptionHandler ThreadFactory customThreadFactory = r -> { Thread t = new Thread(r); t.setUncaughtExceptionHandler((thread, throwable) -> { System.out.println("【线程池级异常处理】线程 " + thread.getName() + " 发生异常: " + throwable.getMessage()); throwable.printStackTrace(); // 这里可以：记录日志、发送钉钉/企业微信告警、统计异常次数等 }); return t; }; // 2. 使用自定义 ThreadFactory 创建线程池 ExecutorService executor = new ThreadPoolExecutor( 2, // 核心线程数 4, // 最大线程数 60L, TimeUnit.SECONDS, // 空闲线程存活时间 new LinkedBlockingQueue<>(100), // 任务队列 customThreadFactory, // 自定义线程工厂 new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略 ); // 3. 提交任务（用 execute，不是 submit！） executor.execute(() -> { System.out.println("任务执行中..."); throw new RuntimeException("模拟业务异常"); });⚠️关键点：
UncaughtExceptionHandler只对execute()提交的任务生效。如果用submit()，异常会被封装进Future，不会触发这个处理器。
方式 4：自定义 ThreadPoolExecutor，重写 afterExecute 方法（最强大）
如果你需要同时处理execute()和submit()的异常，可以自定义线程池类，重写afterExecute方法：
public class CustomThreadPool extends ThreadPoolExecutor { public CustomThreadPool(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) { super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue); } @Override protected void afterExecute(Runnable r, Throwable t) { super.afterExecute(r, t); // submit() 提交的异常会被包装在 FutureTask 里，需要特殊处理 if (t == null && r instanceof Future<?>) { try { Future<?> future = (Future<?>) r; if (future.isDone()) { future.get(); // 这里会抛出异常 } } catch (ExecutionException ee) { t = ee.getCause(); // 拿到真正的异常 } catch (InterruptedException | CancellationException ignored) { } } if (t != null) { System.out.println("【afterExecute 捕获异常】: " + t.getMessage()); t.printStackTrace(); // 这里可以做：日志记录、监控告警、失败重试等 } } } // 使用 CustomThreadPool pool = new CustomThreadPool( 2, 4, 60, TimeUnit.SECONDS, new LinkedBlockingQueue<>(100) ); // 用 submit 也能捕获到异常！ pool.submit(() -> { throw new RuntimeException("submit 抛出的异常"); });优点：无论execute()还是submit()，异常都能统一捕获。
缺点：稍微复杂一点，需要继承ThreadPoolExecutor。
三、4 种方式对比总结
| 方式 | 粒度 | 能否捕获 submit 异常 | 复杂度 | 适用场景 |
|---|---|---|---|---|
| 任务内 try-catch | 单个任务 | ✅ 能 | ⭐ 简单 | 临时任务、快速修复 |
| 任务包装器 | 单个任务 | ✅ 能 | ⭐ 简单 | 需要统一包装但不想改线程池 |
| 自定义 ThreadFactory | 线程池级别 | ❌ 不能（仅 execute） | ⭐⭐ 中等 | 大部分场景，配合 execute 使用 |
| 重写 afterExecute | 线程池级别 | ✅ 能 | ⭐⭐⭐ 稍复杂 | 需要完整监控、审计、重试机制 |
四、实际工作中的建议
简单项目：用方式 3（自定义 ThreadFactory + UncaughtExceptionHandler），配合
execute()提交任务，足够用了。中大型项目：用方式 4（重写
afterExecute），接入日志框架（SLF4J + Logback），异常发生时自动记录并推送告警。无论哪种方式，不要在异常处理里再抛异常，否则可能导致线程池里的线程被销毁，影响任务执行。
生产环境建议：异常处理里做这几件事：
记录详细日志（线程名、任务信息、异常堆栈）
接入监控告警（钉钉、邮件、Prometheus 等）
考虑失败重试或放入死信队列
