点击上方蓝色“方志朋”，选择“设为星标”
回复“666”获取独家整理的学习资料！
线程池的自我介绍
我是一个线程池（ThreadPoolExecutor），我的主要工作是管理在我这的多个线程（Thread），让他们能并发地执行多个任务的同时，又不会造成很大的的系统开销，有人不明白，创建线程有啥开销呢，不是只要 new 一个 Thread 出来让它跑就行了吗，这里我要简单解释下：
其实 Java 中的线程模型是基于操作系统原生线程模型实现的，也就是说 Java 中的线程其实是基于内核线程实现的，线程的创建，析构与同步都需要进行系统调用，而系统调用需要在用户态与内核中来回切换，代价相对较高，线程的生命周期包括「线程创建时间」,「线程执行任务时间」,「线程销毁时间」，创建和销毁都需要导致系统调用。
每个 Thread 都需要有一个内核线程的支持，也就意味着每个 Thread 都需要消耗一定的内核资源（如内核线程的栈空间），因为能创建的 Thread 是有限的，默认一个线程的线程栈大小是 1 M，如果每来一个任务就创建线程的话，1024 个任务就光创建线程就占用了 1 G 内存，很容易就系统崩溃了。
corePoolSize
所以我的主要作用就是减少线程的创建时间和销毁时间，线程创建后不让它马上销毁，而是常驻在我这，随叫随到，我把这些常驻的线程叫做核心线程，核心线程数也不宜过多，所以我指定了它们的数量（corePoolSize），假定为 3 吧。
「线程池，这是我的一个任务，帮我执行一下吧」，主线程丢给我任务后立马返回，于是我赶紧调用 execute 方法来处理丢给我的这个任务（Runnable）
public interface Executor {void execute(Runnable command);
}
由于我诞生后还没有执行过任务，核心线程一直为 0，于是在这个方法里我创建了一个线程作为核心线程。
「线程池，任务又来了，帮我执行一下吧」，又来任务了！于是我再次调用了 execute，又创建了一个核心线程，此时核心线程数为 2。
过了一段时间，第一个核心线程已经执行完任务，空闲出来了，此时任务又来了。。。
「线程池，这是我的一个任务，帮我执行一下吧」主线程摞下一句话后又走了，此时是 1 个核心线程在忙碌，一个核心线程空闲，可能很多人误以为这里既然有一个核心线程在空闲，那就把任务交给这个线程处理即可，不用再创建核心线程了，但实际上只要当前核心线程数少于当初设置的 corePoolSize，不管当前核心线程是否空闲，我依然会再创建一个核心线程，主要是为了保证核心线程尽快达到我们设置的数量，这样如果之后有很多任务涌进来，这些已创建好的核心线程就可以马上准备好处理这些任务了，不需要再经过创建线程这种耗时的操作了。
经过上面的一番操作，核心线程数来到了最开始设置的数量 3 了。
workQueue
「线程池，任务又来了，帮我执行一下吧」，熟悉的声音又来了，此时核心线程已经达到了我们设置的数量 3 个了，再创建线程当然可以，但又要造成一个系统调用，开销比较大，其实核心线程可能经过很短的时间又能马上空闲出来了，不如把任务放到放到一个队列里，让这些核心线程自己去取。
聪明的你一定发现了，这就是典型的生产者-消费者模型，线程池中的线程只要不断循环去 workQueue 队列获取任务即可，为了避免 workQueue 为空线程一直轮询导致的 CPU 资源被占用的问题，这里的 workQueue 采用了阻塞队列，所谓阻塞是指，如果 workQueue 为空，则获取元素的线程会等待队列变为非空，一旦有新的任务入队列，会唤醒等待中的线程。
画外音：线程等待是指调用 LockSupport.park 将线程从运行态变为阻塞态，此时线程就不占用 CPU 资源了
可是好景不长， JVM 老大向我反馈出现 OOM 问题了，一看问题我就明白了，原来是哪个新手程序员在创建我的时候，声明使用了无界队列，导致核心线程无法及时处理任务，而任务又源源不断地添加进了 workQueue 中（即生产任务速度远大于消费任务速度），导致 workQueue 越来越大，最终产生了 OOM！
解决方式很简单，使用有界队列即可，这样当 workQueue 满时就无法添加任务了，不会导致 workQueue 无限增大导致 OOM。
画外音：所谓有界队列是指设定了固定大小的队列，当队列里的元素超过这个大小后就再也不能往这个队列里塞任务了，而无界队列由于没有设置固定大小 ，可以直接入队，直到溢出，容易造成 OOM，所以创建线程池时应该尽量使用有界队列
maximumPoolSize
将 workQueue 改用有界队列后，再也没出现过 OOM 了，不过由于主线程又源源不断地丢了一些耗时的任务过来，核心线程依然处理不过来，workQueue 很快又满了，这时我想起了另一个参数 maximumPoolSize，这个参数定义了我能创建的最大线程数，当其它线程要往队列塞任务，但发现 workQueue 满时，由于当前在我这的线程还未到达 maximumPoolSize（假设起初指定为 5），所以我又创建了线程来处理这个任务。
画外音: 在 workQueue 已满的条件下，如果当前线程池的线程数量 >= corePoolSize 且 <= maximumPoolSize，后续如果一直有其它线程丢任务进来，会一直创建线程，直到 maximumPoolSize。
RejectedExecutionHandler
某天，往我这丢任务的某个线程反馈收到异常了，我一看，我靠，workQueue 满了，线程数也达到了 maximumPoolSize，但此时依然有任务不断往 workQueue 中插，但这种情况下已经超出了我的处理能力了，只好执行默认的拒绝策略，抛出 RejectedExecutionException 异常让其他线程（往我这丢任务的线程）自己处理。
画外音：线程池提供了 AbortPolicy，DiscardPolicy，DiscardOldestPolicy，CallerRunsPolicy，自定义这五种拒绝策略，默认是 AbortPolicy
keepAliveTime
在线程们的努力之下，workQueue 队列中的任务很快被清空了，很长一段时间都没有任务进来了，线程们很快就无事可做，放着又占用资源，该怎么处理呢？此时我这有核心线程 3（corePoolSize = 3）， 额外线程 2 （maximumPoolSize 为 5），
我是这么处理的，如果当前线程总数超过了 corePoolSize，在 keepAliveTime 这个时间内，如果池子里的线程一直空闲，就把这个线程给干掉，哪个线程空闲时间先到达 keepAliveTime，就干掉哪个，直到线程数减少到 corePoolSize。
画外音：线程池里没有核心线程和额外线程之分，只是为了讲述方便人为划分了一下，但其实线程池里的线程都是平等的，任何一个线程都可以被干掉
总结
通过上文的自我介绍，我相信你已经对我的工作机制有了基本了解，但这还不够，本文的介绍只是了解了我的一个皮毛而已，要全面地掌握最好是对我的源码进行深度剖析。
热门内容：
Redis 分布式锁使用不当，酿成一个重大事故，超卖了100瓶飞天茅台！！！
服务被干爆了！竟然是日志的锅！！
扔掉okhttp、httpClient，来试试这款轻量级HTTP客户端神器？
最近面试BAT，整理一份面试资料《Java面试BAT通关手册》，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。
明天见(｡･ω･｡)ﾉ♡
