21 Java并发类库提供的线程池有哪几种? 分别有什么特点?

我在[专栏第17讲]中介绍过线程是不能够重复启动的,创建或销毁线程存在一定的开销,所以利用线程池技术来提高系统资源利用效率,并简化线程管理,已经是非常成熟的选择。

今天我要问你的问题是,Java并发类库提供的线程池有哪几种? 分别有什么特点?

典型回答

通常开发者都是利用Executors提供的通用线程池创建方法,去创建不同配置的线程池,主要区别在于不同的ExecutorService类型或者不同的初始参数。

Executors目前提供了5种不同的线程池创建配置:

考点分析

Java并发包中的Executor框架无疑是并发编程中的重点,今天的题目考察的是对几种标准线程池的了解,我提供的是一个针对最常见的应用方式的回答。

在大多数应用场景下,使用Executors提供的5个静态工厂方法就足够了,但是仍然可能需要直接利用ThreadPoolExecutor等构造函数创建,这就要求你对线程构造方式有进一步的了解,你需要明白线程池的设计和结构。

另外,线程池这个定义就是个容易让人误解的术语,因为ExecutorService除了通常意义上“池”的功能,还提供了更全面的线程管理、任务提交等方法。

Executor框架可不仅仅是线程池,我觉得至少下面几点值得深入学习:

知识扩展

首先,我们来看看Executor框架的基本组成,请参考下面的类图。

我们从整体上把握一下各个类型的主要设计目的:

    void execute(Runnable command);

Executor的设计是源于Java早期线程API使用的教训,开发者在实现应用逻辑时,被太多线程创建、调度等不相关细节所打扰。就像我们进行HTTP通信,如果还需要自己操作TCP握手,开发效率低下,质量也难以保证。

    <T> Future<T> submit(Callable<T> task);

注意,这个例子输入的可是Callable,它解决了Runnable无法返回结果的困扰。

下面我就从源码角度,分析线程池的设计与实现,我将主要围绕最基础的ThreadPoolExecutor源码。ScheduledThreadPoolExecutor是ThreadPoolExecutor的扩展,主要是增加了调度逻辑,如想深入了解,你可以参考相关教程。而ForkJoinPool则是为ForkJoinTask定制的线程池,与通常意义的线程池有所不同。

这部分内容比较晦涩,罗列概念也不利于你去理解,所以我会配合一些示意图来说明。在现实应用中,理解应用与线程池的交互和线程池的内部工作过程,你可以参考下图。

简单理解一下:

    private final BlockingQueue<Runnable> workQueue;
    private final HashSet<Worker> workers = new HashSet<>();

线程池的工作线程被抽象为静态内部类Worker,基于AQS实现。

从上面的分析,就可以看出线程池的几个基本组成部分,一起都体现在线程池的构造函数中,从字面我们就可以大概猜测到其用意:

通过配置不同的参数,我们就可以创建出行为大相径庭的线程池,这就是线程池高度灵活性的基础。

    public ThreadPoolExecutor(int corePoolSize,
                          	int maximumPoolSize,
                          	long keepAliveTime,
                          	TimeUnit unit,
                          	BlockingQueue<Runnable> workQueue,
                          	ThreadFactory threadFactory,
                          	RejectedExecutionHandler handler)

进一步分析,线程池既然有生命周期,它的状态是如何表征的呢?

这里有一个非常有意思的设计,ctl变量被赋予了双重角色,通过高低位的不同,既表示线程池状态,又表示工作线程数目,这是一个典型的高效优化。试想,实际系统中,虽然我们可以指定线程极限为Integer.MAX_VALUE,但是因为资源限制,这只是个理论值,所以完全可以将空闲位赋予其他意义。

    private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
    // 真正决定了工作线程数的理论上限 
    private static final int COUNT_BITS = Integer.SIZE - 3;
    private static final int COUNT_MASK = (1 << COUNT_BITS) - 1;
    // 线程池状态,存储在数字的高位
    private static final int RUNNING = -1 << COUNT_BITS;
    …
    // Packing and unpacking ctl
    private static int runStateOf(int c)  { return c & ~COUNT_MASK; }
    private static int workerCountOf(int c)  { return c & COUNT_MASK; }
    private static int ctlOf(int rs, int wc) { return rs | wc; }

为了让你能对线程生命周期有个更加清晰的印象,我这里画了一个简单的状态流转图,对线程池的可能状态和其内部方法之间进行了对应,如果有不理解的方法,请参考Javadoc。注意,实际Java代码中并不存在所谓Idle状态,我添加它仅仅是便于理解。

前面都是对线程池属性和构建等方面的分析,下面我选择典型的execute方法,来看看其是如何工作的,具体逻辑请参考我添加的注释,配合代码更加容易理解。

    public void execute(Runnable command) {
    …
    	int c = ctl.get();
    // 检查工作线程数目,低于corePoolSize则添加Worker
    	if (workerCountOf(c) < corePoolSize) {
        	if (addWorker(command, true))
            	return;
        	c = ctl.get();
    	}
    // isRunning就是检查线程池是否被shutdown
    // 工作队列可能是有界的,offer是比较友好的入队方式
    	if (isRunning(c) && workQueue.offer(command)) {
        	int recheck = ctl.get();
    // 再次进行防御性检查
        	if (! isRunning(recheck) && remove(command))
            	reject(command);
        	else if (workerCountOf(recheck) == 0)
            	addWorker(null, false);
    	}
    // 尝试添加一个worker,如果失败意味着已经饱和或者被shutdown了
    	else if (!addWorker(command, false))
        	reject(command);
    }

线程池实践

线程池虽然为提供了非常强大、方便的功能,但是也不是银弹,使用不当同样会导致问题。我这里介绍些典型情况,经过前面的分析,很多方面可以自然的推导出来。

线程池大小的选择策略

上面我已经介绍过,线程池大小不合适,太多或太少,都会导致麻烦,所以我们需要去考虑一个合适的线程池大小。虽然不能完全确定,但是有一些相对普适的规则和思路。

    线程数 = CPU核数 × 目标CPU利用率 ×(1 + 平均等待时间/平均工作时间)

这些时间并不能精准预计,需要根据采样或者概要分析等方式进行计算,然后在实际中验证和调整。

另外,在实际工作中,不要把解决问题的思路全部指望到调整线程池上,很多时候架构上的改变更能解决问题,比如利用背压机制的Reactive Stream、合理的拆分等。

今天,我从Java创建的几种线程池开始,对Executor框架的主要组成、线程池结构与生命周期等方面进行了讲解和分析,希望对你有所帮助。

一课一练

关于今天我们讨论的题目你做到心中有数了吗?今天的思考题是从逻辑上理解,线程池创建和生命周期。请谈一谈,如果利用newSingleThreadExecutor()创建一个线程池,corePoolSize、maxPoolSize等都是什么数值?ThreadFactory可能在线程池生命周期中被使用多少次?怎么验证自己的判断?

请你在留言区写写你对这个问题的思考,我会选出经过认真思考的留言,送给你一份学习奖励礼券,欢迎你与我一起讨论。

你的朋友是不是也在准备面试呢?你可以“请朋友读”,把今天的题目分享给好友,或许你能帮到他。