源码：版本JDK8
1. 起因
JDK线程池提供了一些核心参数，用于空闲maximum线程的销毁和空闲core线程的销毁。
参数信息.png
文章来源：线程池系列（1）—ThreadPoolExecutor线程池参数以及使用
2. 分析
在灯下黑？原来线程池是最典型生产消费者模式文章中，我们知道，线程池的工作线程本质是死循环去处理任务，而销毁工作线程的原理，即跳出循环。
工作线程会不断的去阻塞队列中拉取任务，此处有两个方法：
- poll：拉取任务（可能有等待时间），拉取不到（或超过等待时间）返回null；
- task：阻塞式的拉取任务，只要拉取不到，便一直阻塞；
- 具体走什么逻辑拉取任务：取决于timed参数。
- timed取决于：如果配置了allowCoreThreadTimeout参数，或者当前线程数大于核心线程数，则返回true，于是则使用poll方法获取参数。
获取task的方法.png
- 当拉取不到任务，将timeOut=true；
- 在下一次自旋时，会使得当前工作线程数-1，并且返回null；
工作线程自旋拉取任务.png
- 不满足自旋条件，将completedAbruptly设置为true；
- 调用
processWorkerExit方法去真正销毁自己，但此时，不一定真正被销毁；
private void processWorkerExit(Worker w, boolean completedAbruptly) {
if (completedAbruptly) // If abrupt, then workerCount wasn't adjusted
decrementWorkerCount();
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
completedTaskCount += w.completedTasks;
workers.remove(w);
} finally {
mainLock.unlock();
}
tryTerminate();
int c = ctl.get();
if (runStateLessThan(c, STOP)) {
if (!completedAbruptly) {
//若允许销毁空闲的核心线程，则允许剩余的线程数为0
int min = allowCoreThreadTimeOut ? 0 : corePoolSize;
//在销毁过程中，发现阻塞队列有任务，则允许剩余的线程数为1
if (min == 0 && ! workQueue.isEmpty())
min = 1;
//销毁过程中，工作线程数必须大于等于最小线程数，才允许销毁自己。
if (workerCountOf(c) >= min)
//分支1：结束流程，工作线程被销毁
return; // replacement not needed
}
//分支2：继续while循环去处理任务（该工作线程未被销毁）
addWorker(null, false);
}
}
- 若在销毁的流程中，发现阻塞队列中有任务需要被执行，但是该线程为最后一个线程时，会执行到分支2，再去开启while循环。
3. 总结
线程池销毁核心线程，依赖的API是queue的poll。当在keepAliveTime时间内拉取不到任务，则会中断工作线程的while循环，开始销毁任务。但是最终是否要销毁线程，还取决于阻塞队列中是否为空。
想想一个场景：线程池：只有一个核心线程。
- 当任务进来时，发现当前线程数=核心线程数，于是将任务放入到queue中；
- 但是任务放入queue的前一刻，工作线程通过getTask()在keepAliveTime时间内未拉取到任务，触发销毁工作线程的方法；
- 若
processWorkerExit中没有进一步校验，直接去销毁方法，会导致任务进入阻塞队列，但是没有工作线程去执行改任务，产生bug；
系列文章
线程池系列（1）ThreadPoolExecutor线程池参数以及使用
线程池系列（2） ThreadPoolExecutor的实现原理（源码分析）
