Java Executor并发框架（十三）Executor框架线程池关于异常的处理

一、介绍

关于为什么要写这篇文章，是因为我对Executor线程池的两种提交任务的方式的不同产生的好奇，我们知道，可以通过execute和submit两种方式往线程池提交我们的任务，但是这两种任务提交的方式到底有什么区别呢？通过execute方式提交的任务，我们不能获取任务执行后的返回值，而通过submit提交任务的方式，我们是可以获取任务执行结束后产生的结果。那么另一个区别就是关于异常的问题了，请看下文。

二、问题的研究

ok, 我们写一个类，继承ThreadPoolExecutor，命名为MyThreadPoolExecutor，并重写然后使用MyThreadPoolExecutor创建一个线程池。

MyThreadPoolExecutor代码：

package com.npf;import java.util.concurrent.BlockingQueue;import java.util.concurrent.ThreadPoolExecutor;import java.util.concurrent.TimeUnit;public class MyThreadPoolExecutor extends ThreadPoolExecutor {public MyThreadPoolExecutor(int corePoolSize, int maximumPoolSize,long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) {super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue);}@Overrideprotected void afterExecute(Runnable r, Throwable t) {super.afterExecute(r, t);System.out.println("MyThreadPoolExecutor.afterExecute()");}}

一看afterExecute这个方法，想当然的以为如果线程池中出了问题，异常自然回在第二个参数 t 中传过来。也许的确是这样的，但是这里有一个区别。我们知道ExecutorServcie中执行一个Runnable有三个方法，分别是：
第一种，Executor接口中定义的execute方法：


第二种，AbstractExecutorService实现的submit(Runnable task)方法。


第三种，AbstractExecutorService实现的submit(Runnable task，T result)方法。


后面两种提交runnable任务的方式，内部都调用了newTaskFor(Callable<T> callable)方法：


通过上面，我们知道，后面两种提交runnable任务的方式，内部都是将runnable任务封装成了FutureTask，然后再执行execute方法，我们知道execute方法是定义在Executor接口中的方法，它接收的参数是Runnable类型，为什么我们的FutureTask也符合execute方法的参数定义呢？
请看FutureTask的定义：



FutureTask实现了RunnableFuture，而RunnableFuture继承了Runnable, Future<V>接口。


综上我们知道，到最后都是会调用execute方法。execute方法对进来的Runnable又包装成了worker然后进入runWorker
runWorker方法中有这么几行：

try {    beforeExecute(wt, task);    Throwable thrown = null;    try {       task.run();    } catch (RuntimeException x) {       thrown = x; throw x;    } catch (Error x) {       thrown = x; throw x;    } catch (Throwable x) {       thrown = x; throw new Error(x);    } finally {       afterExecute(task, thrown);    }} finally {    task = null;    w.completedTasks++;    w.unlock();}

好了，到了最关键的afterExecute这个步骤，我满心以为这里所有的异常都会通过thrown传递进来，看来我还是太年轻了，之前我们分析过，这个Runnable已经被submit封装成了FutureTask，那么这个task.run()除了我们自己定义的run任务之外，到底还干了啥呢？
因为如果我们通过submit的方式提交Runnable的对象被封装成了FutureTask, 那么这里的task.run()这句代码的task对象实际上就是FutureTask对象，那么这个run也就是FutureTask的方法，下面我们贴出FutureTask的run方法的源码：

public void run() {    if (state != NEW ||        !UNSAFE.compareAndSwapObject(this, runnerOffset,                                     null, Thread.currentThread()))        return;    try {        Callable<V> c = callable;        if (c != null && state == NEW) {            V result;            boolean ran;            try {                result = c.call();                ran = true;            } catch (Throwable ex) {                result = null;                ran = false;                setException(ex);            }            if (ran)                set(result);        }    } finally {        // runner must be non-null until state is settled to        // prevent concurrent calls to run()        runner = null;        // state must be re-read after nulling runner to prevent        // leaked interrupts        int s = state;        if (s >= INTERRUPTING)            handlePossibleCancellationInterrupt(s);    }}

实际我们自己定义的任务已经变成了Callable对象，那么这里的Callable对象的实现类到底是谁呢？
也就是Callable<V> c = callable; 这个callable的具体类型到底是什么？请看下面的分析。

我们知道，通过submit的方式提交Runnable的对象被封装成了FutureTask的关键地方就是：


那么我们进入到FutureTask的这个构造方法里面去看：


再进入到Executors.callable(runnable, result)方法里面去看：


再进入到RunnableAdapter里面去看，很简单的发现，这就是一个典型的适配器模式：

到这里已经很清楚了，这个callable对象就是RunnableAdapter。

也就是说，如果我们使用submit的方式提交Runnable的对象，那么这个callable对象就是RunnableAdapter，然后程序下面的result = c.call(); 的时候，实际就是执行RunnableAdapter的call()方法, 在这个call方面里面，实际调用了我们提交的Runnable对象的run方法。我们写的任务全部在这句代码里面执行完毕了，看看外面都wrap了啥？ OK，我们所有的Throwable全部已经被setException吃掉了，怎么还会抛出到外面那层的execute中呢？所以在submit中提交任务无论任务怎么抛异常，在afterExecute中的第二个参数是取不到的，原因就在这。

如果我们需要获取这个异常怎么办呢？通过FutureTask的get方法，能把刚刚setException中的异常给抛出来，这样我们就能真的拿到这些异常了。

protected void afterExecute(Runnable r, Throwable t) {    super.afterExecute(r, t);    Future<?> f = (Future<?>) r;    try {        f.get();    } catch (InterruptedException e) {        logger.error("线程池中发现异常，被中断", e);    } catch (ExecutionException e) {        logger.error("线程池中发现异常，被中断", e);    }}

如果我们直接通过execute方法提交任务，那么上面刚才我们分析的代码片段中：

try {    beforeExecute(wt, task);    Throwable thrown = null;    try {       task.run();    } catch (RuntimeException x) {       thrown = x; throw x;    } catch (Error x) {       thrown = x; throw x;    } catch (Throwable x) {       thrown = x; throw new Error(x);    } finally {       afterExecute(task, thrown);    }} finally {    task = null;    w.completedTasks++;    w.unlock();}

task.run()中，这个task就是实际的Runnable对象，那么如果这里发生异常的话，afterExecute这个方法的第二个参数thrown就会有异常信息了。

三、结论

如果我们关心线程池执行的结果，则需要使用submit来提交task，那么在afterExecute中对异常的处理也需要通过Future接口调用get方法去取结果，才能拿到异常，如果我们不关心这个任务的结果，可以直接使用ExecutorService中的execute方法（实际是继承Executor接口）来直接去执行任务，这样的话，我们的Runnable没有经过多余的封装，在runWorker中得到的异常也直接能在afterExecute中捕捉。




参考文献：
1. Java ExecutorService线程池中的小坑——关于线程池中抛出的异常处理