【多线程】线程池ThreadPoolExecutor（全面详解）
目录
- 一、线程池原理与实战
-
- （一）JUC的线程池架构
-
- 1.Executor
- 2.ExecutorService
- 3.AbstractExecutorService
- 4.ThreadPoolExecutor
- 5.ScheduledExecutorService
- 6.ScheduledThreadPoolExecutor
- 7.Executors
- （二）Executors的4种快捷创建线程池的方法
-
- 1.newSingleThreadExecutor创建“单线程化线程池”
- 2.newFixedThreadPool创建“固定数量的线程池”
- 3.newCachedThreadPool创建“可缓存线程池”
- 4.newScheduledThreadPool创建“可调度线程池”
- （三）线程池的标准创建方式
- （四）向线程池提交任务的两种方式
- （五）线程池的任务调度流程
- （六）线程工厂：ThreadFactory
- （七）任务阻塞队列
- （八）调度器的钩子方法
- （九）线程池的拒绝策略
- （十）线程池的优雅关闭
- （十一）Executors快捷创建线程池的潜在问题
- 二、确定线程池的线程数
-
- （一）线程池分类
- （二）IO密集型
- （三）CPU密集型
- （四）混合型
一、线程池原理与实战
上篇文章介绍的，多线程的“前世”，“今生”与“未来”，都是手动创建、销毁线程会降低资源的利用率，Java线程的创建非常昂贵，需要JVM和OS（操作系统）配合完成大量的工作：
（1）必须为线程堆栈分配和初始化大量内存块，其中包含至少1MB的栈内存。
（2）需要进行系统调用，以便在OS（操作系统）中创建和注册本地线程。
Java高并发应用频繁创建和销毁线程的操作是非常低效的，而且是不被编程规范所允许的。如何降低Java线程的创建成本？必须使用到线程池。线程池主要解决了以下两个问题：
（1）提升性能：线程池能独立负责线程的创建、维护和分配。在执行大量异步任务时，可以不需要自己创建线程，而是将任务交给线程池去调度。线程池能尽可能使用空闲的线程去执行异步任务，最大限度地对已经创建的线程进行复用，使得性能提升明显。
（2）线程管理：每个Java线程池会保持一些基本的线程统计信息，例如完成的任务数量、空闲时间等，以便对线程进行有效管理，使得能对所接收到的异步任务进行高效调度。
（一）JUC的线程池架构
在多线程编程中，线程和任务管理也变得非常复杂。为了简化这些复杂的线程管理模式，需要一个“管理者”来统一管理线程及任务分配，这就是线程池。
在JUC中有关线程池的类与接口的架构图大致如下图所示。
JUC就是java.util.concurrent工具包的简称，该工具包是从JDK 1.5开始加入JDK的，是用于完成高并发、处理多线程的一个工具包。
1.Executor
Executor是Java异步目标任务的“执行者”接口，其目标是执行目标任务。“执行者”Executor提供了execute()接口来执行已提交的Runnable执行目标实例。Executor作为执行者的角色，其目的是提供一种将“任务提交者”与“任务执行者”分离开来的机制。它只包含一个函数式方法：
void execute(Runnable command)
2.ExecutorService
ExecutorService继承于Executor。它是Java异步目标任务的“执行者服务”接口，对外提供异步任务的接收服务。ExecutorService提供了“接收异步任务并转交给执行者”的方法，如submit系列方法、invoke系列方法等，具体如下：
//向线程池提交单个异步任务
<T> Future<T> submit(Callable<T> task);
//向线程池提交批量异步任务
<T> List<Future<T>> invokeAll(Collection<? extends Callable<T>> tasks) throws InterruptedException;
3.AbstractExecutorService
AbstractExecutorService是一个抽象类，它实现了ExecutorService接口。AbstractExecutorService存在的目的是为ExecutorService中的接口提供默认实现。
4.ThreadPoolExecutor
ThreadPoolExecutor就是大名鼎鼎的“线程池”实现类，它继承于AbstractExecutorService抽象类。ThreadPoolExecutor是JUC线程池的核心实现类。线程的创建和终止需要很大的开销，线程池中预先提供了指定数量的可重用线程，所以使用线程池会节省系统资源，并且每个线程池都维护了一些基础的数据统计，方便线程的管理和监控。
5.ScheduledExecutorService
ScheduledExecutorService是一个接口，它继承于ExecutorService。它是一个可以完成“延时”和“周期性”任务的调度线程池接口，其功能和Timer/TimerTask类似。
6.ScheduledThreadPoolExecutor
ScheduledThreadPoolExecutor继承于ThreadPoolExecutor，它提供了ScheduledExecutorService线程池接口中“延时执行”和“周期执行”等抽象调度方法的具体实现。ScheduledThreadPoolExecutor类似于Timer，但是在高并发程序中，ScheduledThreadPoolExecutor的性能要优于Timer。
7.Executors
Executors是一个静态工厂类，它通过静态工厂方法返回ExecutorService、ScheduledExecutorService等线程池示例对象，这些静态工厂方法可以理解为一些快捷的创建线程池的方法。
（二）Executors的4种快捷创建线程池的方法
通过Executors的4种快捷创建线程池的方法，具体如下表所示：
接下来将简单介绍每种创建线程池的方法特点，因为实际项目一般不容许使用Executors创建线程池就不再展示实例代码。
1.newSingleThreadExecutor创建“单线程化线程池”
该方法用于创建一个“单线程化线程池”，也就是只有一个线程的线程池，所创建的线程池用唯一的工作线程来执行任务，使用此方法创建的线程池能保证所有任务按照指定顺序（如FIFO）执行。
该线程池有以下特点：
（1）单线程化的线程池中的任务是按照提交的次序顺序执行的。
（2）池中的唯一线程的存活时间是无限的。
（3）当池中的唯一线程正繁忙时，新提交的任务实例会进入内部的阻塞队列中，并且其阻塞队列是无界的。
总体来说，单线程化的线程池所适用的场景是：任务按照提交次序，一个任务一个任务地逐个执行的场景。
2.newFixedThreadPool创建“固定数量的线程池”
该方法用于创建一个“固定数量的线程池”，Executors.newFixedThreadPool(int threads)其唯一的参数用于设置池中线程的“固定数量”。
“固定数量的线程池”的特点大致如下：
（1）如果线程数没有达到“固定数量”，每次提交一个任务线程池内就创建一个新线程，直到线程达到线程池固定的数量。
（2）线程池的大小一旦达到“固定数量”就会保持不变，如果某个线程因为执行异常而结束，那么线程池会补充一个新线程。
（3）在接收异步任务的执行目标实例时，如果池中的所有线程均在繁忙状态，新任务会进入阻塞队列中（无界的阻塞队列）。
“固定数量的线程池”的适用场景：
需要任务长期执行的场景。“固定数量的线程池”的线程数能够比较稳定地保证一个数，能够避免频繁回收线程和创建线程，故适用于处理CPU密集型的任务，在CPU被工作线程长时间占用的情况下，能确保尽可能少地分配线程。“固定数量的线程池”的弊端：内部使用无界队列来存放排队任务，当大量任务超过线程池最大容量需要处理时，队列无限增大，使服务器资源迅速耗尽。
3.newCachedThreadPool创建“可缓存线程池”
该方法用于创建一个“可缓存线程池”，如果线程池内的某些线程无事可干成为空闲线程，“可缓存线程池”可灵活回收这些空闲线程。
“可缓存线程池”的特点大致如下：
（1）在接收新的异步任务target执行目标实例时，如果池内所有线程繁忙，此线程池就会添加新线程来处理任务。
（2）此线程池不会对线程池大小进行限制，线程池大小完全依赖于操作系统（或者说JVM）能够创建的最大线程大小。
（3）如果部分线程空闲，也就是存量线程的数量超过了处理任务数量，就会回收空闲（60秒不执行任务）线程。
“可缓存线程池”的适用场景：
需要快速处理突发性强、耗时较短的任务场景，如Netty的NIO处理场景、REST API接口的瞬时削峰场景。“可缓存线程池”的线程数量不固定，只要有空闲线程就会被回收；接收到的新异步任务执行目标，查看是否有线程处于空闲状态，如果没有就直接创建新的线程。“可缓存线程池”的弊端：线程池没有最大线程数量限制，如果大量的异步任务执行目标实例同时提交，可能会因创建线程过多而导致资源耗尽。
4.newScheduledThreadPool创建“可调度线程池”
该方法用于创建一个“可调度线程池”，即一个提供“延时”和“周期性”任务调度功能的ScheduledExecutorService类型的线程池。
“可调度线程池”的适用场景：
周期性地执行任务的场景。Spring Boot中的任务调度器，底层借助了JUC的ScheduleExecutorService“可调度线程池”实现。
总结
以上为Executors中4个主要的快捷创建线程池的方法。为何JUC要提供工厂方法呢？原因是使用ThreadPoolExecutor、ScheduledThreadPoolExecutor构造器创建普通线程池、可调度线程池比较复杂，这些构造器会涉及大量的复杂参数。尽管Executors的工厂方法使用方便，但是在生产场景中被很多企业（尤其是大厂）的开发规范所禁用。
（三）线程池的标准创建方式
大部分企业的开发规范都会禁止使用快捷线程池（具体原因稍后介绍），要求通过标准构造器ThreadPoolExecutor去构造工作线程池。Executors工厂类中创建线程池的快捷工厂方法实际上是调用ThreadPoolExecutor（定时任务使用ScheduledThreadPoolExecutor）线程池的构造方法完成的。ThreadPoolExecutor构造方法有多个重载版本，其中一个比较重要的构造器如下：
// 使用标准构造器构造一个普通的线程池
public ThreadPoolExecutor(
int corePoolSize, // 核心线程数，即使线程空闲（Idle），默认也不会回收
int maximumPoolSize, // 线程数的上限
long keepAliveTime, TimeUnit unit, // 线程最大空闲（Idle）时长
BlockingQueue<Runnable> workQueue, // 任务的排队队列
ThreadFactory threadFactory, // 新线程的产生方式
RejectedExecutionHandler handler) // 拒绝策略
接下来对这些参数进行具体介绍。
1.核心和最大线程数量
参数corePoolSize用于设置核心（Core）线程池数量，参数maximumPoolSize用于设置最大线程数量。
线程池执行器将会根据corePoolSize和maximumPoolSize自动维护线程池中的工作线程，大致规则为：
（1）当在线程池接收到新任务，并且当前工作线程数少于corePoolSize时，即使其他工作线程处于空闲状态，也会创建一个新线程来处理该请求，直到线程数达到corePoolSize。
（2）如果当前工作线程数多于corePoolSize数量，但小于maximumPoolSize数量，那么仅当任务排队队列已满时才会创建新线程。通过设置corePoolSize和maximumPoolSize相同，可以创建一个固定大小的线程池。
（3）当maximumPoolSize被设置为无界值（如Integer.MAX_VALUE）时，线程池可以接收任意数量的并发任务。
（4）corePoolSize和maximumPoolSize不仅能在线程池构造时设置，也可以调用setCorePoolSize()和setMaximumPoolSize()两个方法进行动态更改。
2.BlockingQueue
BlockingQueue（阻塞队列）的实例用于暂时接收到的异步任务，如果线程池的核心线程都在忙，那么所接收到的目标任务缓存在阻塞队列中。
3.keepAliveTime
线程构造器的keepAliveTime（空闲线程存活时间）参数用于设置池内核心线程最大空闲时长，如果超过这个时间，默认情况下核心线程会被回收。如果池在使用过程中提交任务的频率变高，也可以调用方法setKeepAliveTime(long，TimeUnit)进行线程存活时间的动态调整，可以将时长延长。如果需要防止Idle线程被终止，可以将Idle时间设置为无限大，具体如下：
setKeepAliveTime(Long.MAX_VALUE，TimeUnit.NANOSECONDS);
默认情况下，Idle超时策略仅适用于存在超过corePoolSize线程的情况。但若调用了allowCoreThreadTimeOut(boolean)方法，并且传入了参数true，则keepAliveTime参数所设置的Idle超时策略也将被应用于非核心线程。
（四）向线程池提交任务的两种方式
向线程池提交任务的两种方式大致如下：
方式一：调用execute()方法，例如：
//Executor 接口中的方法
void execute(Runnable command);
方式二：调用submit()方法，例如：
//ExecutorService 接口中的方法
<T> Future<T> submit(Callable<T> task);
<T> Future<T> submit(Runnable task, T result);
Future<?> submit(Runnable task);
submit()和execute()两类方法的区别：
（1）二者所接收的参数和有无返回结果不一样
Execute()方法只能接收Runnable类型的参数，而submit()方法可以接收Callable、Runnable两种类型的参数。Callable类型的任务是可以返回执行结果的，而Runnable类型的任务不可以返回执行结果。
submit()方法也用于启动任务的执行，但是启动之后会返回Future对象，代表一个异步执行实例，可以通过该异步执行实例去获取结果。
（2）submit()方便Exception处理
execute()方法在启动任务执行后，任务执行过程中可能发生的异常调用者并不关心。而通过submit()方法返回的Future对象（异步执行实例），可以进行异步执行过程中的异常捕获。
1.通过submit()返回的Future对象获取结果
submit()方法自身并不会传递结果，而是返回一个Future异步执行实例，处理过程的结果被包装到Future实例中，调用者可以通过Future.get()方法获取异步执行的结果。演示代码如下：
// 省略import
public class CreateThreadPoolDemo
{
// 省略其他
//测试用例：获取异步调用的结果
@Test
public void testSubmit2()
{
// 演示暂用Executors线程工厂
ScheduledExecutorService pool = Executors.newScheduledThreadPool(2);
Future<Integer> future = pool.submit(new Callable<Integer>()
{
@Override
public Integer call() throws Exception
{
//返回200～300的随机数
return RandomUtil.randInRange(200, 300);
}
});
try
{
Integer result = future.get();
Print.tco("异步执行的结果是:" + result);
} catch (InterruptedException e)
{
Print.tco("异步调用被中断");
e.printStackTrace();
} catch (ExecutionException e)
{
Print.tco("异步调用过程中，发生了异常");
e.printStackTrace();
}
sleepSeconds(10);
//关闭线程池
pool.shutdown();
}
}
执行的结果如下：
[main]：异步执行的结果是:220
2.通过submit()返回的Future对象捕获异常
submit()方法自身并不会传递异常，处理过程中的异常都被包装到Future实例中，调用者在调用Future.get()方法获取执行结果时，可以捕获异步执行过程中抛出的受检异常和运行时异常，并进行对应的业务处理。演示代码如下：
// 省略import
public class CreateThreadPoolDemo
{
//异步任务的执行目标类
static class TargetTask implements Runnable
{
//为了节约篇幅，省略重复内容
}
//异步的执行目标类：执行过程中将发生异常
static class TargetTaskWithError extends TargetTask
{
public void run()
{
super.run();
throw new RuntimeException("Error from " + taskName);
}
}
//测试用例：提交和执行
@Test
public void testSubmit()
{
ScheduledExecutorService pool = Executors.newScheduledThreadPool(2);
pool.execute(new TargetTaskWithError());
/**
* submit(Runnable x) 返回一个future
*/
Future future = pool.submit(new TargetTaskWithError());
try
{
//如果异常抛出，就会在调用Future.get()时传递给调用者
if (future.get() == null)
{
//如果Future的返回值为null，那么任务完成
Print.tco("任务完成");
}
} catch (Exception e)
{
Print.tco(e.getCause().getMessage());
}
sleepSeconds(10);
//关闭线程池
pool.shutdown();
}
// 省略其他
}
执行结果如下：
[pool-1-thread-2]：任务：task-2 doing
[pool-1-thread-1]：任务：task-1 doing
[pool-1-thread-2]：task-2 运行结束.
[pool-1-thread-1]：task-1 运行结束.
[main]：Error from task-2
在ThreadPoolExecutor类的实现中，内部核心的任务提交方法是execute()方法，虽然用户程序通过submit()也可以提交任务，但是实际上submit()方法中最终调用的还是execute()方法。
（五）线程池的任务调度流程
线程池的任务调度流程（包含接收新任务和执行下一个任务）大致如下：
（1）如果当前工作线程数量小于核心线程数量，执行器总是优先创建一个任务线程，而不是从线程队列中获取一个空闲线程。
（2）如果线程池中总的任务数量大于核心线程池数量，新接收的任务将被加入阻塞队列中，一直到阻塞队列已满。在核心线程池数量已经用完、阻塞队列没有满的场景下，线程池不会为新任务创建一个新线程。
（3）当完成一个任务的执行时，执行器总是优先从阻塞队列中获取下一个任务，并开始执行，一直到阻塞队列为空，其中所有的缓存任务被取光。
（4）在核心线程池数量已经用完、阻塞队列也已经满了的场景下，如果线程池接收到新的任务，将会为新任务创建一个线程（非核心线程），并且立即开始执行新任务。
（5）在核心线程都用完、阻塞队列已满的情况下，一直会创建新线程去执行新任务，直到池内的线程总数超出maximumPoolSize。如果线程池的线程总数超过maximumPoolSize，线程池就会拒绝接收任务，当新任务过来时，会为新任务执行拒绝策略。
任务调度流程如下图所示
在创建线程池时，如果线程池的参数（如核心线程数量、最大线程数量、BlockingQueue等）配置得不合理，就会出现任务不能被正常调度的问题。
下面是一个错误的线程池配置示例：
// 省略import
public class CreateThreadPoolDemo
{
@org.junit.Test
public void testThreadPoolExecutor()
{
ThreadPoolExecutor executor = new ThreadPoolExecutor(
1, //corePoolSize
100, //maximumPoolSize
100, //keepAliveTime 空闲保活时长
TimeUnit.SECONDS, //空闲保活时长的单位
new LinkedBlockingDeque<>(100));//workQueue
//提交5个任务
for (int i = 0; i < 5; i++)
{
final int taskIndex = i;
executor.execute(() ->
{
Print.tco("taskIndex = " + taskIndex);
try
{ //极端测试：无限制睡眠
Thread.sleep(Long.MAX_VALUE);
} catch (InterruptedException e)
{
e.printStackTrace();
}
});
}
while (true)
{
//每隔1秒，输出线程池的工作任务数量、总计的任务数量
Print.tco("- activeCount:" + executor.getActiveCount()+
" - taskCount:" + executor.getTaskCount());
sleepSeconds(1);
}
}
// 省略其他
}
运行程序，结果如下：
[main]：- activeCount:1 - taskCount:5
[pool-1-thread-1]：taskIndex = 0
[main]：- activeCount:1 - taskCount:5
[main]：- activeCount:1 - taskCount:5
[main]：- activeCount:1 - taskCount:5
[main]：- activeCount:1 - taskCount:5
[main]：- activeCount:1 - taskCount:5
[main]：- activeCount:1 - taskCount:5
...
以上示例创建了最大线程数量maximumPoolSize为100的线程池，仅仅向其中提交了5个任务。理论上，这5个任务都会被执行到，奇怪的是示例中只有1个任务在执行，其他的4个任务都在等待。其他任务被加入到了阻塞队列中，需要等pool-1-thread-1线程执行完第一个任务后，才能依次从阻塞队列取出执行。但是，实例中的第一个任务是一个永远也没有办法完成的任务，所以其他的4个任务只能永远在阻塞队列中等待着。由于参数配置得不合理，因此出现了以上的奇怪现象。
为什么会出现上面的奇怪现象呢？因为例子中的corePoolSize为1，阻塞队列的大小为100，按照线程创建的规则，需要等阻塞队列已满，才会去创建新的线程。例子中加入了5个任务，阻塞队列大小为4（<100），所以线程池的调度器不会去创建新的线程，后面的4个任务只能等待。
以上示例的目的是传递两个知识点：
（1）核心和最大线程数量、BlockingQueue队列等参数如果配置得不合理，可能会造成异步任务得不到预期的并发执行，造成严重的排队等待现象。
（2）线程池的调度器创建线程的一条重要的规则是：在corePoolSize已满之后，还需要等阻塞队列已满，才会去创建新的线程。
（六）线程工厂：ThreadFactory
ThreadFactory是Java线程工厂接口，这是一个非常简单的接口，具体如下：
public interface ThreadFactory {
//唯一的方法：创建一个新线程
Thread newThread(Runnable target);
}
在调用ThreadFactory的唯一方法newThread()创建新线程时，可以更改所创建的新线程的名称、线程组、优先级、守护进程状态等。如果newThread()的返回值为null，表示线程工厂未能成功创建线程，线程池可能无法执行任何任务。
使用Executors创建新的线程池时，也可以基于ThreadFactory（线程工厂）创建，在创建新线程池时可以指定将要使用的ThreadFactory实例。只不过，如果没有指定的话，就会使用Executors.defaultThreadFactory默认实例。使用默认的线程工厂实例所创建的线程全部位于同一个ThreadGroup（线程组）中，具有相同的NORM_PRIORITY（优先级为5），而且都是非守护进程状态。
说明
这里提到了两个工厂类，比较容易混淆。
Executors为线程池工厂类，用于快捷创建线程池（Thread Pool）；ThreadFactory为线程工厂类，用于创建线程（Thread）。
基于自定义的ThreadFactory实例创建线程池，首先需要实现一个ThreadFactory接口，实现其唯一的抽象方法newThread(Runnable)。下面的例子首先实现一个简单的线程工厂，然后基于该线程工厂快捷创建线程池，具体的代码如下：
// 省略import
public class CreateThreadPoolDemo
{
//一个简单的线程工厂
static public class SimpleThreadFactory implements ThreadFactory
{
static AtomicInteger threadNo = new AtomicInteger(1);
//实现其唯一的创建线程方法
@Override
public Thread newThread(Runnable target)
{
String threadName = "simpleThread-" + threadNo.get();
Print.tco("创建一个线程，名称为：" + threadName);
threadNo.incrementAndGet();
//设置线程名称和异步执行目标
Thread thread = new Thread(target,threadName);
//设置为守护线程
// thread.setDaemon(true);
return thread;
}
}
//线程工厂的测试用例
@org.junit.Test
public void testThreadFactory()
{
//使用自定义线程工厂快捷创建一个固定大小的线程池
ExecutorService pool =
Executors.newFixedThreadPool(2,new SimpleThreadFactory());
for (int i = 0; i < 5; i++)
{
pool.submit(new TargetTask());
}
//等待10秒
sleepSeconds(10);
Print.tco("关闭线程池");
pool.shutdown();
}
// 省略其他
}
运行以上代码，其输出如下：
[main]：创建一条线程，名称为：simpleThread-1
[main]：创建一条线程，名称为：simpleThread-2
[simpleThread-1]：任务：task-1 doing
[simpleThread-2]：任务：task-2 doing
[simpleThread-1]：task-1 运行结束.
[simpleThread-1]：任务：task-3 doing
[simpleThread-2]：task-2 运行结束.
[simpleThread-2]：任务：task-4 doing
[simpleThread-2]：task-4 运行结束.
[simpleThread-1]：task-3 运行结束.
[simpleThread-2]：任务：task-5 doing
[simpleThread-2]：task-5 运行结束.
[main]：关闭线程池
（七）任务阻塞队列
Java中的阻塞队列（BlockingQueue）与普通队列相比有一个重要的特点：在阻塞队列为空时会阻塞当前线程的元素获取操作。具体来说，在一个线程从一个空的阻塞队列中获取元素时线程会被阻塞，直到阻塞队列中有了元素；当队列中有元素后，被阻塞的线程会自动被唤醒（唤醒过程不需要用户程序干预）。
BlockingQueue是JUC包的一个超级接口，比较常用的实现类有：
（1）ArrayBlockingQueue：是一个数组实现的有界阻塞队列（有界队列），队列中的元素按FIFO排序。ArrayBlockingQueue在创建时必须设置大小，接收的任务超出corePoolSize数量时，任务被缓存到该阻塞队列中，任务缓存的数量只能为创建时设置的大小，若该阻塞队列已满，则会为新的任务创建线程，直到线程池中的线程总数大于maximumPoolSize。
（2）LinkedBlockingQueue：是一个基于链表实现的阻塞队列，按FIFO排序任务，可以设置容量（有界队列），不设置容量则默认使用Integer.Max_VALUE作为容量（无界队列）。该队列的吞吐量高于ArrayBlockingQueue。
如果不设置LinkedBlockingQueue的容量（无界队列），当接收的任务数量超出corePoolSize时，则新任务可以被无限制地缓存到该阻塞队列中，直到资源耗尽。有两个快捷创建线程池的工厂方法Executors.newSingleThreadExecutor和Executors.newFixedThreadPool使用了这个队列，并且都没有设置容量（无界队列）。
（3）PriorityBlockingQueue：是具有优先级的无界队列。
（4）DelayQueue：这是一个无界阻塞延迟队列，底层基于PriorityBlockingQueue实现，队列中每个元素都有过期时间，当从队列获取元素（元素出队）时，只有已经过期的元素才会出队，队列头部的元素是过期最快的元素。快捷工厂方法Executors.newScheduledThreadPool所创建的线程池使用此队列。
（5）SynchronousQueue：（同步队列）是一个不存储元素的阻塞队列，每个插入操作必须等到另一个线程的调用移除操作，否则插入操作一直处于阻塞状态，其吞吐量通常高于LinkedBlockingQueue。快捷工厂方法Executors.newCachedThreadPool所创建的线程池使用此队列。与前面的队列相比，这个队列比较特殊，它不会保存提交的任务，而是直接新建一个线程来执行新来的任务。
（八）调度器的钩子方法
ThreadPoolExecutor线程池调度器为每个任务执行前后都提供了钩子方法。ThreadPoolExecutor类提供了三个钩子方法（空方法），这三个钩子方法一般用作被子类重写，具体如下：
//任务执行之前的钩子方法（前钩子）
protected void beforeExecute(Thread t, Runnable r) { }
//任务执行之后的钩子方法（后钩子）
protected void afterExecute(Runnable r, Throwable t) { }
//线程池终止时的钩子方法（停止钩子）
protected void terminated() { }
（1）beforeExecute：异步任务执行之前的钩子方法
线程池工作线程在异步执行目标实例（如Runnable实例）前调用此钩子方法。此方法仍然由执行任务的工作线程调用。默认实现不执行任何操作，但可以在子类中对其进行自定义。此方法由执行目标实例的工作线程调用，可用于重新初始化ThreadLocal线程本地变量实例、更新日志记录、开始计时统计、更新上下文变量等。
（2）afterExecute：异步任务执行之后的钩子方法
线程池工作线程在异步执行目标实例后调用此钩子方法。此方法仍然由执行任务的工作线程调用。此钩子方法的默认实现不执行任何操作，可以在调度器子类中对其进行自定义。此方法由执行目标实例的工作线程调用，可用于清除ThreadLocal线程本地变量、更新日志记录、收集统计信息、更新上下文变量等。
（3）terminated：线程池终止时的钩子方法
terminated钩子方法在Executor终止时调用，默认实现不执行任何操作。
说明
beforeExecute和afterExecute两个方法在每个任务执行前后被调用，如果钩子（回调方法）引发异常，内部工作线程可能失败并突然终止。
为线程池定制钩子方法的示例，具体代码如下：
// 省略import
public class CreateThreadPoolDemo
{
//线程本地变量,用于记录线程异步任务的开始执行时间
private static final ThreadLocal<Long> START_TIME = new ThreadLocal<>();
@org.junit.Test
public void testHooks()
{
ExecutorService pool = new ThreadPoolExecutor(2, //coreSize
4, //最大线程数
60,//空闲保活时长
TimeUnit.SECONDS,
new LinkedBlockingQueue<>(2)) //等待队列
{
//继承：调度器终止钩子
@Override
protected void terminated()
{
Print.tco("调度器已经终止!");
}
//继承：执行前钩子
@Override
protected void beforeExecute(Thread t, Runnable target)
{
Print.tco( target +"前钩被执行");
//记录开始执行时间
START_TIME.set(System.currentTimeMillis());
super.beforeExecute(t, target);
}
//继承：执行后钩子
@Override
protected void afterExecute(Runnable target, Throwable t)
{
super.afterExecute(target, t);
//计算执行时长
long time = (System.currentTimeMillis() - START_TIME.get()) ;
Print.tco( target + " 后钩被执行, 任务执行时长（ms）：" + time);
//清空本地变量
START_TIME.remove();
}
};
for (int i = 1; i <= 5; i++)
{
pool.execute(new TargetTask());
}
//等待10秒
sleepSeconds(10);
Print.tco("关闭线程池");
pool.shutdown();
}
// 省略其他
}
运行以上示例代码，输出的结果如下：
[pool-1-thread-3]：TargetTask{task-5}前钩被执行
[pool-1-thread-1]：TargetTask{task-1}前钩被执行
[pool-1-thread-2]：TargetTask{task-2}前钩被执行
[pool-1-thread-2]：任务：task-2 doing
[pool-1-thread-1]：任务：task-1 doing
[pool-1-thread-3]：任务：task-5 doing
[pool-1-thread-3]：task-5 运行结束.
[pool-1-thread-2]：task-2 运行结束.
...
[pool-1-thread-3]：TargetTask{task-4} 后钩被执行, 任务执行时长（ms）：515
[main]：关闭线程池
[pool-1-thread-3]：调度器已经终止!
示例代码在beforeExecute（前钩子）方法中通过startTime线程局部变量暂存了异步目标任务（如Runnable实例）的开始执行时间（起始时间），在afterExecute（后钩子）方法中通过startTime线程局部变量获取了之前暂存的起始时间，然后计算与系统当前时间（结束时间）之间的时间差，从而得出异步目标任务的执行时长。
（九）线程池的拒绝策略
在线程池的任务缓存队列为有界队列（有容量限制的队列）的时候，如果队列满了，提交任务到线程池的时候就会被拒绝。
总体来说，任务被拒绝有两种情况：
（1）线程池已经被关闭。
（2）工作队列已满且maximumPoolSize已满。
无论以上哪种情况任务被拒绝，线程池都会调用RejectedExecutionHandler实例的rejectedExecution方法。RejectedExecutionHandler是拒绝策略的接口，JUC为该接口提供了以下几种实现：
·AbortPolicy：拒绝策略。
·DiscardPolicy：抛弃策略。
·DiscardOldestPolicy：抛弃最老任务策略。
·CallerRunsPolicy：调用者执行策略。
·自定义策略。
（1）AbortPolicy
使用该策略时，如果线程池队列满了，新任务就会被拒绝，并且抛出RejectedExecutionException异常。该策略是线程池默认的拒绝策略。
（2）DiscardPolicy
该策略是AbortPolicy的Silent（安静）版本，如果线程池队列满了，新任务就会直接被丢掉，并且不会有任何异常抛出。
（3）DiscardOldestPolicy
抛弃最老任务策略，也就是说如果队列满了，就会将最早进入队列的任务抛弃，从队列中腾出空间，再尝试加入队列。因为队列是队尾进队头出，队头元素是最老的，所以每次都是移除队头元素后再尝试入队。
（4）CallerRunsPolicy
调用者执行策略。在新任务被添加到线程池时，如果添加失败，那么提交任务线程会自己去执行该任务，不会使用线程池中的线程去执行新任务。
在以上4种内置策略中，线程池默认的拒绝策略为AbortPolicy，如果提交的任务被拒绝，线程池就会抛出RejectedExecutionException异常，该异常是非受检异常（运行时异常），很容易忘记捕获。如果关心任务被拒绝的事件，需要在提交任务时捕获RejectedExecutionException异常。
（5）自定义策略
如果以上拒绝策略都不符合需求，那么可自定义一个拒绝策略，实现RejectedExecutionHandler接口的rejectedExecution方法即可。
下面给出一个自定义拒绝策略的例子，代码如下：
//自定义拒绝策略
public static class CustomIgnorePolicy implements RejectedExecutionHandler {
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
// 可做日志记录等
Print.tco(r + " rejected; " + " - getTaskCount: " + e.getTaskCount());
}
}
@org.junit.Test
public void testCustomIgnorePolicy() {
int corePoolSize = 2; //核心线程数
int maximumPoolSize = 4; //最大线程数
long keepAliveTime = 10;
TimeUnit unit = TimeUnit.SECONDS;
//最大排队任务数
BlockingQueue<Runnable> workQueue = new ArrayBlockingQueue<>(2);
//线程工厂(省略类，同上)
ThreadFactory threadFactory = new SimpleThreadFactory();
//拒绝和异常策略
RejectedExecutionHandler policy = new CustomIgnorePolicy();
ThreadPoolExecutor pool = new ThreadPoolExecutor(
corePoolSize,
maximumPoolSize,
keepAliveTime, unit,
workQueue,
threadFactory,
policy);
// 预启动所有核心线程
pool.prestartAllCoreThreads();
for (int i = 1; i <= 10; i++) {
pool.execute(new TargetTask());
}
//等待10秒
sleepSeconds(10);
Print.tco("关闭线程池");
pool.shutdown();
}
运行以上代码，大致结果如下：
[main]：创建一个线程，名称为：simpleThread-1
[main]：创建一个线程，名称为：simpleThread-2
[main]：创建一个线程，名称为：simpleThread-3
[simpleThread-1]：任务：task-1 doing
[simpleThread-2]：任务：task-2 doing
[main]：创建一个线程，名称为：simpleThread-4
[simpleThread-3]：任务：task-3 doing
[simpleThread-4]：任务：task-6 doing
[main]：TargetTask{task-7} rejected; - getTaskCount: 6
[main]：TargetTask{task-8} rejected; - getTaskCount: 6
[main]：TargetTask{task-9} rejected; - getTaskCount: 6
[main]：TargetTask{task-10} rejected; - getTaskCount: 6
[simpleThread-1]：task-1 运行结束.
[simpleThread-2]：task-2 运行结束.
[simpleThread-1]：任务：task-4 doing
[simpleThread-2]：任务：task-5 doing
[simpleThread-2]：task-5 运行结束.
[simpleThread-4]：task-6 运行结束.
[simpleThread-3]：task-3 运行结束.
[simpleThread-1]：task-4 运行结束.
[main]：关闭线程池
（十）线程池的优雅关闭
一般情况下，线程池启动后建议手动关闭。在介绍线程池的优雅关闭之前，我们先了解一下线程池的状态。线程池总共存在5种状态，定义在ThreadPoolExecutor类中，具体代码如下：
// 省略import
public class ThreadPoolExecutor extends AbstractExecutorService {
// runState is stored in the high-order bits
private static final int RUNNING = -1 << COUNT_BITS;
private static final int SHUTDOWN = 0 << COUNT_BITS;
private static final int STOP = 1 << COUNT_BITS;
private static final int TIDYING = 2 << COUNT_BITS;
private static final int TERMINATED = 3 << COUNT_BITS;
// 省略其他
}
线程池的5种状态具体如下：
（1）RUNNING：线程池创建之后的初始状态，这种状态下可以执行任务。
（2）SHUTDOWN：该状态下线程池不再接受新任务，但是会将工作队列中的任务执行完毕。
（3）STOP：该状态下线程池不再接受新任务，也不会处理工作队列中的剩余任务，并且将会中断所有工作线程。
（4）TIDYING：该状态下所有任务都已终止或者处理完成，将会执行terminated()钩子方法。
（5）TERMINATED：执行完terminated()钩子方法之后的状态。
线程池的状态转换规则如下图所示：
优雅地关闭线程池主要涉及的方法有3个：
（1）shutdown：是JUC提供的一个有序关闭线程池的方法，此方法会等待当前工作队列中的剩余任务全部执行完成之后，才会执行关闭，但是此方法被调用之后线程池的状态转为SHUTDOWN，线程池不会再接收新的任务。
（2）shutdownNow：是JUC提供的一个立即关闭线程池的方法，此方法会打断正在执行的工作线程，并且会清空当前工作队列中的剩余任务，返回的是尚未执行的任务。
（3）awaitTermination：等待线程池完成关闭。在调用线程池的shutdown()与shutdownNow()方法时，当前线程会立即返回，不会一直等待直到线程池完成关闭。如果需要等到线程池关闭完成，可以调用awaitTermination()方法。
1.shutdown()方法的原理
shutdown()方法的源码大致如下：
public void shutdown()
{
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try
{
// 检查权限
checkShutdownAccess();
// 设置线程池状态
advanceRunState(SHUTDOWN);
// 中断空闲线程
interruptIdleWorkers();
// 钩子函数，主要用于清理一些资源
onShutdown();
} finally
{
mainLock.unlock();
}
tryTerminate();
}
Shutdown()方法首先加锁，其次检查调用者是否用于执行线程池关闭的Java Security权限。接着shutdown()方法会将线程池状态变为SHUTDOWN，在这之后线程池不再接受提交的新任务。此时如果还继续往线程池提交任务，将会使用线程池拒绝策略响应，默认的拒绝策略将会使用ThreadPoolExecutor.AbortPolicy，接收新任务时会抛出RejectedExecutionException异常。
2.shutdownNow()方法的原理
shutdownNow()方法的源码大致如下：
public List<Runnable> shutdownNow()
{
List<Runnable> tasks;
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try
{
// 检查状态
checkShutdownAccess();
// 将线程池状态变为 STOP
advanceRunState(STOP);
// 中断所有线程，包括工作线程以及空闲线程
interruptWorkers();
// 丢弃工作队列中的剩余任务
tasks = drainQueue();
} finally
{
mainLock.unlock();
}
tryTerminate();
return tasks;
}
shutdownNow()方法将会把线程池状态设置为STOP，然后中断所有线程（包括工作线程以及空闲线程），最后清空工作队列，取出工作队列所有未完成的任务返回给调用者。与有序的shutdown()方法相比，shutdownNow()方法比较粗暴，直接中断工作线程。不过这里需要注意的是，中断线程并不代表线程立刻结束，只是通过工作线程的interrupt()实例方法设置了中断状态，这里需要用户程序主动配合线程进行中断操作。
3.awaitTermination()方法的使用
调用了线程池的shutdown()与shutdownNow()方法之后，用户程序都不会主动等待线程池关闭完成，如果需要等待线程池关闭完成，需要调用awaitTermination()进行主动等待。调用方法大致如下：
threadPool.shutdown();
try {
//一直等待，直到线程池完成关闭
while (!threadPool.awaitTermination(60,TimeUnit.SECONDS)){
System.out.println("线程池任务还未执行结束");
}
} catch (InterruptedException e) {
e.printStackTrace();
}
如果线程池完成关闭，awaitTermination()方法将会返回true，否则当等待时间超过指定时间后将会返回false。如果需要调用awaitTermination()，建议不是永久等待，而是设置一定重试次数。
下面的代码参考了阿里巴巴著名的分布式框架Dubbo框架中线程池关闭源码中的部分代码：
if(!threadPool.isTerminated())
{
try
{
for (int i = 0; i < 1000; i++) //循环关闭1000次，每次等待10毫秒
{
if (threadPool.awaitTermination(10, TimeUnit.MILLISECONDS))
{
break;
}
threadPool.shutdownNow();
}
} catch (InterruptedException e)
{
System.err.println(e.getMessage());
} catch (Throwable e)
{
System.err.println(e.getMessage());
}
}
4.优雅地关闭线程池
大家可以结合shutdown()、shutdownNow()、awaitTermination()三个方法优雅地关闭一个线程池，大致分为以下几步：
（1）执行shutdown()方法，拒绝新任务的提交，并等待所有任务有序地执行完毕。
（2）执行awaitTermination(long timeout,TimeUnit unit)方法，指定超时时间，判断是否已经关闭所有任务，线程池关闭完成。
（3）如果awaitTermination()方法返回false，或者被中断，就调用shutDownNow()方法立即关闭线程池所有任务。
（4）补充执行awaitTermination(long timeout,TimeUnit unit)方法，判断线程池是否关闭完成。如果超时，就可以进入循环关闭，循环一定的次数（如1000次），不断关闭线程池，直到其关闭或者循环结束。
优雅地关闭线程池的参考代码如下：
// 省略import
public class ThreadUtil
{
public static void shutdownThreadPoolGracefully(ExecutorService threadPool)
{
// 若已经关闭则返回
if (!(threadPool instanceof ExecutorService) || threadPool.isTerminated())
{
return;
}
try
{
threadPool.shutdown(); //拒绝接受新任务
} catch (SecurityException e)
{
return;
} catch (NullPointerException e)
{
return;
}
try
{
// 等待60秒，等待线程池中的任务完成执行
if (!threadPool.awaitTermination(60, TimeUnit.SECONDS))
{
// 调用 shutdownNow() 方法取消正在执行的任务
threadPool.shutdownNow();
// 再次等待60秒，如果还未结束，可以再次尝试，或者直接放弃
if (!threadPool.awaitTermination(60, TimeUnit.SECONDS))
{
System.err.println("线程池任务未正常执行结束");
}
}
} catch (InterruptedException ie)
{
// 捕获异常，重新调用 shutdownNow() 方法
threadPool.shutdownNow();
}
// 仍然没有关闭，循环关闭1000次，每次等待10毫秒
if (!threadPool.isTerminated())
{
try
{
for (int i = 0; i < 1000; i++)
{
if (threadPool.awaitTermination(10,TimeUnit.MILLISECONDS))
{
break;
}
threadPool.shutdownNow();
}
} catch (InterruptedException e)
{
System.err.println(e.getMessage());
} catch (Throwable e)
{
System.err.println(e.getMessage());
}
}
}
// 省略不相干代码
}
5.注册JVM钩子函数自动关闭线程池
如果使用了线程池，可以在JVM中注册一个钩子函数，在JVM进程关闭之前，由钩子函数自动将线程池优雅地关闭，以确保资源正常释放。
下面的例子使用JVM钩子函数关闭了一个定义在ThreadUtil辅助类中用于执行定时、顺序任务的线程池，具体代码如下：
// 省略import
public class ThreadUtil
{
//懒汉式单例创建线程池：用于执行定时、顺序任务
static class SeqOrScheduledTargetThreadPoolLazyHolder
{
//线程池：用于定时任务、顺序排队执行任务
static final ScheduledThreadPoolExecutor EXECUTOR =
new ScheduledThreadPoolExecutor( 1,
new CustomThreadFactory("seq"));
static
{
//注册JVM关闭时的钩子函数
Runtime.getRuntime().addShutdownHook(
new ShutdownHookThread("定时和顺序任务线程池",
new Callable<Void>()
{
@Override
public Void call() throws Exception
{
//优雅地关闭线程池
shutdownThreadPoolGracefully(EXECUTOR);
return null;
}
}));
}
}
// 省略不相干代码
}
（十一）Executors快捷创建线程池的潜在问题
1.使用Executors创建“固定数量的线程池”的潜在问题
使用newFixedThreadPool工厂方法创建“固定数量的线程池”的源码如下：
public static ExecutorService newFixedThreadPool(int nThreads)
{
return new ThreadPoolExecutor(
nThreads, // 核心线程数
nThreads, // 最大线程数
0L, // 线程最大空闲（Idle）时长
TimeUnit.MILLISECONDS, // 时间单位：毫秒
new LinkedBlockingQueue<Runnable>() //任务的排队队列，无界队列
);
}
newFixedThreadPool工厂方法返回一个ThreadPoolExecutor实例，该线程池实例的corePoolSize数量为参数nThread，其maximumPoolSize数量也为参数nThread，其workQueue属性的值为LinkedBlockingQueue()无界阻塞队列。
使用Executors创建“固定数量的线程池”的潜在问题主要存在于其workQueue上，其值为LinkedBlockingQueue（无界阻塞队列）。如果任务提交速度持续大于任务处理速度，就会造成队列中大量的任务等待。如果队列很大，很有可能导致JVM出现OOM（Out Of Memory）异常，即内存资源耗尽。
2.使用Executors创建“单线程化线程池”的潜在问题
使用newSingleThreadExecutor工厂方法创建“单线程化线程池”的源码如下：
public static ExecutorService newSingleThreadExecutor()
{
return new FinalizableDelegatedExecutorService
(new ThreadPoolExecutor(
1, // 核心线程数
1, // 最大线程数
0L, // 线程最大空闲（Idle）时长
TimeUnit.MILLISECONDS, //时间单位：毫秒
new LinkedBlockingQueue<Runnable>() //无界队列
));
}
以上代码首先通过调用工厂方法newFixedThreadPool(1)创建一个数量为1的“固定大小的线程池”，然后使用FinalizableDelegatedExecutorService对该“固定大小的线程池”进行包装，这一层包装的作用是防止线程池的corePoolSize被动态地修改。
使用Executors创建的“单线程化线程池”与“固定大小的线程池”一样，其潜在问题仍然存在于其workQueue属性上，该属性的值为LinkedBlockingQueue（无界阻塞队列）。如果任务提交速度持续大于任务处理速度，就会造成队列大量阻塞。如果队列很大，很有可能导致JVM的OOM异常，甚至造成内存资源耗尽。
3.使用Executors创建“可缓存线程池”的潜在问题
使用newCachedThreadPool工厂方法创建“可缓存线程池”的源码如下：
public static ExecutorService newCachedThreadPool()
{
return new ThreadPoolExecutor(
0, // 核心线程数
Integer.MAX_VALUE, // 最大线程数
60L, // 线程最大空闲（Idle）时长
TimeUnit.MILLISECONDS, // 时间单位：毫秒
new SynchronousQueue<Runnable>() // 任务的排队队列，无界队列
);
}
以上代码通过调用ThreadPoolExecutor标准构造器创建一个核心线程数为0、最大线程数不设限制的线程池。所以，理论上“可缓存线程池”可以拥有无数个工作线程，即线程数量几乎无限制。“可缓存线程池”的workQueue为SynchronousQueue同步队列，这个队列类似于一个接力棒，入队出队必须同时传递，正因为“可缓存线程池”可以无限制地创建线程，不会有任务等待，所以才使用SynchronousQueue。当“可缓存线程池”有新任务到来时，新任务会被插入SynchronousQueue实例中，由于SynchronousQueue是同步队列，因此会在池中寻找可用线程来执行，若有可用线程则执行，若没有可用线程，则线程池会创建一个线程来执行该任务。
使用Executors创建的“可缓存线程池”的潜在问题存在于其最大线程数量不设限上。由于其maximumPoolSize的值为Integer.MAX_VALUE（非常大），可以认为可以无限创建线程，如果任务提交较多，就会造成大量的线程被启动，很有可能造成OOM异常，甚至导致CPU线程资源耗尽。
4.使用Executors创建“可调度线程池”的潜在问题
使用newScheduledThreadPool工厂方法创建“可调度线程池”的源码如下：
public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize)
{
return new ScheduledThreadPoolExecutor(corePoolSize);
}
Executors的newScheduledThreadPool工厂方法调用了ScheduledThreadPoolExecutor实现类的构造器，而ScheduledThreadPoolExecutor继承了ThreadPoolExecutor的普通线程池类，在其构造器内部进一步调用了该父类的构造器，具体的代码如下：
public ScheduledThreadPoolExecutor(int corePoolSize)
{
super(corePoolSize, // 核心线程数
Integer.MAX_VALUE, // 最大线程数
0, // 线程最大空闲（Idle）时长
NANOSECONDS, //时间单位
new DelayedWorkQueue() //任务的排队队列
);
}
以上代码创建了一个ThreadPoolExecutor实例，其corePoolSize为传递来的参数，maximumPoolSize为Integer.MAX_VALUE，表示线程数不设上限，其workQueue为一个DelayedWorkQueue实例，这是一个按到期时间升序排序的阻塞队列。使用Executors创建的“可缓存线程池”的潜在问题存在于其最大线程数量不设限上。由于其线程数量不设限，如果到期任务太多，就会导致CPU的线程资源耗尽。
总结
（1）FixedThreadPool和SingleThreadPool这两个工厂方法所创建的线程池，工作队列（任务排队的队列）的长度都为Integer.MAX_VALUE，可能会堆积大量的任务，从而导致OOM（即耗尽内存资源）。
（2）CachedThreadPool和ScheduledThreadPool这两个工厂方法所创建的线程池允许创建的线程数量为Integer.MAX_VALUE，可能会导致创建大量的线程，从而导致OOM。
虽然Executors工厂类提供了构造线程池的便捷方法，但是对于服务器程序而言，大家应该杜绝使用这些便捷方法，而是直接使用线程池ThreadPoolExecutor的构造器，从而有效避免由于使用无界队列可能导致的内存资源耗尽，或者由于对线程个数不做限制而导致的CPU资源耗尽等问题。所以，大厂的编程规范都不允许使用Executors创建线程池，而是要求使用标准构造器ThreadPoolExecutor创建线程池。
二、确定线程池的线程数
（一）线程池分类
使用线程池的好处：
（1）降低资源消耗：线程是稀缺资源，如果无限制地创建，不仅会消耗系统资源，还会降低系统的稳定性，通过重复利用已创建的线程可以降低线程创建和销毁造成的消耗。
（2）提高响应速度：当任务到达时，可以不需要等待线程创建就能立即执行。
（3）提高线程的可管理性：线程池提供了一种限制、管理资源的策略，维护一些基本的线程统计信息，如已完成任务的数量等。通过线程池可以对线程资源进行统一的分配、监控和调优。虽然使用线程池的好处很多，但是如果其线程数配置得不合理，不仅可能达不到预期效果，反而可能降低应用的性能。
按照任务类型对线程池进行分类
（1）IO密集型任务此类任务主要是执行IO操作。由于执行IO操作的时间较长，导致CPU的利用率不高，这类任务CPU常处于空闲状态。Netty的IO读写操作为此类任务的典型例子。
（2）CPU密集型任务此类任务主要是执行计算任务。由于响应时间很快，CPU一直在运行，这种任务CPU的利用率很高。
（3）混合型任务此类任务既要执行逻辑计算，又要进行IO操作（如RPC调用、数据库访问）。相对来说，由于执行IO操作的耗时较长（一次网络往返往往在数百毫秒级别），这类任务的CPU利用率也不是太高。Web服务器的HTTP请求处理操作为此类任务的典型例子。
一般情况下，针对以上不同类型的异步任务需要创建不同类型的线程池，并进行针对性的参数配置。
（二）IO密集型
由于IO密集型任务的CPU使用率较低，导致线程空余时间很多，因此通常需要开CPU核心数两倍的线程。当IO线程空闲时，可以启用其他线程继续使用CPU，以提高CPU的使用率。
ThreadUtil类中为IO密集型任务创建了一个简单的参考线程池，具体代码如下：
// 省略import
public class ThreadUtil
{
//CPU核数
private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();
//IO处理线程数
private static final int IO_MAX = Math.max(2, CPU_COUNT * 2);
/**
* 空闲保活时限，单位秒
*/
private static final int KEEP_ALIVE_SECONDS = 30;
/**
* 有界队列size
*/
private static final int QUEUE_SIZE = 128;
//懒汉式单例创建线程池：用于IO密集型任务
private static class IoIntenseTargetThreadPoolLazyHolder
{
//线程池： 用于IO密集型任务
private static final ThreadPoolExecutor EXECUTOR = new ThreadPoolExecutor(
IO_MAX, //CPU核数*2
IO_MAX, //CPU核数*2
KEEP_ALIVE_SECONDS,
TimeUnit.SECONDS,
new LinkedBlockingQueue(QUEUE_SIZE),
new CustomThreadFactory("io"));
static
{
EXECUTOR.allowCoreThreadTimeOut(true);
//JVM关闭时的钩子函数
Runtime.getRuntime().addShutdownHook(
new ShutdownHookThread("IO密集型任务线程池",
new Callable<Void>()
{
@Override
public Void call() throws Exception
{
//优雅地关闭线程池
shutdownThreadPoolGracefully(EXECUTOR);
return null;
}
}));
}
}
// 省略不相干代码
}
在以上参考代码中，有以下几个要点需要特别说明：
（1）为参考的IO线程池调用了allowCoreThreadTimeOut(…)方法，并且传入了参数true，则keepAliveTime参数所设置的Idle超时策略也将被应用于核心线程，当池中的线程长时间空闲时，可以自行销毁。
（2）使用有界队列缓冲任务而不是无界队列，如果128太小，可以根据具体需要进行增大，但是不能使用无界队列。
（3）corePoolSize和maximumPoolSize保持一致，使得在接收到新任务时，如果没有空闲工作线程，就优先创建新的线程去执行新任务，而不是优先加入阻塞队列，等待现有工作线程空闲后再执行。
（4）使用懒汉式单例模式创建线程池，如果代码没有用到此线程池，就不会立即创建。
（5）使用JVM关闭时的钩子函数优雅地自动关闭线程池。
（三）CPU密集型
CPU密集型任务也叫计算密集型任务，其特点是要进行大量计算而需要消耗CPU资源，比如计算圆周率、对视频进行高清解码等。CPU密集型任务虽然也可以并行完成，但是并行的任务越多，花在任务切换的时间就越多，CPU执行任务的效率就越低，所以要最高效地利用CPU，CPU密集型任务并行执行的数量应当等于CPU的核心数。
比如4个核心的CPU，通过4个线程并行地执行4个CPU密集型任务，此时的效率是最高的。但是如果线程数远远超出CPU核心数量，就需要频繁地切换线程，线程上下文切换时需要消耗时间，反而会使得任务效率下降。因此，对于CPU密集型的任务来说，线程数等于CPU数就行。
ThreadUtil类中为CPU密集型任务创建了一个简单的参考线程池，具体代码如下：
// 省略import
public class ThreadUtil
{
//CPU核数
private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();
private static final int MAXIMUM_POOL_SIZE = CPU_COUNT;
//懒汉式单例创建线程池：用于CPU密集型任务
private static class CpuIntenseTargetThreadPoolLazyHolder
{
//线程池：用于CPU密集型任务
private static final ThreadPoolExecutor EXECUTOR = new ThreadPoolExecutor(
MAXIMUM_POOL_SIZE,
MAXIMUM_POOL_SIZE,
KEEP_ALIVE_SECONDS,
TimeUnit.SECONDS,
new LinkedBlockingQueue(QUEUE_SIZE),
new CustomThreadFactory("cpu"));
static
{
EXECUTOR.allowCoreThreadTimeOut(true);
//JVM关闭时的钩子函数
Runtime.getRuntime().addShutdownHook(
new ShutdownHookThread("CPU密集型任务线程池",
new Callable<Void>()
{
@Override
public Void call() throws Exception
{
//优雅地关闭线程池
shutdownThreadPoolGracefully(EXECUTOR);
return null;
}
}));
}
}
// 省略不相干代码
}
（四）混合型
混合型任务既要执行逻辑计算，又要进行大量非CPU耗时操作（如RPC调用、数据库访问、网络通信等），所以混合型任务CPU的利用率不是太高，非CPU耗时往往是CPU耗时的数倍。比如在Web应用中处理HTTP请求时，一次请求处理会包括DB操作、RPC操作、缓存操作等多种耗时操作。一般来说，一次Web请求的CPU计算耗时往往较少，大致在100～500毫秒，而其他耗时操作会占用500～1000毫秒，甚至更多的时间。
在为混合型任务创建线程池时，如何确定线程数呢？业界有一个比较成熟的估算公式，具体如下：
**最佳线程数目 = (线程等待时间 / 线程CPU时间之比 + 1) * CPU核数**
通过公式可以看出：等待时间所占的比例越高，需要的线程就越多；CPU耗时所占的比例越高，需要的线程就越少。
以上公式的估算结果仅仅是理论最佳值，在生产环境中的使用也仅供参考。生产环境需要结合系统网络环境和硬件情况（CPU、内存、硬盘读写速度）不断尝试，获取一个符合实际的线程数值。
hreadUtil类中为混合型任务创建了一个简单的参考线程池，具体代码如下：
// 省略import
public class ThreadUtil
{
private static final int MIXED_MAX = 128; //最大线程数
private static final String MIXED_THREAD_AMOUNT = "mixed.thread.amount";
//懒汉式单例创建线程池：用于混合型任务
private static class MixedTargetThreadPoolLazyHolder
{
//首先从环境变量 mixed.thread.amount 中获取预先配置的线程数
//如果没有对 mixed.thread.amount进行配置，就使用常量 MIXED_MAX作为线程数
private static final int max = (null != System.getProperty(MIXED_THREAD_AMOUNT)) ?
Integer.parseInt(System.getProperty(MIXED_THREAD_AMOUNT)) : MIXED_MAX;
//线程池：用于混合型任务
private static final ThreadPoolExecutor EXECUTOR = new ThreadPoolExecutor(
max,
max,
KEEP_ALIVE_SECONDS,
TimeUnit.SECONDS,
new LinkedBlockingQueue(QUEUE_SIZE),
new CustomThreadFactory("mixed"));
static
{
EXECUTOR.allowCoreThreadTimeOut(true);
//JVM关闭时的钩子函数
Runtime.getRuntime().addShutdownHook(
new ShutdownHookThread("混合型任务线程池", new Callable<Void>()
{
@Override
public Void call() throws Exception
{
//优雅地关闭线程池
shutdownThreadPoolGracefully(EXECUTOR);
return null;
}
}));
}
}
// 省略不相干代码
}