当前位置: 主页 > JAVA语言

java 线程队列-Java中的线程池的自我介绍(ThreadPoolExecutor)

发布时间:2023-06-14 16:04   浏览次数:次   作者:佚名

线程池的自我介绍

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

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

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

corePoolSize

java 线程队列_ios 线程和队列_java 线程池 队列满了

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

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

public interface Executor {

void execute(Runnable command);

ios 线程和队列_java 线程池 队列满了_java 线程队列

}

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

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

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

ios 线程和队列_java 线程队列_java 线程池 队列满了

「线程池,这是我的一个任务,帮我执行一下吧」主线程摞下一句话后又走了,此时是 1 个核心线程在忙碌,一个核心线程空闲,可能很多人误以为这里既然有一个核心线程在空闲,那就把任务交给这个线程处理即可,不用再创建核心线程了,但实际上只要当前核心线程数少于当初设置的 corePoolSize,不管当前核心线程是否空闲,我依然会再创建一个核心线程,主要是为了保证核心线程尽快达到我们设置的数量,这样如果之后有很多任务涌进来,这些已创建好的核心线程就可以马上准备好处理这些任务了,不需要再经过创建线程这种耗时的操作了。

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

workQueue

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

ios 线程和队列_java 线程队列_java 线程池 队列满了

java 线程池 队列满了_java 线程队列_ios 线程和队列

聪明的你一定发现了,这就是典型的生产者-消费者模型,线程池中的线程只要不断循环去 workQueue 队列获取任务即可,为了避免 workQueue 为空线程一直轮询导致的 CPU 资源被占用的问题,这里的 workQueue 采用了阻塞队列,所谓阻塞是指,如果 workQueue 为空,则获取元素的线程会等待队列变为非空,一旦有新的任务入队列,会唤醒等待中的线程。

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

可是好景不长, JVM 老大向我反馈出现 OOM 问题了,一看问题我就明白了,原来是哪个新手程序员在创建我的时候,声明使用了无界队列,导致核心线程无法及时处理任务,而任务又源源不断地添加进了 workQueue 中(即生产任务速度远大于消费任务速度),导致 workQueue 越来越大,最终产生了 OOM!

java 线程队列_java 线程池 队列满了_ios 线程和队列

解决方式很简单,使用有界队列即可,这样当 workQueue 满时就无法添加任务了,不会导致 workQueue 无限增大导致 OOM。

画外音:所谓有界队列是指设定了固定大小的队列,当队列里的元素超过这个大小后就再也不能往这个队列里塞任务了,而无界队列由于没有设置固定大小 ,可以直接入队,直到溢出,容易造成 OOM,所以创建线程池时应该尽量使用有界队列

maximumPoolSize

将 workQueue 改用有界队列后,再也没出现过 OOM 了,不过由于主线程又源源不断地丢了一些耗时的任务过来,核心线程依然处理不过来,workQueue 很快又满了,这时我想起了另一个参数 maximumPoolSize,这个参数定义了我能创建的最大线程数,当其它线程要往队列塞任务,但发现 workQueue 满时,由于当前在我这的线程还未到达 maximumPoolSize(假设起初指定为 5),所以我又创建了线程来处理这个任务。

画外音: 在 workQueue 已满的条件下,如果当前线程池的线程数量 >= corePoolSize 且