我是一个线程池

线程池的自我介绍

我是一个线程池(ThreadPoolExecutor),我的主要工作是管理在我这的多个线程(Thread),让他们能并发地执行多个任务的同时,又不会造成很大的的系统开销,有人不明白,创建线程有啥开销呢,不是只要 new 一个 Thread 出来让它跑就行了吗,这里我要简单解释下:

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

  2. 每个 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。

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

有道无术,术可成;有术无道,止于术

欢迎大家关注Java之道公众号

好文章,我在看❤️

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 博客之星2020 设计师:CY__0809 返回首页