vlambda博客
学习文章列表

一、线程池的自我介绍

你好呀，我是沉默王二，不不不，我是一个线程池（ThreadPoolExecutor），我的主要工作是管理在我这个池子里的多个线程（Thread），让他们能并发地执行多个任务的同时，不造成很大的的系统开销。有同学就不明白了，创建线程有啥开销呢，不是只要 new 一个 Thread 出来让它跑就行了吗？

这里我要简单解释下。

1. 其实 Java 中的线程模型是基于操作系统原生线程模型实现的，也就是说 Java 中的线程其实是基于内核线程实现的，线程的创建，析构与同步都需要进行系统调用，而系统调用需要在用户态与内核中来回切换，代价相对较高，线程的生命周期包括「线程创建时间」,「线程执行任务时间」,「线程销毁时间」，创建和销毁都需要导致系统调用。

2. 每个 Thread 都需要有一个内核线程的支持，也就意味着每个 Thread 都需要消耗一定的内核资源（如内核线程的栈空间），因为能创建的 Thread 是有限的，默认一个线程的线程栈大小是 1 M，如果每来一个任务就创建一个线程的话，1024 个任务就会创建 1024 个线程，就会占用 1 个 G 的内存，很容易就系统崩溃了。

二、corePoolSize

所以我的主要作用就是减少线程的创建时间和销毁时间，线程创建后不让它马上销毁，而是常驻在我这，随叫随到，我把这些常驻的线程叫做核心线程，核心线程数也不宜过多，所以我指定了它们的数量（corePoolSize），假定为 3 吧。

「线程池，这是我的一个任务，帮我执行一下吧」，主线程丢给我任务后立马返回，于是我赶紧调用 execute 方法来处理丢给我的这个任务（Runnable）

public interface Executor {
    void execute(Runnable command);
}

由于我诞生后还没有执行过任务，核心线程一直为 0，于是在这个方法里我创建了一个线程作为核心线程。

「线程池，任务又来了，帮我执行一下吧」，又来任务了！于是我再次调用 execute，又创建了一个核心线程，此时核心线程数为 2。

过了一段时间，第一个核心线程已经执行完任务，空闲出来了，此时任务又来了。。。

「线程池，这是我的一个任务，帮我执行一下吧」主线程摞下一句话后又走了，此时是一个核心线程在忙碌，一个核心线程空闲，可能很多人误以为这里既然有一个核心线程在空闲，那就把任务交给这个线程处理即可，不用再创建核心线程了。

但实际上只要当前核心线程数少于当初设置的 corePoolSize，不管当前核心线程是否空闲，我依然会再创建一个核心线程，主要是为了保证核心线程尽快达到我们设置的数量，这样如果之后有很多任务涌进来，这些已创建好的核心线程就可以马上做好准备处理这些任务了，不需要再创建新的线程，节省了很多时间。

经过上面的一番操作，核心线程数来到了最开始设置的数量 3 了。

三、workQueue

「线程池，任务又来了，帮我执行一下吧」，熟悉的声音又来了，此时核心线程已经达到了我们设置的数量 3 个了，再创建线程当然可以，但又要造成新的系统开销。与其这样，不如等等，因为核心线程可能经过很短的时间就能空闲出来了，不如把任务放到放到一个队列里，让这些核心线程自己去取。

聪明的你一定发现了，这就是典型的生产者-消费者模型，线程池中的线程只要不断循环去 workQueue 队列获取任务即可。

为了避免 workQueue 为空线程一直轮询导致的  CPU 资源被占用的问题，这里的 workQueue 采用了阻塞队列。所谓的阻塞是指，如果 workQueue 为空，则获取元素的线程会等待队列变为非空，一旦有新的任务入队列，就唤醒等待中的线程。

画外音：线程等待是指调用  LockSupport.park 将线程从运行态变为阻塞态，此时线程就不占用 CPU 资源了。

可是好景不长， JVM 老大向我反馈，他说出现 OOM（Out Of Memory）问题了。看见这个问题我就明白了，肯定是哪个新手程序员在创建我的时候，使用了无界队列，导致核心线程无法及时处理任务，而任务又源源不断地添加进了 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。

画外音：线程池里没有核心线程和额外线程之分，只是为了讲述方便，人为划分了一下，但其实线程池里的线程都是平等的，任何一个线程都可能被干掉。

七、总结

通过我幽默风趣的自我介绍，我相信你已经对我（线程池）的工作机制有了基本了解，但这还不够，本文的介绍只是了解了我的一个皮毛而已，要全面地掌握，最好是对我的源码进行深度的剖析，你要不要试一试啊？

PS：昨天心情好，送了五本书，好多小伙伴都踊跃地参与了，我数了 2 个多小时（眼睛要废了），有 312 个人参与。我只能说，真的是“僧多肉少”啊！下面公布中奖名单，错过的不要着急，等下一轮。

1：籁知、50：呾唔罢去、100：给时间一点时间、150：小W&小L、200：嘻嘻

掐指一算， 最近差不多送出去 100 本书了，很多小伙伴都说，从来没中奖过，在我这竟然中了，谁叫我是你们最爱的二哥呢？第一次都让我来！嘿嘿。