浅谈ThreadPoolExecutor的实现原理

日常业务中我们常使用Executors的newFixedThreadPool去实现线程池，其内部实际上是对ThreadPoolExecutor进行了包装。

一个任务通过execute(Runnable)方法被添加到线程池，任务必须是一个 Runnable类型的对象，任务的执行方法就是调用Runnable类型对象的run()方法。当一个任务通过execute(Runnable)方法欲添加到线程池时，会做一下几步：
1. 如果此时线程池中的数量小于corePoolSize，即使线程池中的线程都处于空闲状态，也要创建新的线程来处理被添加的任务。
2. 如果此时线程池中的数量大于等于corePoolSize，但是缓冲队列 workQueue未满，那么任务被放入缓冲队列。
3. 如果此时线程池中的数量大于corePoolSize，缓冲队列workQueue满，并且线程池中的数量小于maximumPoolSize，建新的线程来处理添加的任务。
4. 如果此时线程池中的数量大于corePoolSize，缓冲队列workQueue满，并且线程池中的数量等于maximumPoolSize，那么通过 handler所指定的策略来处理此任务。也就是处理任务的优先级为：核心线程corePoolSize、任务队列workQueue、最大线程maximumPoolSize，如果三者都满了，使用handler处理被拒绝的任务。
5. 当线程池中的线程数量大于corePoolSize时，如果某线程空闲时间超过keepAliveTime，线程将被终止。这样，线程池可以动态的调整池中的线程数。
 

对于上面的描述需要分析下：

1.线程池新建时（执行Executors.newFixedThreadPool(coreSize)），其内部线程数为0，第一次执行execute(Runnable)方法，且corePoolSize>=1时才会新建线程。

2.newFixedThreadPool的缓冲队列使用的是LinkedBlockingQueue，默认长度为Integer.MAX_VALUE，所以这就是为什么其参数只有一个coreSize，即maximumPoolSize=coreSize。

3.其内部记录线程数量是通过定义一个AtomicInteger的ctl变量来记录，对其所有操作都是使用compareAndSet进行cas操作。

4.线程保存的容器是HashSet<Worker>类型的workers变量，释放线程时调用HashSet的remove方法，算是等待gc时回收。

5.在Worker(implements Runnable)的runWorker(Worker w) 中有段条件while(task != null || (task = getTask()) != null)，线程会一直执行task任务，其中第一个表示开始绑定的Runnable（firstTask），后面的getTask()表示从队列workQueue里获取的Runnable。所以释放线程的实现并不是我之前想的搞个守护线程定时触发，而是通过阻塞队列的poll方法实现的（workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) ）。

---

以上为个人理解，若有错误敬请斧正。。