Java 线程池详解
Java 线程池详解
池化技术想必大家已经屡见不鲜了，线程池、数据库连接池、HTTP 连接池等等都是对这个思想的应用。池化技术的思想主要是为了减少每次获取资源的消耗，提高对资源的利用率。
一、线程池介绍
顾名思义，线程池就是管理一系列线程的资源池，其提供了一种限制和管理线程资源的方式。每个线程池还维护一些基本统计信息，例如已完成任务的数量。
这里借用《Java 并发编程的艺术》书中的部分内容来总结一下使用线程池的好处：
-
降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
-
提高响应速度。当任务到达时，任务可以不需要等到线程创建就能立即执行。
-
提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。
线程池一般用于执行多个不相关联的耗时任务，没有多线程的情况下，任务顺序执行，使用了线程池的话可让多个不相关联的任务同时执行。
二、Executor 框架介绍
Executor 框架是 Java5 之后引进的，在 Java 5 之后，通过 Executor 来启动线程比使用 Thread 的 start 方法更好，除了更易管理，效率更好（用线程池实现，节约开销）外，还有关键的一点：有助于避免 this 逃逸问题。
1. this 逃逸
this 逃逸是指在构造函数返回之前其他线程就持有该对象的引用，调用尚未构造完全的对象的方法可能引发令人疑惑的错误。
在对象的构造函数还没有完全执行完毕（即对象处于一个不一致或不完整的状态）时，该对象的
this引用就已经被另一个线程或上下文所获取和使用。简单来说，就是 一个尚未“诞生”完全的对象，就被提前“曝光”和使用了。
为什么会发生？一个生动的比喻
想象一下你在组装一个机器人（相当于构造一个对象）：
你先给它装上了胳膊和腿（初始化部分字段）。
在给它装头和装入核心程序之前，你就迫不及待地按下了它的启动按钮（将
this引用发布了出去）。另一个线程看到机器人启动了，立刻命令它去完成一个需要“头部思考”和“核心程序”的任务。
结果可想而知：机器人行为错乱，因为它根本还不完整。
在代码中，这个“按下启动按钮”的操作通常发生在：
在构造函数中启动一个线程，并将
this传递给这个线程。在构造函数中注册一个事件监听器，而
this被用作监听器。在构造函数中将
this赋值给某个静态字段或共享的集合。核心：
在对象未完成构造（处于不一致状态）时，就将其引用暴露给其他线程，导致其他线程可能看到一个“部分构造”的、不完整的对象。
永远不要在构造函数中将
this引用发布到任何其他代码可能访问到的地方（静态字段、共享集合、其他对象的字段、启动线程、注册监听器等）。始终先完全构造对象，然后再发布其引用。让构造函数保持简单和私有，使用工厂方法来控制对象的创建和发布流程。
1.1 启动一个线程
new Thread(this).start() 正是在构造函数中导致 this 逃逸的一个典型例子。
让我们来详细分析一下这行代码为什么如此危险：
代码示例与分析
public class ProblematicRunnable implements Runnable {//实现接口Runnable，创建实现类的对象，表示一个可以交给线程执行的任务
private int value;
private String name;
//构造函数
public ProblematicRunnable(String name) {
this.name = name;
this.value = 10; // 部分初始化
// 【极其危险的操作】：在构造函数中启动线程并传递 'this'
Thread thread = new Thread(this); // 'this' 逃逸发生在这里！
thread.start(); // 新线程可能会在构造函数完成前开始运行
// 模拟一些耗时的初始化操作
try {
Thread.sleep(1000); // 假设这里有一些复杂的初始化逻辑
} catch (InterruptedException e) {
e.printStackTrace();
}
this.value = 100; // 这是期望的最终初始化值
}
@Override
public void run() {
// 危险！当新线程执行到这里时，构造函数可能还没有执行完
// value 可能是 10（中间状态），而不是 100（最终状态）
System.out.println(name + " - Value in run(): " + value);
}
public static void main(String[] args) {
ProblematicRunnable example = new ProblematicRunnable("Test");
}
}
如果在run()中，也sleep(1000),那么此时对象初始化完毕。value就是100.
为什么会发生 this 逃逸？
-
对象构造开始：
new ProblematicRunnable("Test")被调用。 -
部分初始化：
name和value被部分初始化（value = 10）。 -
this逃逸发生：-
new Thread(this)将当前对象的引用（即this）传递给了新创建的Thread对象。 -
关键点：此时，
ProblematicRunnable对象的构造还没有完成！
-
-
线程启动：
thread.start()启动新线程。操作系统调度器可能会立即让这个新线程开始执行，也可能在稍后执行。这是一种竞态条件。 -
两种可能的结果：
-
最坏情况（
this逃逸成功）：新线程立即执行，运行run()方法。此时构造函数中的Thread.sleep(1000)和value = 100还根本没执行！所以run()方法打印出的value值是10（一个不一致的中间状态）。 -
较好情况：新线程等到构造函数完全执行完毕（即
value = 100之后）才执行run()方法，打印出100。
-
问题的核心
-
不确定性：你无法控制或预测新线程到底会在构造函数的哪个时间点被调度执行。这种行为依赖于操作系统的线程调度，是不可预测的。
-
看到不一致状态：在新线程的
run()方法中，你可能会看到对象字段的默认值、中间值，而不是构造函数最终想要设置的值。
1.2注册监听器
当你将监听器（往往是 this）注册到另一个对象（事件源）时，你就把自己对象的引用“交出去了”。事件源会持有这个引用，并且完全可能在其内部的某个线程中，在你构造完成之前就触发事件、回调你的方法。
代码示例与分析
import javax.swing.*;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
public class ProblematicGui extends JFrame implements ActionListener {
private String message;
private final JButton button;
private static volatile ProblematicGui instance; // 用于存储正在构造的实例
public ProblematicGui() {
super("This Escape Example");
this.message = "Hello, World!"; // 部分初始化
instance = this; // 存储当前正在构造的实例
button = new JButton("Click Me");
// 【危险操作】：在构造函数中注册监听器，传递了 'this'
button.addActionListener(this); // 'this' 逃逸发生在这里！
this.getContentPane().add(button);
this.pack();
// 启动一个线程，在构造函数完成前尝试触发事件
new Thread(() -> {
try {
Thread.sleep(1000); // 等待1秒，确保监听器已注册但构造函数未完成
System.out.println("尝试在构造函数完成前触发事件...");
// 模拟按钮点击事件
ActionEvent fakeEvent = new ActionEvent(button, ActionEvent.ACTION_PERFORMED, "");
instance.actionPerformed(fakeEvent); // 直接调用监听器方法
} catch (InterruptedException ex) {
ex.printStackTrace();
}
}).start();
// 模拟一些耗时的初始化操作
try {
Thread.sleep(5000); // 这5秒内，对象处于"未完成"状态
} catch (InterruptedException e) {
e.printStackTrace();
}
this.message = "Final Message";
System.out.println("构造函数完成");
}
@Override
public void actionPerformed(ActionEvent e) {
System.out.println("事件处理被调用，当前状态: " + message);
JOptionPane.showMessageDialog(this, message);
someBusinessLogic();
}
private void someBusinessLogic() {
System.out.println("执行重要业务逻辑");
}
public static void main(String[] args) {
SwingUtilities.invokeLater(() -> {
ProblematicGui frame = new ProblematicGui();
frame.setVisible(true);
});
}
}对象初始化完成前，触发点击事件：
对象初始化完成后，再次触发点击事件：
!(C:\Users\Zzz\Desktop\wechat_2025-09-08_114413_268.png)
为什么会发生 this 逃逸？
-
构造开始：
new ProblematicGui()被调用。 -
部分初始化：
message被初始化为"Hello, World!"。 -
this逃逸发生：-
button.addActionListener(this)将当前对象的引用注册到了 Swing 的JButton组件中。 -
此时，
ProblematicGui对象的构造远未完成！ 它卡在Thread.sleep(5000)这里。
-
-
GUI 显示：
frame.setVisible(true)执行，窗口显示出来，按钮可以被用户点击。 -
灾难的导火索：在构造函数
sleep的5秒之内，如果用户点击了按钮：-
Swing 的事件分发线程（EDT） 会捕获到这个点击事件。
-
EDT 会回调所有注册的监听器，即调用
ProblematicGui.this.actionPerformed(e)。 -
actionPerformed方法被调用时，它看到的对象状态是：message是"Hello, World!"，并且someBusinessLogic()方法所依赖的其他资源可能根本还没初始化。 -
结果就是：程序可能行为异常、抛出空指针异常、或者显示错误的数据。
-
1.3 将 this 赋值给某个静态字段或共享的集合
在构造函数中将 this 赋值给静态字段或共享集合，就是一种明确的"发布"行为，这会导致 this 引用逃逸。
想象一下：你在填写自己的简历时，刚写完姓名，就把这份不完整的简历公开发布到了网上。别人看到你的简历时，可能只有姓名，而没有教育经历、工作经历等重要信息，从而对你产生错误的印象。
在代码中也是同样的道理：对象还没有完成构造（简历没写完），但其引用已经被其他人获取并使用了（简历被公开）。
代码示例与分析
public class StaticFieldEscapeDemo {
public static void main(String[] args) {
// 线程1：创建对象（构造速度较慢）
new Thread(() -> {
new PublishedObject("测试对象");
}).start();
// 线程2：立即使用全局引用
new Thread(() -> {
try {
Thread.sleep(1000); // 等待1秒，确保对象已开始构造但未完成
System.out.println("尝试使用全局引用...");
if (PublishedObject.globalReference != null) {
PublishedObject.globalReference.doSomethingImportant(); // 可能抛出异常！
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}).start();
}
}
class PublishedObject {
public static PublishedObject globalReference; // 静态字段，全局可访问
private String name;
private int importantValue;
public PublishedObject(String name) {
this.name = name;
// 【危险操作】：将尚未构造完成的对象发布到静态字段
globalReference = this; // this 逃逸！
// 模拟耗时的初始化操作
try {
Thread.sleep(3000); // 耗时3秒的初始化
} catch (InterruptedException e) {
e.printStackTrace();
}
this.importantValue = 100; // 重要的初始化操作
}
public void doSomethingImportant() {
if (importantValue != 100) {
throw new IllegalStateException("重要值未正确初始化!");
}
System.out.println("执行重要操作: " + importantValue);
}
}为什么会发生 this 逃逸？
-
构造开始：
new PublishedObject("测试对象")被调用。 -
部分初始化：
name被初始化为"测试对象"，importantValue此时为默认值0。 -
this逃逸发生：-
globalReference = this;将当前对象的引用发布到了静态字段PublishedObject.globalReference中。 -
此时，
PublishedObject对象的构造远未完成！ 它卡在Thread.sleep(3000)这里。然而，其引用已经被任何可以访问该静态字段的代码看到了。
-
-
多线程访问：另一个线程（线程2）启动，它休眠1秒后，直接访问全局静态字段
PublishedObject.globalReference。 -
灾难的导火索：线程2在构造函数
sleep的3秒之内，访问了已发布但未构造完成的对象：-
线程2检查
globalReference不为null，然后调用了doSomethingImportant()方法。 -
doSomethingImportant()方法被调用时，它看到的对象状态是：importantValue仍然是0（原始默认值），而不是构造函数最终要设置的100。 -
方法中的检查
if (importantValue != 100)失败，导致抛出IllegalStateException("重要值未正确初始化!")。 -
结果就是：程序因异常而崩溃，或者因为看到不一致的对象状态而产生错误的业务逻辑。
-
线程之间共享数据有两个方法：一个是构造方法传递，另一个就是静态变量
-
静态字段是类级别的变量，属于类
PublishedObject，而不是实例级别的。这意味着所有实例共享同一个静态字段。 -
它们存储在JVM的方法区（或元空间）中，也是全局共享的。所有线程都访问同一个静态字段。
-
堆内存（Heap Memory）：在JVM中，所有对象实例（如
PublishedObject对象）都存储在堆内存中。堆内存是全局共享的，意味着所有线程都可以访问堆中的对象（通过引用）。
模拟两个线程，一个线程执行构造函数，在给静态字段赋值，另一个线程直接尝试使用全局引用改静态字段：
Executor 框架不仅包括了线程池的管理，还提供了线程工厂、队列以及拒绝策略等，Executor 框架让并发编程变得更加简单。
2. 三大部分
Executor 框架结构主要由三大部分组成：
1、任务(Runnable /Callable)
这是要执行的工作单元，是框架的输入部分。
执行任务需要实现的 Runnable 接口 或 Callable接口。Runnable 接口或 Callable 接口 的实现类都可以被 ThreadPoolExecutor 或 ScheduledThreadPoolExecutor 执行。、
Runnable 接口：不返回结果，所以既能excute()，又能submit()，不能抛出受检异常 ------->重写run()
Callable 接口 ：可以返回结果，所以只能submit()，可以抛出受检异常 ------->重写call()
-
Runnable实现类对象：既可以用execute()提交，也可以用submit()提交。 -
Callable实现类对象：只能用submit()提交，不能用execute()提交。
2、任务的执行(Executor)
这是执行任务的机制，是框架的核心调度部分。
如下图所示，包括任务执行机制的核心接口 Executor ，以及继承自 Executor 接口的 ExecutorService 接口。ThreadPoolExecutor 和 ScheduledThreadPoolExecutor 这两个关键类实现了 ExecutorService 接口。
实际上我们需要更多关注的是 ThreadPoolExecutor 这个类。
Executor 接口
-
只定义了一个方法：
void execute(Runnable command) -
提交任务执行，但不提供返回结果的能力。
ExecutorService 接口
-
扩展了
Executor，提供了更丰富的任务执行控制 -
关键方法：
-
submit(): 提交任务，返回Future对象
-
注意： 通过查看 ScheduledThreadPoolExecutor 源代码我们发现 ScheduledThreadPoolExecutor 实际上是继承了 ThreadPoolExecutor 并实现了 ScheduledExecutorService ，而 ScheduledExecutorService 又实现了 ExecutorService，正如我们上面给出的类关系图显示的一样。
ThreadPoolExecutor 类描述:
//AbstractExecutorService实现了ExecutorService接口
public class ThreadPoolExecutor extends AbstractExecutorServiceScheduledThreadPoolExecutor 类描述:
//ScheduledExecutorService继承ExecutorService接口
public class ScheduledThreadPoolExecutor
extends ThreadPoolExecutor
implements ScheduledExecutorService3、异步计算的结果(Future)
这是获取任务执行结果的机制，是框架的输出部分。
Future 接口以及 Future 接口的实现类 FutureTask 类都可以代表异步计算的结果。
当我们把 Runnable接口 或 Callable 接口 的实现类提交给 ThreadPoolExecutor 或 ScheduledThreadPoolExecutor 执行。（调用 submit() 方法时会返回一个 FutureTask 对象）
FutureTask ：它实现了 Future 接口和 Runnable 接口，因此既可以作为 Runnable 被线程执行，又可以作为 Future 获取异步计算的结果，如下图所示。
Executor 框架的使用示意图：
-
主线程首先要创建实现
Runnable或者Callable接口的任务对象。
-
把创建完成的实现
Runnable接口的 对象直接交给ExecutorService执行:ExecutorService.execute（Runnable command））或者也可以把Runnable对象或Callable对象提交给ExecutorService执行（ExecutorService.submit（Runnable task）或ExecutorService.submit（Callable <T> task））。ExecutorService接口抽象方法：
void execute(Runnable command); <T> Future<T> submit(Callable<T> task); <T> Future<T> submit(Runnable task, T result);
-
如果执行
ExecutorService.submit（…），ExecutorService将返回一个实现Future接口的对象（我们刚刚也提到过了执行execute()方法和submit()方法的区别，submit()会返回一个FutureTask 对象）。由于 FutureTask实现了Runnable，我们也可以创建FutureTask，然后直接交给ExecutorService执行。
-
最后，主线程可以执行
FutureTask.get()方法来等待任务执行完成（获取任务结果（会阻塞直到任务完成））。主线程也可以执行FutureTask.cancel（boolean mayInterruptIfRunning）来取消此任务的执行。
三、ThreadPoolExecutor 类介绍
线程池实现类 ThreadPoolExecutor 是 Executor 框架最核心的类。
1、线程池参数分析
ThreadPoolExecutor 类中提供的四个构造方法。我们来看最长的那个，其余三个都是在这个构造方法的基础上产生（其他几个构造方法说白点都是给定某些默认参数的构造方法比如默认制定拒绝策略是什么）。
public ThreadPoolExecutor(int corePoolSize,//线程池的核心线程数量
int maximumPoolSize,//线程池的最大线程数
long keepAliveTime,//当线程数大于核心线程数时，多余的空闲线程存活的最长时间
TimeUnit unit,//时间单位
BlockingQueue<Runnable> workQueue,//任务队列，用来储存等待执行任务的队列
ThreadFactory threadFactory,//线程工厂，用来创建线程，一般默认即可
RejectedExecutionHandler handler//拒绝策略，当提交的任务过多而不能及时处理时，我们可以定制策略来处理任务
) {
if (corePoolSize < 0 ||
maximumPoolSize <= 0 ||
maximumPoolSize < corePoolSize ||
keepAliveTime < 0)
throw new IllegalArgumentException();
if (workQueue == null || threadFactory == null || handler == null)
throw new NullPointerException();
this.corePoolSize = corePoolSize;
this.maximumPoolSize = maximumPoolSize;
this.workQueue = workQueue;
this.keepAliveTime = unit.toNanos(keepAliveTime);
this.threadFactory = threadFactory;
this.handler = handler;
}ThreadPoolExecutor 3 个最重要的参数：
-
corePoolSize: 任务队列未达到队列容量时，最大可以同时运行的线程数量。 -
maximumPoolSize: 任务队列中存放的任务达到队列容量的时候，当前可以同时运行的线程数量变为最大线程数。 -
workQueue: 新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。
ThreadPoolExecutor其他常见参数 :
-
keepAliveTime:线程池中的线程数量大于corePoolSize的时候，如果这时没有新的任务提交，核心线程外的线程不会立即销毁，而是会等待，直到等待的时间超过了keepAliveTime才会被回收销毁。 -
unit:keepAliveTime参数的时间单位。 -
threadFactory:executor 创建新线程的时候会用到。 -
handler:拒绝策略。
下面这张图可以加深你对线程池中各个参数的相互关系的理解（图片来源：《Java 性能调优实战》）：
ThreadPoolExecutor 拒绝策略定义:
如果当前同时运行的线程数量达到最大线程数量并且队列也已经被放满了任务时，ThreadPoolExecutor 定义一些策略:
-
ThreadPoolExecutor.AbortPolicy：抛出RejectedExecutionException来拒绝新任务的处理。 -
ThreadPoolExecutor.CallerRunsPolicy：调用执行自己的线程运行任务，也就是直接在调用execute方法的线程中运行(run)被拒绝的任务，如果执行程序已关闭，则会丢弃该任务。因此这种策略会降低对于新任务提交速度，影响程序的整体性能。如果您的应用程序可以承受此延迟并且你要求任何一个任务请求都要被执行的话，你可以选择这个策略。 -
ThreadPoolExecutor.DiscardPolicy：不处理新任务，直接丢弃掉。 -
ThreadPoolExecutor.DiscardOldestPolicy：此策略将丢弃最早的未处理的任务请求
通过 ThreadPoolTaskExecutor 或者我们直接通过 ThreadPoolExecutor 的构造函数创建线程池，当我们不指定 RejectedExecutionHandler 拒绝策略来配置线程池的时候，默认使用的是 AbortPolicy。在这种拒绝策略下，如果队列满了，ThreadPoolExecutor 将抛出 RejectedExecutionException 异常来拒绝新来的任务 ，这代表你将丢失对这个任务的处理。如果不想丢弃任务的话，可以使用CallerRunsPolicy。CallerRunsPolicy 和其他的几个策略不同，它既不会抛弃任务，也不会抛出异常，而是将任务回退给调用者，使用调用者的线程来执行任务。
//CallerRunsPolicy拒绝策略 将任务回退给调用者，使用调用者的线程来执行任务
public static class CallerRunsPolicy implements RejectedExecutionHandler {
/**
* Creates a {@code CallerRunsPolicy}.
*/
public CallerRunsPolicy() { }
/**
* Executes task r in the caller's thread, unless the executor
* has been shut down, in which case the task is discarded.
*
* @param r the runnable task requested to be executed
* @param e the executor attempting to execute this task
*/
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
if (!e.isShutdown()) {
r.run();//在当前线程（即调用者线程）中同步执行任务代码块。
}
}
}
//AbortPolicy拒绝策略 直接抛出异常
public static class AbortPolicy implements RejectedExecutionHandler {
/**
* Creates an {@code AbortPolicy}.
*/
public AbortPolicy() { }
/**
* Always throws RejectedExecutionException.
*
* @param r the runnable task requested to be executed
* @param e the executor attempting to execute this task
* @throws RejectedExecutionException always
*/
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
//直接抛出异常RejectedExecutionException
throw new RejectedExecutionException("Task " + r.toString() +
" rejected from " +
e.toString());
}
}
//DiscardPolicy拒绝策略 不处理新任务，直接丢弃掉
public static class DiscardPolicy implements RejectedExecutionHandler {
/**
* Creates a {@code DiscardPolicy}.
*/
public DiscardPolicy() { }
/**
* Does nothing, which has the effect of discarding task r.
*
* @param r the runnable task requested to be executed
* @param e the executor attempting to execute this task
*/
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
//不做任何处理
}
}
//DiscardOldestPolicy拒绝策略 此策略将丢弃最早的未处理的任务请求
public static class DiscardOldestPolicy implements RejectedExecutionHandler {
/**
* Creates a {@code DiscardOldestPolicy} for the given executor.
*/
public DiscardOldestPolicy() { }
/**
* Obtains and ignores the next task that the executor
* would otherwise execute, if one is immediately available,
* and then retries execution of task r, unless the executor
* is shut down, in which case task r is instead discarded.
*
* @param r the runnable task requested to be executed
* @param e the executor attempting to execute this task
*/
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
if (!e.isShutdown()) {
e.getQueue().poll();//移除任务队列的头元素
e.execute(r);
}
}
}2、线程池创建的两种方式
方式一：通过 ThreadPoolExecutor 构造函数直接创建 (推荐)
这是最推荐的方式，因为它允许开发者明确指定线程池的核心参数，对线程池的运行行为有更精细的控制，从而避免资源耗尽的风险。
方式二：通过 Executors 工具类创建 (不推荐用于生产环境)
Executors工具类提供的创建线程池的方法如下图所示：
可以看出，通过Executors工具类可以创建多种类型的线程池，包括：
-
FixedThreadPool：固定大小线程池。该线程池中的线程数量始终不变。当有一个新的任务提交时，线程池中若有空闲线程，则立即执行。若没有，则新的任务会被暂存在一个任务队列中，待有线程空闲时，便处理在任务队列中的任务。 -
SingleThreadExecutor： 单线程线程池。若多余一个任务被提交到该线程池，任务会被保存在一个任务队列中，待线程空闲，按先入先出的顺序执行队列中的任务。 -
CachedThreadPool： 可根据实际情况调整线程数量的线程池。线程池的线程数量不确定，但若有空闲线程可以复用，则会优先使用可复用的线程。若所有线程均在工作，又有新的任务提交，则会创建新的线程处理任务。所有线程在当前任务执行完毕后，将返回线程池进行复用。 -
ScheduledThreadPool：定时任务线程池。给定的延迟后运行任务或者定期执行任务的线程池。使用了专门的DelayedWorkQueue（无界的延迟队列）。任务不是按提交顺序，而是按预期的执行时间来排序的。
《阿里巴巴 Java 开发手册》强制线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 构造函数的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险
Executors 返回线程池对象的弊端如下：
-
FixedThreadPool和SingleThreadExecutor:使用的是阻塞队列LinkedBlockingQueue，任务队列最大长度为Integer.MAX_VALUE，可以看作是无界的，可能堆积大量的请求，从而导致 OOM。 -
CachedThreadPool:使用的是同步队列SynchronousQueue, 允许创建的线程数量为Integer.MAX_VALUE，基本上就是可以无限创建线程，如果任务数量过多且执行速度较慢，可能会创建大量的线程，从而导致 OOM。
/**
*同步队列 SynchronousQueue(不存储元素的阻塞队列)
*/
public boolean isEmpty() {
return true;
}
public int size() {
return 0;
}SynchronousQueue 不是一个用于存储的容器，而是一个用于传递和同步的机制。
-
每一个
put/offer（生产者) 操作必须等待一个对应的take/poll（消费者）操作。 -
同理，每一个
take/poll（消费者）操作必须等待一个对应的put/offer（生产者）操作。
/**
* e: 要提交的元素（任务）。
* true: 表示当前模式是 “生产” 模式（offer/put）。
* 0: 超时时间。0 表示不等待（对于 offer(E e) 这种非超时方法而言）。
*/
//offer(E e) 是非阻塞的。它不会在没有消费者时让生产者线程等待，而是立即失败。
public boolean offer(E e) {
if (e == null) throw new NullPointerException();
return transferer.transfer(e, true, 0) != null;
}
/**
* null: 因为你是消费者，不是来提供数据的，所以第一个数据参数为 null。
* false: 表示当前模式是 “消费” 模式（take/poll）。
* 0: 对于 take() 来说，0 的含义是无限期等待，直到被中断或交接成功。
*/
//take() 是阻塞的。如果当前没有生产者，消费者线程会一直等待下去。
public E take() throws InterruptedException {
E e = transferer.transfer(null, false, 0);
if (e != null)
return e;
Thread.interrupted();// 清除中断状态，为下一步抛异常做准备
throw new InterruptedException();
}-
当线程池试图将任务
offer(提交) 给SynchronousQueue时，会发生什么？-
如果此时有空闲的消费者线程（即线程池中已有的线程）正在等待从队列中
take任务，那么offer操作会成功，任务立刻被那个空闲线程取走执行。这是最佳情况，实现了线程复用。 -
如果没有空闲线程在等待（
SynchronousQueue没有任何消费者），offer操作会立即失败（对于非定时offer而言）！因为队列“拒绝接收”这个元素。
-
-
offer操作失败意味着什么？-
这意味着对于线程池来说，队列“已满”。
-
于是，线程池就会进入上面的第3步：创建新的线程来执行这个任务！
-
结论：SynchronousQueue 使得 CachedThreadPool 的行为变成了：“如果有空闲线程，就复用；如果没有空闲线程，就立即创建新线程”。 这完美实现了线程数量的弹性伸缩，非常适合处理大量短命的异步任务。
-
ScheduledThreadPool和SingleThreadScheduledExecutor:使用的无界的延迟阻塞队列DelayedWorkQueue，任务队列最大长度为Integer.MAX_VALUE,可能堆积大量的请求，从而导致 OOM。
public static ExecutorService newFixedThreadPool(int nThreads) {
// LinkedBlockingQueue 的默认长度为 Integer.MAX_VALUE，可以看作是无界的
return new ThreadPoolExecutor(nThreads, nThreads,0L, TimeUnit.MILLISECONDS,new LinkedBlockingQueue<Runnable>());
}
public static ExecutorService newSingleThreadExecutor() {
// LinkedBlockingQueue 的默认长度为 Integer.MAX_VALUE，可以看作是无界的
return new FinalizableDelegatedExecutorService (new ThreadPoolExecutor(1, 1,0L, TimeUnit.MILLISECONDS,new LinkedBlockingQueue<Runnable>()));
}
// 同步队列 SynchronousQueue，没有容量，最大线程数是 Integer.MAX_VALUE`
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,60L, TimeUnit.SECONDS,new SynchronousQueue<Runnable>());
}
// DelayedWorkQueue（延迟阻塞队列）
public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {
return new ScheduledThreadPoolExecutor(corePoolSize);
}
public ScheduledThreadPoolExecutor(int corePoolSize) {
super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
new DelayedWorkQueue());
}3、线程池常用的阻塞队列总结
新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。
不同的线程池会选用不同的阻塞队列，我们可以结合内置线程池来分析。
容量为 Integer.MAX_VALUE 的 LinkedBlockingQueue（无界队列）：FixedThreadPool 和 SingleThreadExector 。FixedThreadPool最多只能创建核心线程数的线程（核心线程数和最大线程数相等），SingleThreadExector只能创建一个线程（核心线程数和最大线程数都是 1），二者的任务队列永远不会被放满。
SynchronousQueue（同步队列）：CachedThreadPool 。SynchronousQueue 没有容量，不存储元素，目的是保证对于提交的任务，如果有空闲线程，则使用空闲线程来处理；否则新建一个线程来处理任务。也就是说，CachedThreadPool 的最大线程数是 Integer.MAX_VALUE ，可以理解为线程数是可以无限扩展的，可能会创建大量线程，从而导致 OOM。
DelayedWorkQueue（延迟阻塞队列）：ScheduledThreadPool 和 SingleThreadScheduledExecutor 。DelayedWorkQueue 的内部元素并不是按照放入的时间排序，而是会按照延迟的时间长短对任务进行排序，内部采用的是“堆”的数据结构，可以保证每次出队的任务都是当前队列中执行时间最靠前的。DelayedWorkQueue 添加元素满了之后会自动扩容原来容量的 1/2，即永远不会阻塞，最大扩容可达 Integer.MAX_VALUE，所以最多只能创建核心线程数的线程。
四、线程池原理分析
上面讲解了 Executor框架以及 ThreadPoolExecutor 类，下面让我们实战一下，来通过写一个 ThreadPoolExecutor 的小 Demo 来回顾上面的内容。
线程池示例代码
首先创建一个 Runnable 接口的实现类（当然也可以是 Callable 接口）
import java.util.Date;
/**
* 这是一个简单的Runnable类，需要大约5秒钟来执行其任务。
* @author zzz
*/
public class MyRunnable implements Runnable {
private String command;
public MyRunnable(String s) {
this.command = s;
}
@Override
public void run() {
System.out.println(Thread.currentThread().getName() + " Start. Time = " + new Date());
processCommand();
System.out.println(Thread.currentThread().getName() + " End. Time = " + new Date());
}
private void processCommand() {
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
@Override
public String toString() {
return this.command;
}
}编写测试程序，我们这里以阿里巴巴推荐的使用 ThreadPoolExecutor 构造函数自定义参数的方式来创建线程池。
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
public class ThreadPoolExecutorDemo {
private static final int CORE_POOL_SIZE = 5;
private static final int MAX_POOL_SIZE = 10;
private static final int QUEUE_CAPACITY = 100;
private static final Long KEEP_ALIVE_TIME = 1L;
public static void main(String[] args) {
//使用阿里巴巴推荐的创建线程池的方式
//通过ThreadPoolExecutor构造函数自定义参数创建
ThreadPoolExecutor executor = new ThreadPoolExecutor(
CORE_POOL_SIZE,
MAX_POOL_SIZE,
KEEP_ALIVE_TIME,
TimeUnit.SECONDS,
new ArrayBlockingQueue<>(QUEUE_CAPACITY),
new ThreadPoolExecutor.CallerRunsPolicy());
for (int i = 0; i < 10; i++) {
//创建WorkerThread对象（WorkerThread类实现了Runnable 接口）
Runnable worker = new MyRunnable("" + i);
//执行Runnable
executor.execute(worker);
}
//终止线程池
executor.shutdown();
while (!executor.isTerminated()) {
}//任务全部执行完了才会跳出来，因为executor.isTerminated()判断为true了才会跳出while循环，当且仅当调用 shutdown() 方法后，并且所有提交的任务完成后返回为 true
System.out.println("Finished all threads");
}
}可以看到我们上面的代码指定了：
-
corePoolSize: 核心线程数为 5。 -
maximumPoolSize：最大线程数 10 -
keepAliveTime: 等待时间为 1L。 -
unit: 等待时间的单位为 TimeUnit.SECONDS。 -
workQueue：任务队列为ArrayBlockingQueue，并且容量为 100; -
handler:拒绝策略为CallerRunsPolicy。
输出结构：
我们通过前面的代码输出结果可以看出：线程池首先会先执行 5 个任务，然后这些任务有任务被执行完的话，就会去拿新的任务执行。
现在，我们就分析上面的输出内容来简单分析一下线程池原理。
为了搞懂线程池的原理，我们需要首先分析一下 execute方法。 在示例代码中，我们使用 executor.execute(worker)来提交一个任务到线程池中去。
// 存放线程池的运行状态 (runState) 和线程池内有效线程的数量 (workerCount)
private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
private static int workerCountOf(int c) {
return c & CAPACITY;
}
//任务队列
private final BlockingQueue<Runnable> workQueue;
public void execute(Runnable command) {
// 如果任务为null，则抛出异常。
if (command == null)
throw new NullPointerException();
// ctl 中保存的线程池当前的一些状态信息
int c = ctl.get();
// 下面会涉及到 3 步 操作
// 1.第一阶段：尝试使用核心线程执行
if (workerCountOf(c) < corePoolSize) {//检查当前工作线程数是否小于核心线程数 (corePoolSize)
if (addWorker(command, true))//如果小于，尝试通过 addWorker(command, true) 创建一个新的核心线程来执行任务
return;//如果创建成功 (addWorker 返回 true)，方法直接返回
c = ctl.get();//如果创建失败（可能由于线程池状态已改变），重新获取当前的 ctl 值
}
// 2.第二阶段：尝试将任务加入队列
// 通过 isRunning 方法判断线程池状态，线程池处于 RUNNING 状态并且队列可以加入任务，该任务才会被加入进去
if (isRunning(c) && workQueue.offer(command)) {//检查线程池是否仍在运行状态，并且尝试将任务加入工作队列
int recheck = ctl.get();// 再次获取线程池状态
if (!isRunning(recheck) && remove(command))//如果线程池状态不是 RUNNING 状态就需要从任务队列中移除任务
reject(command);//
// 如果当前工作线程数量为0，新创建一个线程并执行。
else if (workerCountOf(recheck) == 0)//如果工作线程数为0
//线程复用，非核心线程不工作时有生命剩余时间，只有0个非核心线程时才会创建新的核心线程
addWorker(null, false);//创建一个非核心线程来处理队列中的任务
}
//3. 第三阶段：尝试创建非核心线程
else if (!addWorker(command, false))//如果任务无法加入队列（队列已满）
reject(command);//如果创建非核心线程也失败（可能因为线程池已关闭或达到最大线程数），执行拒绝策略
}这里简单分析一下整个流程：
-
如果当前运行的线程数小于核心线程数，那么就会新建一个核心线程来执行任务。
-
如果当前运行的线程数等于或大于核心线程数，但是小于最大线程数，（if (isRunning(c) && workQueue.offer(command))）那么就把该任务放入到任务队列里等待执行。
-
如果向任务队列投放任务失败（任务队列已经满了）（else if (!addWorker(command, false))），但是当前运行的线程数是小于最大线程数的，就新建一个线程来执行任务。
-
如果当前运行的线程数已经等同于最大线程数了，新建线程将会使当前运行的线程超出最大线程数，那么当前任务会被拒绝，拒绝策略会调用
RejectedExecutionHandler.rejectedExecution()方法。
在 execute 方法中，多次调用 addWorker 方法。addWorker 这个方法主要用来创建新的工作线程，如果返回 true 说明创建和启动工作线程成功，否则的话返回的就是 false。
// 全局锁，并发操作必备
private final ReentrantLock mainLock = new ReentrantLock();
// 跟踪线程池的最大大小，只有在持有全局锁mainLock的前提下才能访问此集合
private int largestPoolSize;
// 工作线程集合，存放线程池中所有的（活跃的）工作线程，只有在持有全局锁mainLock的前提下才能访问此集合
private final HashSet<Worker> workers = new HashSet<>();
//获取线程池状态
private static int runStateOf(int c) { return c & ~CAPACITY; }
//判断线程池的状态是否为 Running
private static boolean isRunning(int c) {
return c < SHUTDOWN;
}
/**
* 添加新的工作线程到线程池
* @param firstTask 要执行
* @param core参数为true的话表示使用线程池的基本大小，为false使用线程池最大大小
* @return 添加成功就返回true否则返回false
*/
private boolean addWorker(Runnable firstTask, boolean core) {
retry:
for (int c = ctl.get();;) {
// Check if queue empty only if necessary.
if (runStateAtLeast(c, SHUTDOWN)
&& (runStateAtLeast(c, STOP)
|| firstTask != null
|| workQueue.isEmpty()))
return false;
for (;;) {
if (workerCountOf(c)
>= ((core ? corePoolSize : maximumPoolSize) & COUNT_MASK))
return false;
if (compareAndIncrementWorkerCount(c))
break retry;
c = ctl.get(); // Re-read ctl
if (runStateAtLeast(c, SHUTDOWN))
continue retry;
// else CAS failed due to workerCount change; retry inner loop
}
}
// 标记工作线程是否启动成功
boolean workerStarted = false;
// 标记工作线程是否创建成功
boolean workerAdded = false;
Worker w = null;
try {
w = new Worker(firstTask);
final Thread t = w.thread;
if (t != null) {
// 加锁
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
// Recheck while holding lock.
// Back out on ThreadFactory failure or if
// shut down before lock acquired.
//获取线程池状态
int c = ctl.get();
//isRunning(c) 如果线程池状态依然为RUNNING,并且线程的状态是存活的话，就会将工作线程添加到工作线程集合中
//(runStateLessThan(c, STOP) && firstTask == null)如果线程池状态小于STOP，也就是RUNNING或者SHUTDOWN状态下，同时传入的任务实例firstTask为null，则需要添加到工作线程集合和启动新的Worker
// firstTask == null证明只新建线程而不执行任务
if (isRunning(c) ||
(runStateLessThan(c, STOP) && firstTask == null)) {
if (t.getState() != Thread.State.NEW)
throw new IllegalThreadStateException();
workers.add(w);
// 工作线程是否启动成功
workerAdded = true;
//更新当前工作线程的最大容量
int s = workers.size();
if (s > largestPoolSize)
largestPoolSize = s;
}
} finally {
// 释放锁
mainLock.unlock();
}
// 如果成功添加工作线程，则调用Worker内部的线程实例t的Thread.start()方法启动真实的线程实例
if (workerAdded) {
t.start();
// 工作线程是否启动成功
workerStarted = true;
}
}
} finally {
// 线程启动失败，需要从工作线程中移除对应的Worke
if (! workerStarted)
addWorkerFailed(w);
}
return workerStarted;
}我们在代码中模拟了 10 个任务，我们配置的核心线程数为 5、等待队列容量为 100 ，所以每次只可能存在 5 个任务同时执行，剩下的 5 个任务会被放到等待队列中去。当前的 5 个任务中如果有任务被执行完了，线程池就会去拿新的任务执行。
五、几个常见的对比
1、Runnable vs Callable
Runnable自 Java 1.0 以来一直存在，但Callable仅在 Java 1.5 中引入,目的就是为了来处理Runnable不支持的用例。Runnable 接口不会返回结果或抛出检查异常，但是 Callable 接口可以。所以，如果任务不需要返回结果或抛出异常推荐使用 Runnable 接口，这样代码看起来会更加简洁。
工具类 Executors 可以实现将 Runnable 对象转换成 Callable 对象。（Executors.callable(Runnable task) 或 Executors.callable(Runnable task, Object result)）。
@FunctionalInterfacepublic interface Runnable {
/** * 被线程执行，没有返回值也无法抛出异常 */
public abstract void run();
}
@FunctionalInterface
public interface Callable<V> {
/**
* 计算结果，或在无法这样做时抛出异常。
* @return 计算得出的结果
* @throws 如果无法计算结果，则抛出异常
*/
V call() throws Exception;
}2、execute() vs submit()
execute() 和 submit()是两种提交任务到线程池的方法，有一些区别：
返回值：execute() 方法用于提交不需要返回值的任务。通常用于执行 Runnable 任务，无法判断任务是否被线程池成功执行。submit() 方法用于提交需要返回值的任务。可以提交 Runnable 或 Callable 任务。submit() 方法返回一个 Future 对象，通过这个 Future 对象可以判断任务是否执行成功，并获取任务的返回值（get()方法会阻塞当前线程直到任务完成， get（long timeout，TimeUnit unit）多了一个超时时间，如果在 timeout 时间内任务还没有执行完，就会抛出 java.util.concurrent.TimeoutException）。
异常处理：在使用 submit() 方法时，可以通过 Future 对象处理任务执行过程中抛出的异常；而在使用 execute() 方法时，异常处理需要通过自定义的 ThreadFactory （在线程工厂创建线程的时候设置UncaughtExceptionHandler对象来 处理异常）或 ThreadPoolExecutor 的 afterExecute() 方法来处理
示例 1：使用 get()方法获取返回值。
public class Test {
public static void main(String[] args) throws ExecutionException, InterruptedException {
ExecutorService executorService = Executors.newFixedThreadPool(3);
Future<String> submit = executorService.submit(() -> {
try {
Thread.sleep(5000L);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "abc";
});
String s = submit.get();
System.out.println(s);
executorService.shutdown();
}
}输出示例：
示例 2：使用 get（long timeout，TimeUnit unit）方法获取返回值。
public class Test {
public static void main(String[] args) throws ExecutionException, InterruptedException, TimeoutException{
ExecutorService executorService = Executors.newFixedThreadPool(3);
Future<String> submit = executorService.submit(() -> {
try {
Thread.sleep(5000L);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "abc";
});
String s = submit.get(3, TimeUnit.SECONDS);
System.out.println(s);
executorService.shutdown();
}
}输出示例：
3、shutdown()VSshutdownNow()
-
shutdown（）:关闭线程池，线程池的状态变为SHUTDOWN。线程池不再接受新任务了，但是队列里的任务得执行完毕。 -
shutdownNow（）:关闭线程池，线程池的状态变为STOP。线程池会终止当前正在运行的任务，并停止处理排队的任务并返回正在等待执行的 List。
4、isTerminated() VS isShutdown()
-
isShutDown当调用shutdown()方法后返回为 true。 -
isTerminated当调用shutdown()方法后，并且所有提交的任务完成后返回为 true
六、几种常见的内置线程池
1、FixedThreadPool
FixedThreadPool 被称为可重用固定线程数的线程池。通过 Executors 类中的相关源代码来看一下相关实现：
/**
* 创建一个可重用固定数量线程的线程池
*/
public static ExecutorService newFixedThreadPool(int nThreads, ThreadFactory threadFactory) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>(),
threadFactory);
}从上面源代码可以看出新创建的 FixedThreadPool 的 corePoolSize 和 maximumPoolSize 都被设置为 nThreads，这个 nThreads 参数是我们使用的时候自己传递的。
即使 maximumPoolSize 的值比 corePoolSize 大，也至多只会创建 corePoolSize 个线程。这是因为FixedThreadPool 使用的是容量为 Integer.MAX_VALUE 的 LinkedBlockingQueue（无界队列），队列永远不会被放满。
执行任务过程介绍
FixedThreadPool 的 execute() 方法运行示意图（该图片来源：《Java 并发编程的艺术》）：
上图说明：
-
如果当前运行的线程数小于
corePoolSize， 如果再来新任务的话，就创建新的线程来执行任务； -
当前运行的线程数等于
corePoolSize后， 如果再来新任务的话，会将任务加入LinkedBlockingQueue； -
线程池中的线程执行完 手头的任务后，会在循环中反复从
LinkedBlockingQueue中获取任务来执行；
为什么不推荐使用FixedThreadPool？
FixedThreadPool 使用无界队列 LinkedBlockingQueue（队列的容量为 Integer.MAX_VALUE）作为线程池的工作队列会对线程池带来如下影响：
-
当线程池中的线程数达到
corePoolSize后，新任务将在无界队列中等待，因此线程池中的线程数不会超过corePoolSize； -
由于使用无界队列时
maximumPoolSize将是一个无效参数，因为不可能存在任务队列满的情况。所以，通过创建FixedThreadPool的源码可以看出创建的FixedThreadPool的corePoolSize和maximumPoolSize被设置为同一个值。 -
由于 1 和 2，使用无界队列时
keepAliveTime将是一个无效参数； -
运行中的
FixedThreadPool（未执行shutdown()或shutdownNow()）不会拒绝任务，在任务比较多的时候会导致 OOM（内存溢出）。
2、SingleThreadExecutor
SingleThreadExecutor 是只有一个线程的线程池。下面看看SingleThreadExecutor 的实现：
/**
*返回只有一个线程的线程池
*/
public static ExecutorService newSingleThreadExecutor(ThreadFactory threadFactory) {
return new FinalizableDelegatedExecutorService
(new ThreadPoolExecutor(1, 1,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>(),
threadFactory));
}
从上面源代码可以看出新创建的 SingleThreadExecutor 的 corePoolSize 和 maximumPoolSize 都被设置为 1，其他参数和 FixedThreadPool 相同。
执行任务过程介绍
SingleThreadExecutor 的运行示意图（该图片来源：《Java 并发编程的艺术》）：
上图说明 :
-
如果当前运行的线程数少于
corePoolSize，则创建一个新的线程执行任务； -
当前线程池中有一个运行的线程后，将任务加入
LinkedBlockingQueue -
线程执行完当前的任务后，会在循环中反复从
LinkedBlockingQueue中获取任务来执行；
为什么不推荐使用SingleThreadExecutor？
SingleThreadExecutor 和 FixedThreadPool 一样，使用的都是容量为 Integer.MAX_VALUE 的 LinkedBlockingQueue（无界队列）作为线程池的工作队列。SingleThreadExecutor 使用无界队列作为线程池的工作队列会对线程池带来的影响与 FixedThreadPool 相同。说简单点，就是可能会导致 OOM。
3、CachedThreadPool
CachedThreadPool 是一个会根据需要创建新线程的线程池。下面通过源码来看看 CachedThreadPool 的实现
/**
* 创建一个线程池，根据需要创建新线程，但会在先前构建的线程可用时重用它。
*/
public static ExecutorService newCachedThreadPool(ThreadFactory threadFactory) {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>(),
threadFactory);
}
CachedThreadPool 的corePoolSize 被设置为空（0），maximumPoolSize被设置为 Integer.MAX.VALUE，即它是无界的，这也就意味着如果主线程提交任务的速度高于 maximumPool 中线程处理任务的速度时，CachedThreadPool 会不断创建新的线程。极端情况下，这样会导致耗尽 cpu 和内存资源。
执行任务过程介绍
CachedThreadPool 的 execute() 方法的执行示意图（该图片来源：《Java 并发编程的艺术》）：
上图说明：
-
首先执行
SynchronousQueue.offer(Runnable task)提交任务到任务队列。如果当前maximumPool中有闲线程正在执行SynchronousQueue.poll(keepAliveTime,TimeUnit.NANOSECONDS)，那么主线程执行 offer 操作与空闲线程执行的poll操作配对成功，主线程把任务交给空闲线程执行，execute()方法执行完成，否则执行下面的步骤 2； -
当初始
maximumPool为空，或者maximumPool中没有空闲线程时，将没有线程执行SynchronousQueue.poll(keepAliveTime,TimeUnit.NANOSECONDS)。这种情况下，步骤 1 将失败，此时CachedThreadPool会创建新线程执行任务，execute 方法执行完成；
为什么不推荐使用CachedThreadPool？
CachedThreadPool 使用的是同步队列 SynchronousQueue, 允许创建的线程数量为 Integer.MAX_VALUE ，可能会创建大量线程，从而导致 OOM。
ScheduledThreadPool
ScheduledThreadPool 用来在给定的延迟后运行任务或者定期执行任务。
public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {
return new ScheduledThreadPoolExecutor(corePoolSize);
}
public ScheduledThreadPoolExecutor(int corePoolSize) {
super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
new DelayedWorkQueue());
}ScheduledThreadPool 是通过 ScheduledThreadPoolExecutor 创建的，使用的DelayedWorkQueue（延迟阻塞队列）作为线程池的任务队列。
DelayedWorkQueue 的内部元素并不是按照放入的时间排序，而是会按照延迟的时间长短对任务进行排序，内部采用的是“堆”的数据结构，可以保证每次出队的任务都是当前队列中执行时间最靠前的。DelayedWorkQueue 添加元素满了之后会自动扩容原来容量的 1/2，即永远不会阻塞，最大扩容可达 Integer.MAX_VALUE，所以最多只能创建核心线程数的线程。
ScheduledThreadPoolExecutor 继承了 ThreadPoolExecutor，所以创建 ScheduledThreadExecutor 本质也是创建一个 ThreadPoolExecutor 线程池，只是传入的参数不相同。
ScheduledThreadPoolExecutor类描述：
public class ScheduledThreadPoolExecutor
extends ThreadPoolExecutor
implements ScheduledExecutorServiceScheduledThreadPoolExecutor 和 Timer 对比
-
Timer对系统时钟的变化敏感，ScheduledThreadPoolExecutor不是； -
Timer只有一个执行线程，因此长时间运行的任务可以延迟其他任务。ScheduledThreadPoolExecutor可以配置任意数量的线程。 此外，如果你想（通过提供ThreadFactory），你可以完全控制创建的线程; -
在
TimerTask中抛出的运行时异常会杀死一个线程，从而导致Timer死机即计划任务将不再运行。ScheduledThreadExecutor不仅捕获运行时异常，还允许您在需要时处理它们（通过重写afterExecute方法ThreadPoolExecutor）。抛出异常的任务将被取消，但其他任务将继续运行。
参考
更多推荐
50
0- 0
已为社区贡献8条内容
所有评论(0)