面试官：线程池如何按照core、max、queue的执行循序去执行？（内附详细解析）

前言

这是一个真实的面试题。

前几天一个朋友在群里分享了他刚刚面试候选者时问的问题："线程池如何按照core、max、queue的执行循序去执行？"。

我们都知道线程池中代码执行顺序是：corePool->workQueue->maxPool，源码我都看过，你现在问题让我改源码？？

一时间群里炸开了锅，小伙伴们纷纷打听他所在的公司，然后拉黑避坑。(手动狗头，大家一起调侃٩(๑❛ᴗ❛๑)۶)

关于线程池他一共问了这么几个问题：

  • 线程池如何按照core、max、queue的顺序去执行？
  • 子线程抛出的异常，主线程能感知到么？
  • 线程池发生了异常改怎样处理？

全是一些有意思的问题，我之前也写过一篇很详细的图文教程：【万字图文-原创】 | 学会Java中的线程池，这一篇也许就够了！ ，不了解的小伙伴可以再回顾下~

但是针对这几个问题，可能大家一时间也有点懵。今天的文章我们以源码为基础来分析下该如何回答这三个问题。（之前没阅读过源码也没关系，所有的分析都会贴出源码及图解）

线程池如何按照core、max、queue的顺序执行？

问题思考

对于这个问题，很多小伙伴肯定会疑惑："别人源码中写好的执行流程你为啥要改？这面试官脑子有病吧......"

这里来思考一下现实工作场景中是否有这种需求？之前也看到过一份简历也写到过这个问题：

场景描述.png

一个线程池执行的任务属于IO密集型，CPU大多属于闲置状态，系统资源未充分利用。如果一瞬间来了大量请求，如果线程池数量大于coreSize时，多余的请求都会放入到等待队列中。等待着corePool中的线程执行完成后再来执行等待队列中的任务。

试想一下，这种场景我们该如何优化？

我们可以修改线程池的执行顺序为corePool->maxPool->workQueue。 这样就能够充分利用CPU资源，提交的任务会被优先执行。当线程池中线程数量大于maxSize时才会将任务放入等待队列中。

你就说巧不巧？面试官的这个问题显然是经过认真思考来提问的，这是一个很有意思的温恩提，下面就一起看看如何解决吧。

线程池运行流程

我们都知道线程池执行流程是先corePool再workQueue，最后才是maxPool的一个执行流程。

执行流程.png

线程池核心参数

在回顾下ThreadPoolExecutor.execute()源码前我们先回顾下线程池中的几个重要参数：

线程池核心参数.png

我们来看下这几个参数的定义：
corePoolSize: 线程池中核心线程数量
maximumPoolSize: 线程池中最大线程数量
keepAliveTime: 非核心的空闲线程等待新任务的时间
unit: 时间单位。配合allowCoreThreadTimeOut也会清理核心线程池中的线程。
workQueue: 基于Blocking的任务队列，最好选用有界队列，指定队列长度
threadFactory: 线程工厂，最好自定义线程工厂，可以自定义每个线程的名称
handler: 拒绝策略，默认是AbortPolicy

ThreadPoolExecutor.execute()源码分析

我们可以看下execute()如下：

execute执行源码.png

接着来分析下执行过程：

  1. 第一步：workerCountOf(c)时间计算当前线程池中线程的个数，当线程个数小于核心线程数
  2. 第二步：线程池线程数量大于核心线程数，此时提交的任务会放入workQueue中，使用offer()进行操作
  3. 第三步：workQueue.offer()执行失败，新提交的任务会直接执行，addWorker()会判断如果当前线程池数量大于最大线程数，则执行拒绝策略

好了，到了这里我们都已经很清楚了，关键在于第二步和第三步如何交换顺序执行呢？

解决思路

仔细想一想，如果修改workQueue.offer()的实现不就可以达到目的了？我们先来画图来看一下：

问题思路.png

现在的问题就在于，如果当前线程池中coreSize < workCount < maxSize时，一定会先执行offer()操作。

我们如果修改offer的实现是否可以完成执行顺序的更换呢？这里也是画图来展示一下：

解决方式.png

Dubbo中EagerThreadPool解决方案

凑巧Dubbo中也有类似的实现，在Dubbo的EagerThreadPool自定义了一个BlockingQueue，在offer()方法中，如果当前线程池数量小于最大线程池时，直接返回false，这里就达到了调节线程池执行顺序的目的。

dubbo中解决方案.png

源码直达：https://github.com/apache/dubbo/blob/master/dubbo-common/src/main/java/org/apache/dubbo/common/threadpool/support/eager/TaskQueue.java

看到这里一切都真相大白了，解决思路以及方案都很简单，学会了没有？

这个问题背后还隐藏了一些场景的优化、源码的扩展等等知识，果然是一个值得思考的好问题。

子线程抛出的异常，主线程能感知到么？

问题思考

这个问题其实也很容易回答，也仅仅是一个面试题而已，实际工作中子线程的异常不应该由主线程来捕获。

针对这个问题，希望大家清楚的是： 我们要明确线程代码的边界，异步化过程中，子线程抛出的异常应该由子线程自己去处理，而不是需要主线程感知来协助处理。

解决方案

解决方案很简单，在虚拟机中，当一个线程如果没有显式处理异常而抛出时会将该异常事件报告给该线程对象的 java.lang.Thread.UncaughtExceptionHandler 进行处理，如果线程没有设置 UncaughtExceptionHandler，则默认会把异常栈信息输出到终端而使程序直接崩溃。

所以如果我们想在线程意外崩溃时做一些处理就可以通过实现 UncaughtExceptionHandler 来满足需求。

我们使用线程池设置ThreadFactory时可以指定UncaughtExceptionHandler，这样就可以捕获到子线程抛出的异常了。

代码示例

具体代码如下：

/**
 * 测试子线程异常问题
 *
 * @author wangmeng
 * @date 2020/6/13 18:08
 */
public class ThreadPoolExceptionTest {

    public static void main(String[] args) throws InterruptedException {
        MyHandler myHandler = new MyHandler();
        ExecutorService execute = new ThreadPoolExecutor(10, 10,
                0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>(), new ThreadFactoryBuilder().setUncaughtExceptionHandler(myHandler).build());

        TimeUnit.SECONDS.sleep(5);
        for (int i = 0; i < 10; i++) {
            execute.execute(new MyRunner());
        }
    }


    private static class MyRunner implements Runnable {
        @Override
        public void run() {
            int count = 0;
            while (true) {
                count++;
                System.out.println("我要开始生产Bug了============");
                if (count == 10) {
                    System.out.println(1 / 0);
                }

                if (count == 20) {
                    System.out.println("这里是不会执行到的==========");
                    break;
                }
            }
        }
    }
}

class MyHandler implements Thread.UncaughtExceptionHandler {
    private final static Logger LOGGER = LoggerFactory.getLogger(MyHandler.class);
    @Override
    public void uncaughtException(Thread t, Throwable e) {
        LOGGER.error("threadId = {}, threadName = {}, ex = {}", t.getId(), t.getName(), e.getMessage());
    }
}

执行结果：


执行结果.png

UncaughtExceptionHandler 解析

我们来看下Thread中的内部接口UncaughtExceptionHandler：

public class Thread {
    ......
    /**
     * 当一个线程因未捕获的异常而即将终止时虚拟机将使用 Thread.getUncaughtExceptionHandler()
     * 获取已经设置的 UncaughtExceptionHandler 实例，并通过调用其 uncaughtException(...) 方
     * 法而传递相关异常信息。
     * 如果一个线程没有明确设置其 UncaughtExceptionHandler，则将其 ThreadGroup 对象作为其
     * handler，如果 ThreadGroup 对象对异常没有什么特殊的要求，则 ThreadGroup 会将调用转发给
     * 默认的未捕获异常处理器（即 Thread 类中定义的静态未捕获异常处理器对象）。
     *
     * @see #setDefaultUncaughtExceptionHandler
     * @see #setUncaughtExceptionHandler
     * @see ThreadGroup#uncaughtException
     */
    @FunctionalInterface
    public interface UncaughtExceptionHandler {
        /**
         * 未捕获异常崩溃时回调此方法
         */
        void uncaughtException(Thread t, Throwable e);
    }

    /**
     * 静态方法，用于设置一个默认的全局异常处理器。
     */
    public static void setDefaultUncaughtExceptionHandler(UncaughtExceptionHandler eh) {
         defaultUncaughtExceptionHandler = eh;
     }

    /**
     * 针对某个 Thread 对象的方法，用于对特定的线程进行未捕获的异常处理。
     */
    public void setUncaughtExceptionHandler(UncaughtExceptionHandler eh) {
        checkAccess();
        uncaughtExceptionHandler = eh;
    }

    /**
     * 当 Thread 崩溃时会调用该方法获取当前线程的 handler，获取不到就会调用 group（handler 类型）。
     * group 是 Thread 类的 ThreadGroup 类型属性，在 Thread 构造中实例化。
     */
    public UncaughtExceptionHandler getUncaughtExceptionHandler() {
        return uncaughtExceptionHandler != null ?
            uncaughtExceptionHandler : group;
    }

    /**
     * 线程全局默认 handler。
     */
    public static UncaughtExceptionHandler getDefaultUncaughtExceptionHandler() {
        return defaultUncaughtExceptionHandler;
    }
    ......
}

部分内容参考自：https://mp.weixin.qq.com/s/ghnNQnpou6-NemhFjpl4Jg

线程池发生了异常改怎样处理？

线程池中线程运行过程中出现了异常该怎样处理呢？线程池提交任务有两种方式，分别是execute()和submit()，这里会依次说明。

ThreadPoolExecutor.runWorker()实现

不管是使用execute()还是submit()提交任务，最终都会执行到ThreadPoolExecutor.runWorker()，我们来看下源码（源码基于JDK1.8）：

runWorker().png

我们看到在执行task.run()时，出现异常会直接向上抛出，这里处理的最好的方式就是在我们业务代码中使用try...catch()来捕获异常。

FutureTask.run()实现

如果我们使用submit()来提交任务，在ThreadPoolExecutor.runWorker()方法执行时最终会调用到FutureTask.run()方法里面去，不清楚的小伙伴也可以看下我之前的文章：

线程池续：你必须要知道的线程池submit()实现原理之FutureTask！

FutureTask.run().png

这里可以看到，如果业务代码抛出异常后，会被catch捕获到，然后调用setExeception()方法：

FutureTask.setException().png

可以看到其实类似于直接吞掉了，当我们调用get()方法的时候异常信息会包装到FutureTask内部的变量outcome中，我们也会获取到对应的异常信息。

在ThreadPoolExecutor.runWorker()最后finally中有一个afterExecute()钩子方法，如果我们重写了afterExecute()方法，就可以获取到子线程抛出的具体异常信息Throwable了。

结论

对于线程池、包括线程的异常处理推荐以下方式:

  1. 直接使用try/catch，这个也是最推荐的方式
  2. 在我们构造线程池的时候，重写uncaughtException()方法，上面示例代码也有提到：
public class ThreadPoolExceptionTest {

    public static void main(String[] args) throws InterruptedException {
        MyHandler myHandler = new MyHandler();
        ExecutorService execute = new ThreadPoolExecutor(10, 10,
                0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>(), new ThreadFactoryBuilder().setUncaughtExceptionHandler(myHandler).build());

        TimeUnit.SECONDS.sleep(5);
        for (int i = 0; i < 10; i++) {
            execute.execute(new MyRunner());
        }
    }
}

class MyHandler implements Thread.UncaughtExceptionHandler {
    private final static Logger LOGGER = LoggerFactory.getLogger(MyHandler.class);
    @Override
    public void uncaughtException(Thread t, Throwable e) {
        LOGGER.error("threadId = {}, threadName = {}, ex = {}", t.getId(), t.getName(), e.getMessage());
    }
}

3 直接重写afterExecute()方法，感知异常细节

总结

这篇文章到这里就结束了，不知道小伙伴们有没有一些感悟或收获？

通过这几个面试问题，我也深刻的感受到学习知识要多思考，看源码的过程中要多设置一些场景，这样才会收获更多。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 194,457评论 5赞 459
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 81,837评论 2赞 371
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 141,696评论 0赞 319
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 52,183评论 1赞 263
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 61,057评论 4赞 355
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 46,105评论 1赞 272
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 36,520评论 3赞 381
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 35,211评论 0赞 253
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 39,482评论 1赞 290
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,574评论 2赞 309
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,353评论 1赞 326
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 32,213评论 3赞 312
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 37,576评论 3赞 298
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,897评论 0赞 17
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,174评论 1赞 250
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 41,489评论 2赞 341
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 40,683评论 2赞 335