线程池是 Java 中用于提升程序执行效率的主要手段，也是并发编程中的核心实现技术，并且它也被广泛的应用在日常项目的开发之中。那问题来了，如果把线程池中的核心线程数设置为 0 时，线程池是如何执行的？

要回答这个问题，我们首先要了解在正常情况下，线程池的执行流程，也就是说当有一个任务来了之后，线程池是如何运行的？

1.线程池的执行流程

正常情况下（核心线程数不为 0 的情况下）线程池的执行流程如下：

判断核心线程数：先判断当前工作线程数是否大于核心线程数，如果结果为 false，则新建线程并执行任务。判断任务队列：如果大于核心线程数，则判断任务队列是否已满？如果结果为 false，则把任务添加到任务队列中等待线程执行。判断最大线程数：如果任务队列已满，则判断当前线程数量是否超过最大线程数？如果结果为 false，则新建线程执行此任务。判断是否要执行拒绝策略：如果超过最大线程数，则将执行线程池的拒绝策略。

如下图所示：

核心线程数 VS 最大线程数

核心线程数（corePoolSize）和最大线程数（maximumPoolSize）都是线程池中的两个重要参数，其中：

核心线程数定义了线程池中最小线程数量，即使这些线程处于空闲状态，也不会被销毁。最大线程数定义了线程池中允许的最大线程数量，最大线程数等于核心线程数 + 临时线程数，最大线程数主要是提供了一种机制来应对突发的高并发请求，当有大量任务的时候，可以创建线程数量的上线。

PS：在线程池的使用过程中，最大线程数必须大于等于核心线程数，否则程序执行会报错。

2.核心线程为0的执行流程

那么问题来了，按照线程池的正常执行流程来看，如果核心线程数为 0 的话，那么当任务来了之后会判断当前工作的线程数不大于核心线程数，那也就不会创建线程执行任务了，会将任务放到队列。

但这个结果又很滑稽，有任务来了线程池竟然不执行，而是先放到任务队列中，这好像有比较奇怪，这就好比你开了一个快递店，当有快递来了之后，你想的不是如何派送，而是直接把它丢到仓库一样滑稽，这会让等快递的人很着急，所以，我们需要验证一下线程池的执行是否如我们猜想的那般，验证代码如下：

// 线程池核心线程数设置为 0ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor( 0, 10, 1, TimeUnit.SECONDS, new ArrayBlockingQueue<>(10));// 给线程池添加任务threadPoolExecutor.execute(() -> { System.out.println("www.javacn.site");});

最终程序的执行结果如下：

咦，结果怎么不符合我们的预期呢？为什么任务来了之后，没有将任务放到任务队列而是直接执行了呢？

虽然程序执行结果符合正常逻辑，但又和我们了解的线程池执行理论相违背，这是什么原因呢？

查看线程池的执行源码

带着这个疑问，我们查看了线程池的执行源码发现，线程池的执行过程远比我们想想的复杂，线程池核心源码如下：

从上面源码可以看出，当我们将任务添加到队列的时候，线程池会判断工作的线程数是否为 0，也就是上面圈出来的那行代码，如果当前工作线程为 0 的话，会创建线程执行任务。哦，原来如此，这样，就能将理论和实践对应上了。

也就是说，当核心线程数为 0 时，当来了一个任务之后，会先将任务添加到任务队列，同时也会判断当前工作的线程数是否为 0，如果为 0，则会创建线程来执行线程池的任务，这就是正确的线程池执行流程，同时也是面试官想要的答案。

课后思考

如何实现线程池的监控？如何动态调整线程池的核心线程数呢？

本文已收录到我的面试小站 [www.javacn.site](https://www.javacn.site)，其中包含的内容有：Redis、JVM、并发、并发、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、设计模式、消息队列等模块。