共计 5520 个字符，预计需要花费 14 分钟才能阅读完成。
这是 why 的第 98 篇原创文章
前几天，有个敌人在微信上找我。他问：why 哥，在吗？
我说：产生肾么事了？
他啪的一下就提了一个问题啊，很快。
我粗心了，随便瞅了一眼，这题不是很简略吗？
后果没想到外面还暗藏着一篇文章。
故事，得从这个问题说起：
下面的图中的线程池配置是这样的：
ExecutorService executorService = new ThreadPoolExecutor(40, 80, 1, TimeUnit.MINUTES,
new LinkedBlockingQueue<>(100),
new DefaultThreadFactory("test"),
new ThreadPoolExecutor.DiscardPolicy());下面这个线程池外面的参数、执行流程啥的我就不再解释了。
毕竟我已经在《一人血书，想让 why 哥讲一下这道面试题。》这篇文章外面发过毒誓的，再说就是小王吧了：
下面的这个问题其实就是一个非常简单的八股文问题：
非核心线程在什么时候被回收？
如果通过 keepAliveTime 工夫后，超过外围线程数的线程还没有承受到新的工作，就会被回收。
标准答案，齐全没故障。
那么我当初带入一个简略的场景，为了简略直观，咱们把线程池相干的参数调整一下：
ExecutorService executorService = new ThreadPoolExecutor(2, 3, 30, TimeUnit.SECONDS,
new LinkedBlockingQueue<>(2),
new DefaultThreadFactory("test"),
new ThreadPoolExecutor.DiscardPolicy());那么问题来了：
- 这个线程最多能包容的工作是不是 5 个？
- 假如工作须要执行 1 秒钟，那么我间接循环外面提交 5 个工作到线程池，必定是在 1 秒钟之内提交实现，那么以后线程池的沉闷线程是不是就是 3 个？
- 如果接下来的 30 秒，没有工作提交过去。那么 30 秒之后，以后线程池的沉闷线程是不是就是 2 个？
下面这三个问题的答案都是必定的，如果你搞不明确为什么，那么我倡议你先连忙去补充一下线程池相干的知识点，上面的内容你强行看上来必定是一脸懵逼的。
接下来的问题是这样的：
- 如果以后线程池的沉闷线程是 3 个（2 个外围线程 + 1 个非核心线程），然而它们各自的工作都执行实现了，都处于 waiting 状态。而后我每隔 3 秒往线程池外面扔一个耗时 1 秒的工作。那么 30 秒之后，沉闷线程数是多少？
先说答案：还是 3 个。
从我集体失常的思维，是这样的：外围线程是闲暇的，每隔 3 秒扔一个耗时 1 秒的工作过去，所以仅须要一个外围线程就齐全解决的过去。
那么，30 秒内，超过外围线程的那一个线程始终处于期待状态，所以 30 秒之后，就被回收了。
然而下面仅仅是我的主观认为，而理论状况呢？
30 秒之后，超过外围线程的线程并不会被回收，沉闷线程还是 3 个。
到这里，如果你晓得是 3 个，且晓得为什么是 3 个，即理解为什么非核心线程并没有被回收，那么接下里的内容应该就是你曾经把握的了。
能够不看，拉到最初，点个赞，去忙本人的事件吧。
如果你不晓得，能够接着看，理解一下为什么是 3 个。
尽管我置信没有面试官会问这样的问题，然而对于你去了解线程池，是有帮忙的。
先上 Demo
基于我后面说的这个场景，码出代码如下：
public class ThreadTest {
@Test
public void test() throws InterruptedException {
ThreadPoolExecutor executorService = new ThreadPoolExecutor(2, 3, 30, TimeUnit.SECONDS,
new LinkedBlockingQueue<>(2), new DefaultThreadFactory("test"),
new ThreadPoolExecutor.DiscardPolicy());
// 每隔两秒打印线程池的信息
ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(1);
scheduledExecutorService.scheduleAtFixedRate(() -> {System.out.println("=====================================thread-pool-info:" + new Date() + "=====================================");
System.out.println("CorePoolSize:" + executorService.getCorePoolSize());
System.out.println("PoolSize:" + executorService.getPoolSize());
System.out.println("ActiveCount:" + executorService.getActiveCount());
System.out.println("KeepAliveTime:" + executorService.getKeepAliveTime(TimeUnit.SECONDS));
System.out.println("QueueSize:" + executorService.getQueue().size());
}, 0, 2, TimeUnit.SECONDS);
try {
// 同时提交 5 个工作, 模仿达到最大线程数
for (int i = 0; i < 5; i++) {executorService.execute(new Task());
}
} catch (Exception e) {e.printStackTrace();
}
// 休眠 10 秒，打印日志，察看线程池状态
Thread.sleep(10000);
// 每隔 3 秒提交一个工作
while (true) {Thread.sleep(3000);
executorService.submit(new Task());
}
}
static class Task implements Runnable {
@Override
public void run(){
try {Thread.sleep(1000);
} catch (InterruptedException e) {e.printStackTrace();
}
System.out.println(Thread.currentThread() + "- 执行工作");
}
}
}这份代码也是发问的哥们给我的，我做了微调，你间接粘进来就能跑起来。
show me code，no bb。这才是互相探讨的正确姿态。
这个程序的运行后果是这样的：
一共五个工作，线程池的运行状况是什么样的呢？
先看标号为 ① 的中央：
三个线程都在执行工作，而后 2 号线程和 1 号线程率先实现了工作，接着把队列外面的两个工作拿进去执行（标号为 ② 的中央）。
依照程序，接下来，每隔 3 秒就有一个耗时 1 秒的工作过去。而此时线程池外面的三个沉闷线程都是闲暇状态。
那么问题就来了：
该抉择哪个线程来执行这个工作呢？是随机选一个吗？
尽管接下来的程序还没有执行，然而基于后面的截图，我当初就能够通知你，接下来的工作，线程执行程序为：
- Thread[test-1-3,5,main]- 执行工作
- Thread[test-1-2,5,main]- 执行工作
- Thread[test-1-1,5,main]- 执行工作
- Thread[test-1-3,5,main]- 执行工作
- Thread[test-1-2,5,main]- 执行工作
- Thread[test-1-1,5,main]- 执行工作
- ……
即尽管线程都是闲暇的，然而当工作来的时候不是随机调用的，而是轮询。
因为是轮询，每三秒执行一次，所以非核心线程的闲暇工夫最多也就是 9 秒，不会超过 30 秒，所以始终不会被回收。
基于这个 Demo，咱们就从表象上答复了，为什么沉闷线程数始终为 3。
为什么是轮询？
咱们通过 Demo 验证了下面场景中，线程执行程序为轮询。
那么为什么呢？
这只是通过日志得出的表象呀，外部原理呢？对应的代码呢？
这一大节带大家看一下到底是怎么回事。
首先我看到这个表象的时候我就猜想：这三个线程必定是在某个中央被某个队列存起来了，基于此，能力实现轮询调用。
所以，我始终在找这个队列，始终没有找到对应的代码，我还有点焦急了。想着不会是在操作系统层面管制的吧？
起初我冷静下来，感觉不太可能。于是电光火石之间，我想到了，要不先 Dump 一下线程，看看它们都在干啥：
Dump 之后，这玩意我眼生啊，AQS 的期待队列啊。
依据堆栈信息，咱们能够定位到这里的源码：
java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#awaitNanos
看到这里的时候，我才一下豁然开朗了起来。
害，是本人想的太多了。
说穿了，这其实就是个生产者 - 消费者的问题啊。
三个线程就是三个消费者，当初没有工作须要解决，它们就等着生产者生产工作，而后告诉它们筹备生产。
因为本文只是带着你去找答案在源码的什么中央，不对源码进行解读。
所以我默认你是对 AQS 是有肯定的理解的。
能够看到 addConditionWaiter 办法其实就是在操作咱们要找的那个队列。学名叫做期待队列。
Debug 一下，看看队列外面的状况：
巧了嘛，这不是。程序刚好是：
- Thread[test-1-3,5,main]
- Thread[test-1-2,5,main]
- Thread[test-1-1,5,main]
消费者这边咱们大略摸清楚了，接着去看看生产者。
- java.util.concurrent.ThreadPoolExecutor#execute
线程池是在这里把工作放到队列外面去的。
而这个办法外面的源码是这样的：
其中 signalNotEmpty() 最终会走到 doSignal 办法，而该办法外面会调用 transferForSignal 办法。
这个办法外面会调用 LockSupport.unpark(node.thred) 办法，唤醒线程：
而唤醒的程序，就是期待队列外面的程序：
所以，当初你晓得当一个工作来了之后，这个工作该由线程池外面的哪个线程执行，这个不是随机的，也不是轻易来的。
是考究一个程序的。
什么程序呢？
Condition 外面的期待队列外面的程序。
什么，你不太懂 Condition？
那还不连忙去学？等着我给你讲呢？
原本我是想写一下的，起初发现《Java 并发编程的艺术》一书中的 5.6.2 大节曾经写的挺分明了，图文并茂。这部分内容其实也是面试的时候的高频考点，所以本人去看看就好了。
先欠着，欠着。
非核心线程怎么回收？
还是下面的例子，假如非核心线程就闲暇了超过 30 秒，那么它是怎么被回收的呢？
这个也是一个比拟热门的面试题。
这题没有什么浅近的中央，答案就藏在源码的这个中央：
- java.util.concurrent.ThreadPoolExecutor#getTask
当 timed 参数为 true 的时候，会执行 workQueue.poll(keepAliveTime,TimeUnit.NANOSECONDS) 办法。
而 timed 什么时候为 true 呢？
- boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;
allowCoreThreadTimeOut 默认为 false。
所以，就是看 wc > corePoolSize 条件，wc 是沉闷线程数。此时沉闷线程数为 3，大于外围线程数 2。
因而 timed 为 true。
也就是说，以后 workQueue 为空的时候，当初三个线程都阻塞 workQueue.poll 办法中。
而当指定工夫后，workQueue 还是为空，则返回为 null。
于是在 1077 行把 timeOut 批改为 true。
进入一下次循环，返回 null。
最终会执行到这个办法：
- java.util.concurrent.ThreadPoolExecutor#processWorkerExit
而这个办法外面会执行 remove 的操作。
于是线程就被回收了。
所以当超过指定工夫后，线程会被回收。
那么被回收的这个线程是外围线程还是非核心线程呢？
不晓得。
因为在线程池外面，外围线程和非核心线程仅仅是一个概念而已，其实拿着一个线程，咱们并不能晓得它是外围线程还是非核心线程。
这个中央就是一个证实，因为当工作线程多余外围线程数之后，所有的线程都在 poll，也就是说所有的线程都有可能被回收：
另外一个强有力的证实就是 addWorker 这里：
core 参数仅仅是管制取 corePoolSize 还是 maximumPoolSize。
所以，这个问题你说怎么答复：
JDK 辨别的形式就是不辨别。
那么咱们能够晓得吗？
能够，比方通过观察日志，后面的案例中，我就晓得这两个是外围线程，因为它们最先创立：
- Thread[test-1-1,5,main]- 执行工作
- Thread[test-1-2,5,main]- 执行工作
在程序外面怎么晓得呢？
目前是不晓得的，然而这个需要，加钱就能够实现。
本人扩大一下线程池嘛，给线程池外面的线程打个标还不是一件很简略的事件吗？
只是你想想，你辨别这玩意干啥，有没有可落地的需要？
毕竟，脱离需要谈实现。都是耍流氓。
最初说一句
满腹经纶，难免会有纰漏，如果你发现了谬误的中央，能够在后盾提出来，我对其加以批改。
感谢您的浏览，我保持原创，非常欢送并感谢您的关注。
