深入源码，深度解析Java 线程池的实现原理

2401_84049088

于 2024-04-22 09:10:13 发布

阅读量697

点赞数 7

分类专栏：程序员文章标签： java 网络开发语言

本文链接：https://blog.csdn.net/2401_84049088/article/details/138059004

版权

程序员专栏收录该内容

434 篇文章 0 订阅

订阅专栏

this.handler = handler;

}

主要参数就是下面这几个：

corePoolSize：线程池中的核心线程数，包括空闲线程，也就是核心线程数的大小；
maximumPoolSize：线程池中允许的最多的线程数，也就是说线程池中的线程数是不可能超过该值的；
keepAliveTime：当线程池中的线程数大于 corePoolSize 的时候，在超过指定的时间之后就会将多出 corePoolSize 的的空闲的线程从线程池中删除；
unit：keepAliveTime 参数的单位（常用的秒为单位）；
workQueue：用于保存任务的队列，此队列仅保持由 executor 方法提交的任务 Runnable 任务；
threadFactory：线程池工厂，他主要是为了给线程起一个标识。也就是为线程起一个具有意义的名称；
handler：拒绝策略

阻塞队列

workQueue 有多种选择，在 JDK 中一共提供了 7 中阻塞对列，分别为：

ArrayBlockingQueue ：一个由数组结构组成的有界阻塞队列。此队列按照先进先出（FIFO）的原则对元素进行排序。默认情况下不保证访问者公平地访问队列，所谓公平访问队列是指阻塞的线程，可按照阻塞的先后顺序访问队列。非公平性是对先等待的线程是不公平的，当队列可用时，阻塞的线程都可以竞争访问队列的资格。
LinkedBlockingQueue ：一个由链表结构组成的有界阻塞队列。此队列的默认和最大长度为Integer.MAX_VALUE。此队列按照先进先出的原则对元素进行排序。
PriorityBlockingQueue ：一个支持优先级排序的无界阻塞队列。（虽然此队列逻辑上是无界的，但是资源被耗尽时试图执行 add 操作也将失败，导致 OutOfMemoryError）
DelayQueue：一个使用优先级队列实现的无界阻塞队列。元素的一个无界阻塞队列，只有在延迟期满时才能从中提取元素
SynchronousQueue：一个不存储元素的阻塞队列。一种阻塞队列，其中每个插入操作必须等待另一个线程的对应移除操作，反之亦然。（SynchronousQueue 该队列不保存元素）
LinkedTransferQueue：一个由链表结构组成的无界阻塞队列。相对于其他阻塞队列LinkedTransferQueue多了tryTransfer和transfer方法。
LinkedBlockingDeque：一个由链表结构组成的双向阻塞队列。是一个由链表结构组成的双向阻塞队列

在以上的7个队列中，线程池中常用的是ArrayBlockingQueue、LinkedBlockingQueue、SynchronousQueue，

队列中的常用的方法如下：

| 类型 | 方法 | 含义 | 特点 |

| — | — | — | — |

| 抛异常 | add | 添加一个元素 | 如果队列满，抛出异常 IllegalStateException |

| 阻塞 | put | 添加一个元素 | 如果队列满，阻塞 |

关于阻塞队列，介绍到这里也就基本差不多了。

线程池工厂

线程池工厂，就像上面已经介绍的，目的是为了给线程起一个有意义的名字。用起来也非常的简单，只需要实现ThreadFactory接口即可

public class CustomThreadFactory implements ThreadFactory {

@Override

public Thread newThread(Runnable r) {

Thread thread = new Thread®;

thread.setName(“我是你们自己定义的线程名称”);

return thread;

}

具体的使用就不去废话了。

拒绝策略

线程池有四种默认的拒绝策略，分别为：

AbortPolicy：这是线程池默认的拒绝策略，在任务不能再提交的时候，抛出异常，及时反馈程序运行状态。如果是比较关键的业务，推荐使用此拒绝策略，这样子在系统不能承载更大的并发量的时候，能够及时的通过异常发现；
DiscardPolicy：丢弃任务，但是不抛出异常。如果线程队列已满，则后续提交的任务都会被丢弃，且是静默丢弃。这玩意不建议使用；
DiscardOldestPolicy：丢弃队列最前面的任务，然后重新提交被拒绝的任务。这玩意不建议使用；
CallerRunsPolicy：如果任务添加失败，那么主线程就会自己调用执行器中的 executor 方法来执行该任务。这玩意不建议使用；

也就是说关于线程池的拒绝策略，最好使用默认的。这样能够及时发现异常。如果上面的都不能满足你的需求，你也可以自定义拒绝策略，只需要实现 RejectedExecutionHandler 接口即可

public class CustomRejection implements RejectedExecutionHandler {

@Override

public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {

System.out.println(“你自己想怎么处理就怎么处理”);

}

看到这里，我们再来画一张图来总结和概括下线程池的执行示意图：

详细的执行过程全部在图中说明了。

提交任务到线程池

在 java 中，有两个方法可以将任务提交到线程池，分别是submit和execute。

execute 方法

execute()方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功。

void execute(Runnable command);

通过以下代码可知 execute() 方法输入的任务是一个Runnable类的实例。

executorService.execute(()->{

System.out.println(“ThreadPoolDemo.execute”);

});

submit 方法

submit()方法用于提交需要返回值的任务。

Future<?> submit(Runnable task);

线程池会返回一个future类型的对象，通过这个 future 对象可以判断任务是否执行成功，并且可以通过future的get()方法来获取返回值，get() 方法会阻塞当前线程直到任务完成，而使用get（long timeout，TimeUnit unit）方法则会阻塞当前线程一段时间后立即返回，这时候有可能任务没有执行完。

Future<?> submit = executorService.submit(() -> {

System.out.println(“ThreadPoolDemo.submit”);

});

关闭线程池

其实，如果优雅的关闭线程池是一个令人头疼的问题，线程开启是简单的，但是想要停止却不是那么容易的。通常而言，大部分程序员都是使用 jdk 提供的两个方法来关闭线程池，他们分别是：shutdown 或 shutdownNow；

通过调用线程池的 shutdown 或 shutdownNow 方法来关闭线程池。它们的原理是遍历线程池中的工作线程，然后逐个调用线程的 interrupt 方法来中断线程（PS：中断，仅仅是给线程打上一个标记，并不是代表这个线程停止了，如果线程不响应中断，那么这个标记将毫无作用），所以无法响应中断的任务可能永远无法终止。

但是它们存在一定的区别，shutdownNow首先将线程池的状态设置成 STOP，然后尝试停止所有的正在执行或暂停任务的线程，并返回等待执行任务的列表，而 shutdown 只是将线程池的状态设置成SHUTDOWN状态，然后中断所有没有正在执行任务的线程。

只要调用了这两个关闭方法中的任意一个，isShutdown 方法就会返回 true。当所有的任务都已关闭后，才表示线程池关闭成功，这时调用isTerminaed方法会返回 true。至于应该调用哪一种方法来关闭线程池，应该由提交到线程池的任务特性决定，通常调用 shutdown方法来关闭线程池，如果任务不一定要执行完，则可以调用 shutdownNow 方法。

这里推荐使用稳妥的 shutdownNow 来关闭线程池，至于更优雅的方式我会在以后的并发编程设计模式中的两阶段终止模式中会再次详细介绍。

合理的参数

为什么叫合理的参数，那不合理的参数是什么样子的？在我们创建线程池的时候，里面的参数该如何设置才能称之为合理呢？其实这是有一定的依据的，我们先来看一下以下的创建的方式：

ExecutorService executorService = new ThreadPoolExecutor(5,

TimeUnit.SECONDS,

new ArrayBlockingQueue<>(5),

r -> {

Thread thread = new Thread®;

thread.setName(“线程池原理讲解”);

return thread;

});

你说他合理不合理？我也不知道，因为我们没有参考的依据，在实际的开发中，我们需要根据任务的性质（IO是否频繁？）来决定我们创建的核心的线程数的大小，实际上可以从以下的一个角度来分析：