由于工作中基本都是CRUD操作，对线程池不常用，所以一直没去具体了解过其底层原理，但是在工作、健身之余一直有一颗躁动的心，想在技术上浸淫的更深入一点（其实lz就是想技术好点，工资高点），所以这几天就查看了线程池的底层源码。另外开个公众号记录一下笔记，练练文笔，岂不美哉！
话不多说，开始！
目前Java线程池的创建JUC提供了四种方便的快捷方法，利用Executors工具类直接创建，如下图
方便快捷，那为什么还要研究底层呢？（之后说明）
然而它们的底层实现又是什么，线程池又是怎么进行扩容的呢？稍等，一一说明。
先来看下底层实现
可以看到，底层都是有ThreadPoolExecutor类实现的和阻塞队列实现的，而且Executors.newScheduledThreadPool()一直点下去也是ThreadPoolExecutor类。
接下来查看一下ThreadPoolExecutor类，其底层究竟是什么？七大参数又是什么？
七个参数，分别是corePoolSize，maximumPoolSize，keepAliveTime，unit，workQueue，threadFactory和handler。
（1）corePoolSize：就是线程池中的常驻核心线程数。
（2）maximumPoolSize：线程池能容纳同时执行的最大线程数。
（3）keepAliveTime：空闲线程的最大存活时间。
（4）unit：keepAliveTime参数的时间单位
（5）workQueue：任务队列，被提交但是尚未被执行的任务将存放在此。
（6）threadFactory：生成线程池中工作线程的工厂。
（7）handler：拒绝策略，当任务队列已满并且当前工作线程数量等于maximumPoolSize执行的策略。
线程池工作流程：
1.创建线程池
2.提交任务，线程池会进行判断
（1）如果正在运行的线程数量小于corePoolSize，则新建一个线程执行任务
（2）如果正在运行的线程数量等于corePoolSize，则任务进入等待队列
（3）如果正在运行的线程数量大于等于corePoolSize并且小于maximumPoolSize，则会进行扩容，新建一个线程执行任务。
（4）如果队列已满并且正在运行的线程数量等于maximumPoolSize，则会执行拒绝策略。
3.如果当前运行的线程数量大于corePoolSize，并且有部分线程在keepAliveTime时间内无事可做，就会执行线程销毁，直至线程数量等于corePoolSize为止。
可能上述解释有点抽象，下面就是一个比喻，一看就明：
银行网点大家都知道，通常营业的时候会有几个正在服务的窗口，也会有几个停止服务的窗口（就是没有漂亮小姐姐的那种，懂了吧！），也会有侯客区（几排冷冰冰的铁椅），银行网点就是线程池，而正在值班的窗口就是corePoolSize，全部窗口数量就是maximumPoolSize，侯客区就是任务队列。去银行办理业务一般是如下流程，如果正在值班的窗口有空闲的，就马上办理业务，如果值班窗口都在办理业务，则进入侯客区进行等待。如果值班窗口都在办理业务并且侯客区已满，银行就会进行将停止服务的窗口开通（称为“加班窗口”）。如果全部窗口都在办理业务，侯客区已满，大堂经理就会进行拒绝客户的操作，这就是拒绝策略。如果办业务人数持续减少，如果加班窗口已经不办业务了，过了一段时间（也即是keepAliveTime）之后就会将加班窗口撤掉，直到所有加班窗口都被撤掉。
那什么又是拒绝策略呢？
JUC包提供了四种拒绝策略，分别是
（1）AbortPolicy：默认的拒绝策略，会直接抛异常
例如我手写了一个线程池，corePoolSize是2，maximumPoolSize是5，任务队列容量为3，那么线程池最多可以同时提交8个任务。但我提交了10个任务。所以直接抛异常。
（2）CallerRunsPolicy：调用者策略，将任务返回给调用者，利用调用者线程执行提交给线程池中的任务。
直接返回给main线程执行。
（3）DiscardOldestPolicy：将队列中等待时间最长的任务直接扔掉
（4）DiscardPolicy：直接扔掉线程
OK，上述就是我理解的线程池（仅作为笔记记录），如果有不同见解的，欢迎指正。
为什么不建议直接用JUC提供的Executors工具类直接创建线程池呢，因为用这个工具类直接创建的话底层的阻塞队列容量是Integer.MAX_VALUE，在高并发的时候容易任务堆积，造成OOM的情况。
