关于多线程中抛异常的这个面试题我再说最后一次！

这里why的第 66 篇原创文章

一道面试题

我一年前写过这篇文章《有的线程它死了，于是它变成一道面试题》，这是早期作品，遣词造句，排版行文都有一点稚嫩，但是不知咋地，还是有很多人看过。

甚至已经进入了某网红公司的面试题库里面。

所以我后面应该会重写一下，翻新翻新，再补充一点新的东西进去。

现在先回顾一下这篇文章抛出的问题和问题的答案：

一个线程池中的线程异常了，那么线程池会怎么处理这个线程?

这个题是我遇到的一个真实的面试题，当时并没有回答的很好。然后通过上面的文章，我在源码中寻找到了答案。

先给大家看两个案例。

当执行方式是 execute 方法时，在控制台会打印堆栈异常：

当执行方式是 submit 方法时，在控制台不会打印堆栈异常：

那么怎么获取这个 submit 方法提交时的异常信息呢？

得调用返回值 future 的 get 方法：

具体原因，我在之前的文章里面详细分析过，就不赘述了，直接看结论：

然后一个读者找我聊天，说为什么他这样写，通过 future.get 方法没有抛出异常呢，和我文章里面说的不一样呢？

我说：那肯定是你操作不对，你把代码发给我看看。

然后我收到了一份这样的代码：

public class ExecutorsTest {
    public static void main(String[] args) {
        ThreadPoolExecutor executorService = new ThreadPoolExecutor(2, 2,
                30, TimeUnit.SECONDS, new ArrayBlockingQueue<>(10));
        Future future = executorService.submit(() -> {
            try {
                sayHi("submit");
            } catch (Exception e) {
                System.out.println("sayHi Exception");
                e.printStackTrace();
            }
        });
        try {
            future.get();
        } catch (Exception e) {
            System.out.println("future.get Exception");
            e.printStackTrace();
        }
    }
    private static void sayHi(String name) throws RuntimeException {
        String printStr = "【thread-name:" + Thread.currentThread().getName() + ",执行方式:" + name + "】";
        System.out.println(printStr);
        throw new RuntimeException(printStr + ",我异常啦!哈哈哈!");
    }
}

这个程序的输出结果是这样的：

我寻思这没毛病呀，这不是很正常吗？不就是应该这样输出吗？

那个哥们说：和你说的不一样啊，你说的是调用 future.get 方法的时候会抛出异常的？我这里并没有输出“future.get Exception”，说明 future.get 方法没有抛出异常。

我回答到：你这不是把会抛出运行时异常的 sayHi 方法用 try/catch 代码块包裹起来了吗？异常在子线程里面就处理完了，也就不会封装到 Future 里面去了。你把 try/catch 代码块去掉，异常就会封装到 Future 里面了。

过了一小会，他应该是实验完了，又找过来了。

他说：牛逼呀，确实是这样的。那你的这个面试题是有问题的啊，描述不清楚，正确的描述应该是一个线程池中的线程抛出了未经捕获的运行时异常，那么线程池会怎么处理这个线程？

看到他的这个回复的时候，我竟然鼓起掌来，这届读者真是太严格了！但是他说的确实是没有错，严谨点好。

他还追问到：怎么实现的呢？为什么当 submit 方法提交任务的时候，子线程捕获了异常，future.get 方法就不抛出异常了呢？

其实听到这个问题的时候都把我干懵了。

这问法，难道你是想再抛一次异常出来？

其实大家按照正常的思维去想，都能知道如果子线程捕获了一次，future.get 方法就不应该抛出异常了。

所以，现在的问题是，这个小小的功能，在线程池里面是怎么实现的？

现在的面试题在原来的基础上再加一层：

好，你说当执行方法是 submit 的时候，如果子线程抛出未经捕获的运行时异常，将会被封装到 Future 里面？那么如果子线程捕获了异常，该异常还会封装到 Future 里面吗？是怎么实现的呢？

寻找答案-FUTURE

来，一起去源码里面寻找答案。

现在是用 submit 的方式往线程池里面提交任务，而执行的这个任务会抛出运行时异常。

对于抛出的这个异常，我们分为两种情况：

子线程中捕获了异常，则调用返回的 future 的 get 方法，不会抛出异常。
子线程中没有捕获异常，则调用返回的 future 的 get 方法，会抛出异常。

两种情况都和 future.get 方法有关，那我们就从这个方法的源码入手。

这个 Future 是一个接口：

而这个接口有非常多的实现类。我们找哪个实现类呢？

就是下面这个实现类：

java.util.concurrent.FutureTask

至于是怎么找到它的，你慢慢往后看就知道了。

先看看 FutureTask 的 get 方法：

get 方法的逻辑很简单，首先判断当前状态是否已完成，如果不是，则进入等待，如果是，则进入 report 方法。

一进 get 方法，我们就看到了 state 这个东西，这是 FutureTask 里面一个非常重要的东西：

在 FutureTask 里面，一共有 7 种状态。这 7 种状态之间的流转关系已经在注释里面写清楚了。

状态之间只会按照这四个流程去流转。

所以，一目了然，一个任务的终态有四种：NORMAL、EXCEPTIONAL、CANCELLED、INTERRUPTED。

而我们主要关心 NORMAL、EXCEPTIONAL。

所以再回头看看 get 方法：

如果当前状态是小于 COMPLEING 的。

也就是当前状态只能是 NEW 或者 COMPLEING，总之就是任务还没有完成。所以进入 awaitDone 方法。这个方法不是本文关心的地方，接着往下看。

程序能往下走，说明当前的状态肯定是下面圈起来的状态中的某一个：

记住这几种状态，然后看这个 report 方法：

这个方法是干啥的？

注解说的很清楚了：对于已经完成了的 task，返回其结果或者抛出异常。

这里面的逻辑就很简单了，把 outcome 变量赋值给 x 。

然后判断当前状态，如果是 NORMAL，即 2，说明正常完成，直接返回 x。

如果是大于等于 CANCELLED，即大于等于 4 ，即这几种状态，就抛出 CancellationException。

剩下的情况就抛出 ExecutionException。

而这个“剩下的情况”是什么情况？

不就只剩下一个 EXCEPTIONAL 的情况了。

所以，经过前面的描述，我们可以总结一下。

当 FutureTask 的 status 为 NORMAL 时正常返回结果，当 status 为 EXCEPTIONAL 时抛出异常。

而当终态为 NORMAL 或者 EXCEPTIONAL 时，按照注释描述，状态的流程只能是这样的：

那么到底是不是这样的呢？

这就需要我们去线程池里面验证一下了。

寻找答案-线程池

先回答上一节的一个问题：我怎么知道是看 Future 这个接口的 FutureTask 这个实现类的：

submit 方法提交的时候把任务包裹了一层，就是用 FutureTask 包裹的：

可以看到，FutureTask 的构造方法里面默认了状态为 NEW。

然后直接在 runWorker 方法的 task.run 方法处打上断点：

这个 task 是一个 FutureTask，所以 run 方法其实是 FutureTask 的 run 方法。

跟着断点进去之后，就是 FutureTask 的 run 方法：

答案都藏在这个方法里面。

java.util.concurrent.FutureTask#run

标号为 ① 的地方是执行我们的任务，call 的就是示例代码里面的 sayHi 方法。

如果 sayHi 方法没有捕获运行时异常，则会在标号为 ② 的这个 catch 里面被捕获。然后执行标号为 ② 的这个代码。

如果 sayHi 方法捕获了运行时异常，则会进入标号为 ③ 的这个逻辑里面。

我们分别看一下标号为 ② 和 ③ 的逻辑：

首先，两个方法都是先进行一个 cas 的操作，把当前 FutureTask 的 status 字段从 NEW 修改为 COMPLETING 。

完成了状态流转的这一步：

注意这里，如果 cas 操作失败了，则不会进行任何操作。

cas 操作失败了，说明什么呢？

说明当前的状态是 CANCELLED 或者 INTERRUPTING 或者INTERRUPTED。

也就是这个任务被取消了或者被中断了。

那还设置结果干啥，没有任何卵用，对不对。

如果 cas 操作成功，接着往下看，可以看到虽然入参不一样了，但是都赋给了 outcome 变量，这个变量，在上一节的 report 方法出现过，还记得吗？能不能呼应上？

接下来就是状态接着往下流转。

set 方法表示正常结束，状态流转到 NORMAL。

setException 方法表示任务出现异常，状态流转到 EXCEPTIONAL。

所以经过 FutureTask 的 run 方法后，如果任务没有被中断或者取消，则会通过 setException 或者 set 方法完成状态的流转和 outcome 参数的设置：

而到底是调用 setException 方法还是 set 方法，取决于标号为 ① 的地方是否会抛出异常。

即取决于任务体是否会抛出异常。

假设 sayHi 方法是这样的，会抛出运行时异常：

而通过 submit 方法提交任务时写法分别如下：

如果是标号为 ① 的写法，则会进入 setException 方法。

如果是标号为 ② 的写法，则会进入 set 方法。

所以，你现在再回去看看这个题目：

当执行方法是 submit 的时候，如果子线程抛出未经捕获的运行时异常，将会被封装到 Future 里面，那么如果子线程捕获了异常，该异常还会封装到 Future 里面吗？是怎么实现的呢？

现在是不是很清晰了。

如果子线程捕获了异常，该异常不会被封装到 Future 里面。是通过 FutureTask 的 run 方法里面的 setException 和 set 方法实现的。在这两个方法里面完成了 FutureTask 里面的 outcome 变量的设置，同时完成了从 NEW 到 NORMAL 或者 EXCEPTIONAL 状态的流转。