一、前言
线程池技术是服务器端开发中常用的技术。不论是直接还是间接，各种服务器端功能的执行总是离不开线程池的调度。关于线程池的各种文章，多数是关注任务的创建和执行方面，对于异常处理和任务取消（包括线程池关闭）关注的偏少。
接下来，本文将从 Java 原生线程、两种主要线程池ThreadPoolExecutor和ScheduledThreadPoolExecutor这三方面介绍 Java 中线程的异常处理机制。
二、Thread
在谈线程池的异常处理之前，我们先来看 Java 中线程中的异常是如何被处理的。大家都知道如何创建一个线程任务：
代码1
Thread t =newThread(() -> System.out.println("Execute in a thread"));
t.start();
为了简化代码，这里使用了 Java 8 的 Lambda 表达式。() -> System.out.println("Execute in a thread")等同于在Runnable中执行System.out.println方法。后面不再解释。
如果这个任务抛出了异常，那又会怎样：
代码2
Thread t =newThread(() -> System.out.println(1/0));
t.start();
如果我们执行上面这段代码，会在控制台上看到异常输出。可能多数同学会对此不会觉得问题，但是问题在于，通常情况下绝大多数线上应用不会将控制台作为日志输出地址，而是另有日志输出。这种情况下，上面的代码所抛出异常便会丢失。
那为了将异常输出到日志中，我们会这样写代码：
代码3
Thread t =newThread(() -> {
try{
System.out.println(1/0);
}catch(Exceptione) {
LOGGER.error(e.getMessage(), e);
}
});
t.start();
这样我们就能异常栈输出到日志中，而不是控制台，从而避免异常的丢失。
过了一段时间，问题又来了，可能好多线程任务默认的异常处理机制都是相同的。比如都是将异常输出到日志文件。按照上面的写法会造成重复代码。虽然重复的不多，但是有代码洁癖的小伙伴可能也会觉得不舒服。
那我们该如何解决这个问题呢？其实 JDK 已经为我们想到了，Thread类中有个接口UncaughtExceptionHandler。通过实现这个接口，并调用Thread.setUncaughtExceptionHandler(UncaughtExceptionHandler)方法，我们就能为一个线程设置默认的异常处理机制，避免重复的try...catch了。
除此以外，我们还可以通过Thread.setDefaultUncaughtExceptionHandler(UncaughtExceptionHandler)设置全局的默认异常处理机制。此外，ThreadGroup也实现了UncaughtExceptionHandler接口，所以通过ThreadGroup还可以为一组线程设置默认的异常处理机制。
其实，之所以代码2在执行之后我们能在控制台上看到异常，也是因为UncaughtExceptionHandler机制。ThreadGroup默认提供了异常处理机制如下：
代码4
publicvoiduncaughtException(Thread t, Throwable e){
if(parent!=null) {
parent.uncaughtException(t, e);
}else{
Thread.UncaughtExceptionHandler ueh =
Thread.getDefaultUncaughtExceptionHandler();
if(ueh !=null) {
ueh.uncaughtException(t, e);
}elseif(!(einstanceofThreadDeath)) {
// 最终执行如下代码
System.err.print("Exception in thread \""
+ t.getName() +"\" ");
e.printStackTrace(System.err);
}
}
}
三、ThreadPoolExecutor
在 Java 5 发布之后，线程池便开始越来越广泛地用于创建并发任务。多数时候，当说到 Java 的线程池时，我们一般指的就是ThreadPoolExecutor。那在ThreadPoolExecutor中是如何处理异常的呢？
代码5
Executors.newSingleThreadExecutor().execute(() -> {
thrownewRuntimeException("My runtime exception");
});
上面的代码的异常处理机制其实同直接使用Thread是一样的。所以也有同样的问题，异常信息无法反映在日志文件中。解决这个问题的方法同上一节一样：在每个Runnable中编写try ... catch语句；或者使用UncaughtExceptionHandler机制。
我们先来看如何为线程池中的工作线程设置UncaughtExceptionHandler。
为线程池工作线程设置 UncaughtExceptionHandler
简单来说，就是通过ThreadFactory。通过ThreadPoolExecutor的构造函数和Executors中的工具方法，我们都可以为新创建的线程池设置ThreadFactory。
ThreadFactory是个接口，它只定义了一个方法Thread newThread(Runnable r)。在这个方法中，我们可以为新创建出来的线程设置UncaughtExceptionHandler。当然，这样写起来显得很麻烦，好在 Apache Commons 和 Google Guava 这两个最有名的 Java 工具类库都为我们提供了相应的类库以简化配置ThreadFactory的工作。下面以 Apache Commons 提供的BasicThreadFactoryBuilder为例
代码6
ThreadFactory executorThreadFactory =newBasicThreadFactory.Builder()
.namingPattern("task-scanner-executor-%d")
.uncaughtExceptionHandler(newLogUncaughtExceptionHandler(LOGGER))
.build();
Executors.newSingleThreadExecutor(executorThreadFactory);
UncaughtExceptionHandler 一定起作用吗？
此话怎讲呢？其实ThreadPoolExecutor为执行并发任务提供了两种方法：execute(Runnable)和submit(Callable/Runnable)。之前的代码示例只演示了执行execute(Runnable)时的情况。那在设置了默认的UncaughtExceptionHandler之后，当执行submit(Callable/Runnable)方法，抛出抛异常之后有会如何？
看下面的代码
代码7
ThreadFactory threadFactory =newThreadFactoryBuilder()
.setUncaughtExceptionHandler(newLogExceptionHandler())
.build();
Executors.newSingleThreadExecutor(threadFactory)
.submit(() -> {
thrownewRuntimeException("test");
});
上面的程序执行完之后，不会在控制台或日志中看到任何输出，虽然设置了UncaughtExceptionHandler。要弄清原因，就要看一下ThreadPoolExecutor的源代码
代码8
publicFuture submit(Runnabletask) {
if(task==null)thrownewNullPointerException();
RunnableFuture ftask = newTaskFor(task,null);
execute(ftask);
returnftask;
}
submit方法是调用execute实现任务执行的。但是在调用execute之前，任务会被封装进FutureTask类中，然后最终工作线程执行的是FutureTask中的run方法。
代码9：FutureTask.run
try{
result = c.call();
ran =true;
}catch(Throwable ex) {
result =null;
ran =false;
setException(ex);
}
protected void setException(Throwable t) {
if(UNSAFE.compareAndSwapInt(this, stateOffset,NEW, COMPLETING)) {
outcome = t;
UNSAFE.putOrderedInt(this, stateOffset, EXCEPTIONAL);// final state
finishCompletion();
}
}
由上面的代码可以看出，不同于直接调用execute方法，调用submit方法后，如果任务抛出异常，会被setException方法赋给代表执行结果的outcome变量，而不会继续抛出。因此，UncaughtExceptionHandler也没有机会处理。
如果想知道submit的执行结果是成功还是失败，必须调用Future.get()方法。
UncaughtExceptionHandler 是否适合在线程池中使用
从上面的分析中可以看出，使用UncaughtExceptionHandler，可以处理到使用execute方法执行任务所抛出的异常，但是对submit方法无效。那如果只是用execute方法，我们是否可以通过设置UncaughtExceptionHandler从而添加一种默认的异常处理机制，以避免重复的try...catch代码呢？
答案是不能。原因在于，如果在执行execute方法时不在Runnable.run方法中写try...catch方法，自然异常会交由UncaughtExceptionHandler处理，但是，在这之前，线程的工作线程会因为异常而退出。虽然线程池会创建一个新的工作线程，但是如果这个步骤反复执行，效率自然会下降很多。
四、ScheduledThreadPoolExecutor
ScheduledThreadPoolExecutor是另一种常用的线程池，常用了执行延迟任务或定时任务。常用的方法为scheduleXXX系列。那在这个线程池中异常是如何处理的呢？
其实，如果看过前面的部分，到这里也基本能猜出来了。ScheduledThreadPoolExecutor用来封装任务的是ScheduledFutureTask。ScheduledFutureTask是FutureTask的子类，所以，异常也会被复制给outcome。
但是，这里还是有一些差异的。在使用ThreadPoolExecutor.submit和ScheduledThreadPoolExecutor.schedule方法时，我们可以通过这两个方法返回的Future来获得执行结果，这包括正常结果，也包括异常结果。但是，对于ScheduledThreadPoolExecutor.scheduleWithFixedDelay和scheduleAtFixedRate这两个方法，其返回的Future只会用来取消任务，而不是得到结果。原因也很容易理解，因为这两个方法执行的是定时任务，是反复执行的。这也是为什么这两个方法的任务定义使用了Runnable接口，而不是有返回值的Callable接口。因此，对于这两个方法来说，在Runnable.run方法中加try...catch是必须的，否则很有可能出错了却毫不知情。
五、结论
在Thread中，我们可以通过UncaughtExceptionHandler来实现默认的异常处理机制。但是在使用ThreadPoolExecutor和ScheduledThreadPoolExecutor这两个 JDK 最主要的线程池时，使用UncaughtExceptionHandler是不合适的。所以，try...catch往往是不可避免的，否则你的任务很有可能失败的悄无声息。