在Java并发编程中，线程池可以高效管理线程资源，提升任务执行效率，但任务执行过程中抛出的异常如果未被正确处理，往往会被线程池吞掉，导致开发者无法感知异常发生，给问题排查带来很大困难。不同的任务提交方式、不同的线程池配置，对应的异常处理逻辑也存在差异，需要针对性选择处理方案。
线程池任务异常的默认行为
线程池处理异常的逻辑和任务的提交方式、任务类型直接相关，首先需要明确默认情况下的异常表现，才能针对性做处理。
Runnable任务的默认异常行为
当我们向线程池提交Runnable任务时，如果任务执行过程中抛出未捕获的异常，线程池会将该异常交给线程的未捕获异常处理器处理，默认情况下异常只会被打印到控制台，不会被上层调用者感知。
示例代码如下：
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class ThreadPoolExceptionDemo {
public static void main(String[] args) {
ExecutorService executor = Executors.newFixedThreadPool(2);
// 提交Runnable任务，任务内部抛出异常
executor.execute(() -> {
System.out.println("任务开始执行");
throw new RuntimeException("Runnable任务执行异常");
});
executor.shutdown();
}
}
执行上述代码后，控制台只会输出异常堆栈信息，主线程无法获取到该异常，也无法做后续的业务处理。
Callable任务的默认异常行为
如果提交的是Callable任务，异常会被封装到返回的Future对象中，只有调用Future.get()方法时才会抛出，不会主动打印到控制台。
示例代码如下：
import java.util.concurrent.*;
public class CallableExceptionDemo {
public static void main(String[] args) throws ExecutionException, InterruptedException {
ExecutorService executor = Executors.newFixedThreadPool(2);
// 提交Callable任务，任务内部抛出异常
Future<String> future = executor.submit(() -> {
System.out.println("Callable任务开始执行");
throw new RuntimeException("Callable任务执行异常");
});
// 调用get方法才会抛出封装的异常
future.get();
executor.shutdown();
}
}
这种情况下如果不调用Future.get()，异常就会被一直隐藏，不会被任何地方处理。
常用的线程池异常处理方案
方案一：使用Future获取任务执行结果和异常
对于通过submit方法提交的Callable或者Runnable任务，都可以通过返回的Future对象获取执行结果，同时捕获任务抛出的异常。
如果是Runnable任务，submit方法返回的Future.get()在任务正常执行时会返回null，任务抛出异常时则会抛出封装后的ExecutionException，可以通过该异常获取原始异常信息。
示例代码如下：
import java.util.concurrent.*;
public class FutureExceptionHandle {
public static void main(String[] args) {
ExecutorService executor = Executors.newFixedThreadPool(2);
// 提交Runnable任务到线程池
Future<?> future = executor.submit(() -> {
System.out.println("Runnable任务执行");
throw new RuntimeException("任务执行失败");
});
try {
// 获取任务结果，触发异常处理
future.get();
} catch (InterruptedException e) {
// 处理线程中断异常
Thread.currentThread().interrupt();
System.out.println("任务被中断");
} catch (ExecutionException e) {
// 获取任务抛出的原始异常
Throwable cause = e.getCause();
System.out.println("捕获到任务异常：" + cause.getMessage());
// 这里可以做自定义的业务处理，比如告警、重试等
} finally {
executor.shutdown();
}
}
}
这种方案适合需要获取任务执行结果，并且需要明确感知每个任务执行状态的场景，缺点是需要手动调用Future.get()，如果任务很多，管理起来会比较繁琐。
方案二：自定义线程未捕获异常处理器
线程池中的线程抛出的未捕获异常，最终会交给线程的UncaughtExceptionHandler处理，我们可以自定义该处理器，统一处理所有线程的未捕获异常。
首先自定义异常处理器实现Thread.UncaughtExceptionHandler接口：
import java.lang.Thread;
public class CustomExceptionHandler implements Thread.UncaughtExceptionHandler {
@Override
public void uncaughtException(Thread t, Throwable e) {
System.out.println("线程" + t.getName() + "抛出未捕获异常，异常信息：" + e.getMessage());
// 这里可以做统一的异常处理，比如记录日志、发送告警等
e.printStackTrace();
}
}
然后将自定义的处理器设置到线程池的线程工厂中，让线程池创建的线程都使用该处理器：
import java.util.concurrent.Executors;
import java.util.concurrent.ThreadFactory;
import java.util.concurrent.ThreadPoolExecutor;
public class ThreadPoolWithExceptionHandler {
public static void main(String[] args) {
// 自定义线程工厂，设置未捕获异常处理器
ThreadFactory threadFactory = r -> {
Thread thread = new Thread(r);
thread.setUncaughtExceptionHandler(new CustomExceptionHandler());
return thread;
};
// 创建线程池，使用自定义线程工厂
ThreadPoolExecutor executor = new ThreadPoolExecutor(
2,
2,
0L,
java.util.concurrent.TimeUnit.MILLISECONDS,
new java.util.concurrent.LinkedBlockingQueue<>(),
threadFactory
);
// 提交Runnable任务，异常会被自定义处理器捕获
executor.execute(() -> {
System.out.println("任务执行");
throw new RuntimeException("任务异常");
});
executor.shutdown();
}
}
这种方案适合需要统一处理所有线程池任务未捕获异常的场景，但是只对execute方法提交的Runnable任务生效，对submit方法提交的任务无效，因为submit方法会将任务封装成FutureTask，异常会被FutureTask捕获，不会传递给线程的未捕获异常处理器。
方案三：重写线程池的afterExecute方法
ThreadPoolExecutor提供了afterExecute方法，该方法会在每个任务执行完成后被调用，我们可以重写该方法，在方法内部获取任务执行过程中抛出的异常并进行处理。
示例代码如下：
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
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);
// 如果t不为null，说明execute方法提交的任务抛出了未捕获异常
if (t != null) {
System.out.println("捕获到任务异常：" + t.getMessage());
t.printStackTrace();
}
// 如果是submit方法提交的任务，异常会被封装到FutureTask中，需要从FutureTask中获取
if (r instanceof java.util.concurrent.Future<?>) {
try {
java.util.concurrent.Future<?> future = (java.util.concurrent.Future<?>) r;
// 调用get方法获取异常，如果任务正常完成，get方法会正常返回，不会抛异常
future.get();
} catch (Exception e) {
// ExecutionException的cause就是任务抛出的原始异常
Throwable cause = e.getCause();
if (cause != null) {
System.out.println("捕获到submit任务异常：" + cause.getMessage());
cause.printStackTrace();
}
}
}
}
public static void main(String[] args) {
CustomThreadPool executor = new CustomThreadPool(2, 2, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<>());
// 测试execute提交的任务
executor.execute(() -> {
throw new RuntimeException("execute任务异常");
});
// 测试submit提交的任务
executor.submit(() -> {
throw new RuntimeException("submit任务异常");
});
executor.shutdown();
}
}
这种方案可以同时处理execute和submit方法提交的任务异常，比较通用，适合需要统一处理线程池所有任务异常的场景。
方案四：在任务内部主动捕获异常
最基础的处理方式是在Runnable或者Callable任务的内部主动捕获异常，在任务内部做处理，这种方式最灵活，也最容易控制。
示例代码如下：
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class TaskInnerExceptionHandle {
public static void main(String[] args) {
ExecutorService executor = Executors.newFixedThreadPool(2);
executor.execute(() -> {
try {
System.out.println("任务执行");
// 业务逻辑
int a = 1 / 0;
} catch (Exception e) {
System.out.println("任务内部捕获异常：" + e.getMessage());
// 内部处理异常，比如记录日志、重试等
}
});
executor.shutdown();
}
}
这种方案适合每个任务的异常处理逻辑差异较大的场景，缺点是需要每个任务都写异常处理代码，代码重复度较高。
不同处理方案的适用场景对比
为了更方便选择合适的处理方案，我们可以通过下表对比不同方案的特点和适用场景：
| 处理方案 | 适用任务类型 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| Future获取结果 | submit提交的Callable、Runnable | 可以获取任务返回结果，异常感知明确 | 需要手动调用get方法，管理成本高 | 需要获取单个任务结果，且需要明确感知任务状态的场景 |
| 自定义未捕获异常处理器 | execute提交的Runnable | 统一处理所有线程异常，代码侵入性低 | 对submit提交的任务无效 | 只需要处理execute提交任务异常，且需要统一处理的场景 |
| 重写afterExecute方法 | 所有提交方式的任务 | 通用性强，可统一处理所有任务异常 | 实现相对复杂，需要了解线程池原理 | 需要统一处理线程池所有任务异常的场景 |
| 任务内部捕获异常 | 所有任务类型 | 灵活，可针对单个任务定制处理逻辑 | 代码重复度高，侵入性强 | 不同任务异常处理逻辑差异大的场景 |
注意事项
- 如果使用
Future.get()处理异常，需要注意get方法是阻塞的，如果任务执行时间很长，会阻塞当前线程，建议结合超时参数使用，比如future.get(5, TimeUnit.SECONDS)。 - 自定义未捕获异常处理器只对
execute提交的Runnable任务生效，不要误以为可以处理所有任务异常。 - 重写
afterExecute方法时，需要同时处理execute和submit两种提交方式的异常，避免遗漏。 - 如果线程池的任务执行异常需要触发告警、重试等业务逻辑，建议在异常处理逻辑中做好幂等设计，避免重复处理带来额外问题。