线程池

为什么推荐用线程池去创建线程？
为什么不推荐使用线程池工具类创建线程池
线程池深入分析

为什么推荐用线程池去创建线程？

特点

手动创建线程：

频繁创建销毁开销大，疯狂抢占资源混乱，出错概率大。

线程池创建线程

很好的管理线程，复用线程，合理高效运用资源

示例

我们创建 10000 个线程，做同样一件事。接下来来比较手动创建线程和线程池创建线程的运行时间。

手动创建线程

代码如下：

public class ThreadTest {
    public static void main(String[] args) throws InterruptedException {
        long start = System.currentTimeMillis();
        final Random random = new Random();
        final List<Integer> list = new ArrayList();

        for(int i=0;i<10000;i++){
            Thread thread = new Thread(){
                @Override
                public void run() {
                    list.add(random.nextInt());
                }
            };
            thread.start();
            thread.join();
        }

        System.out.println("时间：" + (System.currentTimeMillis() - start));
        System.out.println("大小：" + list.size());
    }
}

运行时间 2120 毫秒，如下图

图片:

线程池创建线程

public class ThreadPoolTest {

    public static void main(String[] args) throws InterruptedException {
        long start = System.currentTimeMillis();
        final Random random = new Random();
        final List<Integer> list = new ArrayList();
        ExecutorService executorService = Executors.newSingleThreadExecutor();

        for(int i=0;i<10000;i++){
            executorService.execute(new Runnable() {
                @Override
                public void run() {
                    list.add(random.nextInt());
                }
            });
        }
        executorService.shutdown();
//        executorService.awaitTermination(1, TimeUnit.DAYS);
        System.out.println("时间：" + (System.currentTimeMillis() - start));
        System.out.println("大小：" + list.size());
    }
}

运行时间 11 毫秒，如下图：

图片:

可见线程池创建线程的方式比手动创建线程的方式快了一两千倍。

为什么不推荐使用线程池工具类创建线程池

线程池执行器

由于线程池工具类里面都是实例化线程池执行器，接下来看下线程池执行器的构造方法。如下图：

图片:

参数说明：

corePoolSize：核心线程数量
maximumPoolSize：整个线程池最大线程数量
keepAliveTime：空闲时间。活跃线程数量大于核心线程数量时，当某个线程空闲时间大于这个时间时，该线程会被回收。
unit：空闲时间单位。
workQueue：在任务执行前，存放一些任务（暂挂）的处理队列，当任务数量大于核心线程数量时。未处理的任务就会放到该队列，当该队列放满时，再来的任务会交给非核心线程（maximumPoolSize-corePoolSize）去处理。
threadFactory：创建线程时的线程工厂。
handler：当任务太多时的拒绝策略，默认使用 AbortPolicy

拒绝策略一共有 4 种，如下图：

图片:

默认使用 AbortPolicy 策略

图片:

这几种策略看源码注释就行，这里不再赘叙。

线程池工具类创建的几种线程池

这个线程池工具类为 java.util.concurrent.Executors，该工具类提供了很多创建线程池的方法，如下图：

图片:

我们来看下这其中几种的源码，分析下为什么不推荐使用线程池工具类来创建线程池。

newCachedThreadPool

图片:

该线程池核心线程数为 0，非核心线程数 Integer.MAX_VALUE，这可能会导致内存溢出

newFixedThreadPool

图片:

线程数量固定。该线程池核心线程数为 nThreads，非核心线程数 nThreads-nThreads 也就是 0。但是其处理队列为 LinkedBlockingQueue，这个类默认容量也为 Integer.MAX_VALUE.，如下图，这也可能会导致内存溢出

图片:

newSingleThreadExecutor

图片:

单线程。核心线程数量为 1，总线程数量也为 1，即，非核心线程数量为 0。处理队列也使用了 LinkedBlockingQueue，同样也可能会导致内存溢出

newScheduledThreadPool

图片:

定时任务线程。点进去看其参数 ScheduledThreadPoolExecutor，如下

图片:

又调用了父类构造器，其父类就是线程池执行器，如下图：

图片:

我们发现调用父类构造器时 super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,

new DelayedWorkQueue()); 第二个参数也是 Integer.MAX_VALUE，同样也可能会导致内存溢出。

线程池深入分析

线程提交优先级

为了很好说明线程池内部线程分配情况，我们把线程池当作一个公司，一个线程当作一个员工。如下图左边灰色背景部分。

有本司员工（核心线程），数量为：corePoolSize

有一个仓库（处理队列）

外包员工（非核心线程），员工总数为：maximumPoolSize

图片:

假如我们现在创建好了一个线程池 MyThreadPool，如上图右边紫色背景部分。现在有 15 个任务需要处理，一个员工只能处理一个任务。那么：

先拿出 4 个任务交给 4 个核心员工（核心线程）去处理；
接着再拿出 5 个任务放到临时仓库（处理队列）；
最后拿出 6 个任务交给 6=10-4（maximumPoolSize-corePoolSize）个外包员工去处理。

如果现在还有新任务来呢，就会有专门的拒绝策略去处理。

上面这 3 个处理顺序也叫提交优先级。

处理任务，分配线程情况如下图：

图片:

线程池处理流程示意图：

图片:

对应源码如下：

java.util.concurrent#execute(Runnable command)

图片:

代码调用时序图如下：

图片:

一个奇怪的现象

现创建一个线程池有核心线程 5 个，悬挂队列容量 5，非核心线程 5 个。按照线程池提交流程分析，应该：

先 1~5 个任务交给前 5 个线程；

然后 6~10 个任务放到队列里面；

最后 11~15 个任务交给非核心线程；

这 3 组任务的提交顺序：先是 1~5 任务、再是 6~10 任务、最后 11~15 任务。那么其重写的 run 方法的执行顺序应该也是这样的。事实上真的如此吗？

代码示例如下：

图片:

执行结果：

图片:

我们发现中间 5 个任务竟然是最后执行的！按照我们上面的分析中间 5 个任务应该是紧接着前 5 个任务执行后执行。这是怎么回事呢？

原来上面我们分析的是线程池的提交优先级（提交顺序），控制台日志展示的执行优先级（执行顺序）。

线程执行优先级

这个执行流程到底在那控制着呢？我们根据代码从头开始捋下：

java.util.concurrent.ThreadPoolExecutor#execute(Runnable command)方法

图片:

从上图可以看到，核心线程与非核心线程 addWorker 时传的第一个参数 command，即，任务不为空。队列这种情况 addWorker 时上传的任务为 null。接着看 addWorker 方法。

java.util.concurrent.ThreadPoolExecutor#addWorker(Runnable firstTask, boolean core)方法

图片:

也就是说核心线程、非核心线程情况时上次的 firstTask 不为 null，队列情况时上传的 firstTask 为 null。接着看 Workder 类。

private final class Worker extends AbstractQueuedSynchronizer implements Runnable{}

图片:

接着查看 runWorker 方法。

java.util.concurrent.ThreadPoolExecutor#runWorker(Worker w）

图片:

注意看红框中这行代码，已知核心线程、非核心线程情况时上次的 firstTask 不为 null，队列情况时上传的 firstTask 为 null。

再来看蓝色框中代码，也就是当核心线程、非核心线程都为空，即，处理完后，这个 task 才能为 null。

当 task==null 时，去执行 getTask，来看下该方法 java.util.concurrent.ThreadPoolExecutor#getTask()

图片:

可见该方法中是从队列 workQueue 中获取的任务。

最后看绿色框（上上幅图）中的 task.run()，就去执行我们刚开始重写的 run()方法了。

这个就是线程池的执行优先级了。

原文链接：https://blog.csdn.net/weixin_41968788/article/details/119461121

线程池