线程池的自定义异常处理机制

当线程池里的任务抛出异常时，异常信息经常"消失"了，控制台看不到任何报错。这就是线程池默认行为带来的坑。今天我们就来搞清楚怎么"接管"这些异常。

一、问题现象：异常被"吞掉"了

先看一段典型代码，感受一下问题：

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 种方式对比总结

四、实际工作中的建议

1. 简单项目：用方式 3（自定义 ThreadFactory + UncaughtExceptionHandler），配合execute()提交任务，足够用了。

2. 中大型项目：用方式 4（重写afterExecute），接入日志框架（SLF4J + Logback），异常发生时自动记录并推送告警。

3. 无论哪种方式，不要在异常处理里再抛异常，否则可能导致线程池里的线程被销毁，影响任务执行。

4. 生产环境建议：异常处理里做这几件事：

   • 记录详细日志（线程名、任务信息、异常堆栈）

   • 接入监控告警（钉钉、邮件、Prometheus 等）

   • 考虑失败重试或放入死信队列