本文详细解析了ThreadPoolExecutor中核心线程数、线程创建时机、核心线程销毁机制、keepAliveTime设置的影响，以及优化线程池的实践建议，包括线程池初始化、线程池大小调整和异常处理技巧。
我上一篇文章《多线程之线程池使用》简单介绍了线程池的原理和使用。但线程池在使用过程中如果参数配置错误，很容易引发线程切换过渡或OOM。所以这篇文章主要介绍ThreadPoolExecutor设值的一些技术细节，并且给出几个常用的实践建议。
corePoolSize=0会如何
我上一个版本的描述是线程池刚创建是没有线程的，新任务到来不会立马启动，只有当调用execute() 方法添加一个任务时，线程池就会判断核心线程数corePoolSize是否已经达最大值，没有则创建线程执行任务，大于corePoolSize时就将任务塞到队列（workQueue ）等待执行，当队列被塞满，会再次创建非核心线程执行任务，直到线程数达到maximumPoolSize，再进入的任务则会被拒绝策略 RejectedExecutionHandler 处理。
按照上面的描述，如果corePoolSize=0，则会判断等待队列的容量，如果还有容量，则排队，并且不会创建新的线程。
基本上大部分博客也都是这样介绍的。但实这要看JDK版本，1.6之前确实是如此，但1.6之后代码的实现方式就变了。既然调用execute()方法时会判断corePoolSize，那我们就先来看看execute()方法源码：
public void execute(Runnable command) {
if (command == null)
throw new NullPointerException();
int c = ctl.get();
// 先判断当前池中线程数是否小于corePoolSize
if (workerCountOf(c) < corePoolSize) {
// 小于则尝试创建新的线程执行该任务
if (addWorker(command, true))
return;
c = ctl.get();
}
// 尝试添加到等待队列。
if (isRunning(c) && workQueue.offer(command)) {
int recheck = ctl.get();
if (! isRunning(recheck) && remove(command))
reject(command);
/*重点看着一行，如果当前池内线程数为0，则创建一个firstTask为null的worker，这个worker会从等待队列中获取任务并执行。 */
else if (workerCountOf(recheck) == 0)
addWorker(null, false);
}
else if (!addWorker(command, false))
reject(command);
}
private boolean addWorker(Runnable firstTask, boolean core)
在1.6版本之后，如果corePoolSize=0，提交任务时如果线程池为空，则会立即创建一个线程来执行任务（先排队再获取）；如果提交任务的时候，线程池不为空，则先在等待队列中排队，只有队列满了才会创建新线程。
所以，优化在于，在队列没有满的这段时间内，会有一个线程在消费提交的任务；1.6之前的实现是，必须等队列满了之后，才开始消费。
线程池创建之后，是否立即建核心线程
普通玩家：从上面的源码可以看出，在刚刚创建ThreadPoolExecutor的时候，线程并不会立即启动，而是要等到有任务提交时才会启动
高端玩家：预先调用prestartCoreThread()或prestartAllCoreThreads()方法
/*
预先创建corePoolSize数量的核心线程
*/
public boolean prestartCoreThread() {
return workerCountOf(ctl.get()) < corePoolSize &&
addWorker(null, true);
}
/*
预先创建一个核心线程
*/
public int prestartAllCoreThreads() {
int n = 0;
while (addWorker(null, true))
++n;
return n;
}
初始化线程池时是可以预先创建线程的，初始化线程池后，调用prestartAllCoreThreads()方法，即可预先创建corePoolSize数量的核心线程。estartCoreThread()同样可以预先创建线程，只不过该方法只会与创建1条线程
为什么核心线程不会销毁
我们知道只有当调用execute() 方法添加一个任务时，线程池才会创建线程执行任务，里面的run()方法才会跑起来。而run方法里面又是实现runWorker(this)，再看看runWorker里面的源码
public void run() {
runWorker(this);
}
// --------------------------------------------------------------------------
final void runWorker(Worker w) {
// 获取当前线程
Thread wt = Thread.currentThread();
Runnable task = w.firstTask;
// 把Worker中的firstTask清空，因为下面要执行它
w.firstTask = null;
w.unlock();
boolean completedAbruptly = true;
try {
// 注意，while循环，这个循环不结束，Worker线程就不会终止，一直循环读取线程池任务队列中的任务并执行
while (task != null || (task = getTask()) != null) {
w.lock();
if ((runStateAtLeast(ctl.get(), STOP) ||
(Thread.interrupted() &&
runStateAtLeast(ctl.get(), STOP))) &&
!wt.isInterrupted())
wt.interrupt();
try {
beforeExecute(wt, task);
Throwable thrown = null;
try {
// 执行任务
task.run();
} catch (RuntimeException x) {
thrown = x; throw x;
} catch (Error x) {
thrown = x; throw x;
} catch (Throwable x) {
thrown = x; throw new Error(x);
} finally {
afterExecute(task, thrown);
}
} finally {
task = null;
w.completedTasks++;
w.unlock();
}
}
completedAbruptly = false;
} finally {
processWorkerExit(w, completedAbruptly);
}
}
//---------------------------------------------------------------------
/**
* 执行阻塞或定时等待任务 , 具体执行哪个需要根据当前的配置情况 ;
*
* 如果出现下面 4 中情况 , 任务必须退出 , 该方法返回 null :
* 1 . 任务数量超过线程池个数
* 2 . 线程池停止
* 3 . 线程池关闭 , 任务队列清空
* 4 . 任务等待时间超过空闲时间 , 需要被回收 ; 前提是该线程是非核心线程 ;
*
*/
private Runnable getTask() {
// timedOut标志位用来判断poll方法拿取任务是否超时了
boolean timedOut = false;
for (;;) {
int c = ctl.get();
// 获取当前线程池的运行状态
int rs = runStateOf(c);
// 如果线程池状态大于SHUTDOWN，则需要判断两种情况：
// 1. 线程池状态大于STOP，也就是线程池正在停止，一般是调用了shutdownNow()方法
// 2. 任务队列为空
// 如果在线程池至少为SHUTDOWN状态并且满足上面两个条件之一，则工作线程数wc减去1，然后直接返回null
if (rs >= SHUTDOWN && (rs >= STOP || workQueue.isEmpty())) {
decrementWorkerCount();
return null;
}
// 重新获取当前线程池的工作线程数
int wc = workerCountOf(c);
// 判断任务是否会被淘汰，如果 wc 大于 核心线程数 , 说明本线程是非核心线程
boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;
if ((wc > maximumPoolSize || (timed && timedOut))
&& (wc > 1 || workQueue.isEmpty())) {
if (compareAndDecrementWorkerCount(c))
return null;
continue;
}
try {
/*注意，核心代码在这里
这里进行了timed进行了判断
如果当前执行的线程数大于核心线程数 , 就是非核心线程
调用 poll 方法从任务队列中取任务, 如果超过 keepAliveTime 时间还取不到任务 , 非核心线程 空闲时间 超过了一定时间 , 此时需要回收
如果该线程是核心线程，那么就会调用 take 方法，而不是poll方法take方法是阻塞的
因此核心线程不会回收 , 非核心线程超过一定时间会被回收
*/
Runnable r = timed ?
workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
workQueue.take();
// 如果拿取到任务了，就直接返回给Worker处理
if (r != null)
return r;
timedOut = true;
} catch (InterruptedException retry) {
// 如果在阻塞的过程中发生了中断，那么将timedOut置为false，也进入到下一次循环中重试
timedOut = false;
}
}
}
每一个Worker在创建出来的时候，会调用它本身的run()方法，实现是runWorker(this)，这个实现的核心是一个while循环，这个循环不结束，Worker线程就不会终止，就是这个基本逻辑。
-
在这个while条件中，有个getTask()方法是核心中的核心，它所做的事情就是从等待队列中取出任务来执行：
-
如果没有达到corePoolSize，则创建的Worker在执行完它承接的任务后，会用workQueue.take()取任务、注意，这个接口是阻塞接口，如果取不到任务，Worker线程一直阻塞。
-
如果超过了corePoolSize，或者allowCoreThreadTimeOut，一个Worker在空闲了之后，会用workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS)取任务。注意，这个接口只阻塞等待keepAliveTime时间，超过这个时间返回null，则Worker的while循环执行结束，则被终止了。
核心线程是否可以销毁
是不是想着将核心线程数corePoolSize=0就不存在核心线程回收了。但这样很危险，如果你的队列未设置长度，所有来的任务都会往队列里面塞，分分钟给你OOM。
上一个问题‘为什么核心线程不会销毁’中提到getTask()方法，里面有一个allowsCoreThreadTimeOut值的判断
其实在JDK1.6之前，线程池确实会一直保持corePoolSize个核心线程，即使这些线程闲置了很长时间。但在JDK1.6之后就提供了方法allowsCoreThreadTimeOut()，如果传参为true，则允许闲置的核心线程被终止。
// 如果为false(默认值)，核心线程即使在空闲时也保持活动。如果为true，核心线程在keepAliveTime超时会被回收。
private volatile boolean allowCoreThreadTimeOut;
public boolean allowsCoreThreadTimeOut() {
return allowCoreThreadTimeOut;
}
所以你会发现当设置了最大队列数后，corePoolSize=0的效果，基本等同于allowsCoreThreadTimeOut=true && corePoolSize=1，只是实现方式不同而已
关闭线程池
public void shutdown() {
final ReentrantLock mainLock = this.mainLock;
// 上锁
mainLock.lock();
try {
// 查是否有关闭线程池的权限
checkShutdownAccess();
//将当前线程池的状态设置为SHUTDOWN
advanceRunState(SHUTDOWN);
//中断所有空闲线程
interruptIdleWorkers();
// 此方法在ThreadPoolExecutor中是空实现，具体实现在其子类ScheduledThreadPoolExecutor
onShutdown(); // hook for ScheduledThreadPoolExecutor
} finally {
// 释放锁
mainLock.unlock();
}
// 根据线程池状态来判断是否应该结束线程池
tryTerminate();
}
public List<Runnable> shutdownNow() {
List<Runnable> tasks;
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
//检查是否有关闭权限
checkShutdownAccess();
//设置线程池的状态为STOP
advanceRunState(STOP);
//中断所有的Worker线程
interruptWorkers();
//将任务队列中的任务移动到tasks集合中
tasks = drainQueue();
} finally {
mainLock.unlock();
}
tryTerminate();
return tasks;
}
shutdown或shutdownNow方法的原理都是遍历线程池的工作线程，然后逐个调用线程的interrupt方法来中断线程。所以无法响应中断的任务可能永远无法终止。两者的区别：
- shutdownNow将线程池的状态设置为STOP，然后尝试停止所有正在执行或暂停任务的线程，返回等待执行任务的列表。
- shutdown只是将线程池的状态设置为shutdown状态，等待所有已添加到线程池中的任务执行完再关闭(包括队列里的任务)，在提交的任务会走拒绝策略
好比你正在看当前博客，这时候收到shutdown，则把当前所有准备看的博客看完不再打开新的博客。收到shutdownNow则立即停止当前所有博客阅读也不准看新的。
keepAliveTime=0会怎么样
看ThreadPoolExecutor()的实现源码就能看到keepAliveTime必须大约等于0，小于0会直接抛IllegalArgumentException异常，当keepAliveTime=0表示非核心线程执行完立刻终止。还有一个特殊情况，那就是当allowsCoreThreadTimeOut=true时，keepAliveTime必须大于0，不然初始化报错，报错源码如下：
public void allowCoreThreadTimeOut(boolean value) {
if (value && keepAliveTime <= 0)
throw new IllegalArgumentException("Core threads must have nonzero keep alive times");
if (value != allowCoreThreadTimeOut) {
allowCoreThreadTimeOut = value;
if (value)
interruptIdleWorkers();
}
}
空闲线程过多会有什么问题
笼统地回答是会占用内存，我们分析一下占用了哪些内存。首先，比较普通的一部分，一个线程的内存模型：
- 虚拟机栈
- 本地方法栈
- 程序计数器
额外强调下面这几个内存占用，需要小心：
-
ThreadLocal：业务代码是否使用了ThreadLocal？就算没有，Spring框架中也大量使用了ThreadLocal。线程池保持空闲的核心线程是它的默认配置，一般来讲是没有问题的，因为它占用的内存一般不大。怕的就是业务代码中使用ThreadLocal缓存的数据过大又不清理。
-
局部变量：线程处于阻塞状态，肯定还有栈帧没有出栈，栈帧中有局部变量表，凡是被局部变量表引用的内存都不能回收。所以如果这个线程创建了比较大的局部变量，那么这一部分内存无法GC。
-
TLAB机制(thread local allocation buffer)：如果你的应用线程数处于高位，那么新的线程初始化可能因为Eden没有足够的空间分配TLAB而触发YoungGC。所以有必要估算一下Eden大小是否足够。如果不够的话，可能要谨慎地创建新线程，并且让空闲的线程终止；必要的时候，可能需要对JVM进行调参。
阻塞队列BlockingQueue的执行策略
主要有3种类型的BlockingQueue：无界队列队列大小无限制，常用的为无界的LinkedBlockingQueue，使用该队列做为阻塞队列时要尤其当心，当任务耗时较长时可能会导致大量新任务在队列中堆积最终导致OOM。我们的项目就遇到过这样的坑，618的时候QPS很高，请求量陡增，大量的任务被添加到这个无界LinkedBlockingQueue 中，导致cpu和内存飙升。
有界队列常用的有两类，一类是遵循FIFO原则的队列如ArrayBlockingQueue与有界的LinkedBlockingQueue，另一类是优先级队列如PriorityBlockingQueue。PriorityBlockingQueue中的优先级由任务的Comparator决定。
使用有界队列时队列大小需和线程池大小互相配合，线程池较小有界队列较大时可减少内存消耗，降低cpu使用率和上下文切换，但是可能会限制系统吞吐量。同步移交队列如果不希望任务在队列中等待而是希望将任务直接移交给工作线程，可使用SynchronousQueue作为等待队列。
SynchronousQueue不是一个真正的队列，而是一种线程之间移交的机制。要将一个元素放入SynchronousQueue中，必须有另一个线程正在等待接收这个元素。只有在使用无界线程池或者有饱和策略时才建议使用该队列。
怎么进行异常处理
很多代码的写法，我们都习惯按照常见范式去编写，而没有去思考为什么。比如：
- 如果我们使用execute()提交任务，我们一般要在Runable任务的代码加上try-catch进行异常处理。
executorService.execute(()->{
try{
int i=1/0;
}catch (Exception ex){
log.error(ex.getMessage());
}
});
- 如果我们使用submit()提交任务，我们一般要在主线程中，对Future.get()进行try-catch进行异常处理。
Callable callable=()->{return 1/0;};
Future future = executorService.submit(callable);
try {
//获取线程池里面的结果
Integer a= (Integer) future.get();
} catch (Exception e) {
//获取线程池里面的异常
log.error("future中获取异常"+e.getMessage());
}
但submit()底层实现依赖execute()，两者应该统一呀，为什么有差异呢？文章篇幅已经够长了，我就不做源码解析了，直接贴出答案，大家有兴趣可以自己去看看。
- 1.不论是用execute还是submit，都可以自己在业务代码上加try-catch进行异常处理。其实我们也是这样写的，因为这可以对不同业务场景的异常进行差异化处理。
- 2.如果是execute，还可以自定义线程池，继承ThreadPoolExecutor并复写其afterExecute(Runnable r, Throwable t)方法。或者实现Thread.UncaughtExceptionHandler接口，实现void uncaughtException(Thread t, Throwable e);方法，并将该handler传递给线程池的ThreadFactory。
// 1.创建一个自己定义的线程池,重写afterExecute方法
ExecutorService service = new ThreadPoolExecutor(1, 1, 0, TimeUnit.MILLISECONDS,new LinkedBlockingQueue(10)){
@Override
protected void afterExecute(Runnable r, Throwable t) {
super.afterExecute(r, t);
log.error("afterExecute里面获取到异常信息"+t.getMessage());
}
};
// 2.写一个自己的线程池工厂，实现UncaughtExceptionHandler接口
ThreadFactory factory = (Runnable r) -> {
//创建一个线程
Thread t = new Thread(r);
//给创建的线程设置UncaughtExceptionHandler对象 里面实现异常的默认逻辑
t.setDefaultUncaughtExceptionHandler((Thread thread1, Throwable e) -> {
log.error("线程工厂设置的exceptionHandler" + e.getMessage());
});
return t;
};
// 创建一个自己定义的线程池，使用自己定义的线程工厂
ExecutorService service = new ThreadPoolExecutor(1, 1, 0, TimeUnit.MILLISECONDS,new LinkedBlockingQueue(10),factory);
- 3.但是注意，afterExecute和UncaughtExceptionHandler都不适用submit。可以看FutureTask.run()不难发现，它自己对Throwable进行了try-catch，封装到了outcome属性，所以底层方法execute的Worker是拿不到异常信息的。
实践总结
- 【强制】使用ThreadPoolExecutor的构造函数声明线程池，避免使用Executors类的 newFixedThreadPool和newCachedThreadPool。
- 【强制】 创建线程或线程池时请指定有意义的线程名称，方便出错时回溯。即threadFactory参数要构造好。
- 【建议】建议不同类别的业务用不同的线程池。
- 【建议】CPU密集型任务(N+1)：这种任务消耗的主要是CPU资源，可以将线程数设置为N（CPU核心数）+1，比CPU核心数多出来的一个线程是为了防止线程偶发的缺页中断，或者其它原因导致的任务暂停而带来的影响。一旦任务暂停，CPU就会处于空闲状态，而在这种情况下多出来的一个线程就可以充分利用CPU的空闲时间。
- 【建议】I/O密集型任务(2N)：这种任务应用起来，系统会用大部分的时间来处理I/O交互，而线程在处理I/O的时间段内不会占用CPU来处理，这时就可以将CPU交出给其它线程使用。因此在I/O密集型任务的应用中，我们可以多配置一些线程，具体的计算方法是2N。
- 【建议】workQueue不要使用无界队列，尽量使用有界队列。避免大量任务等待，造成OOM。
- 【建议】如果是资源紧张的应用，使用allowsCoreThreadTimeOut可以提高资源利用率。
- 【建议】虽然使用线程池有多种异常处理的方式，但在任务代码中，使用try-catch最通用，也能给不同任务的异常处理做精细化。
- 【建议】对于资源紧张的应用，如果担心线程池资源使用不当，可以利用ThreadPoolExecutor的API实现简单的监控，然后进行分析和优化。
扫一扫
170万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
