我们知道,ExecutorService是一个抽象出线程池的一个接口,然后我们在使用线程池的时候,用的是Executors工具类中的一系列newCachedThreadPool() 等类似的方法,这些方法之间返回一个可以用的线程池。但其实这些方法都是在里面调用了一个类——ThreadPoolExecutor,这个是个Java线程池真正的实现类,Executors中的工具方法都是new了这个ThreadPoolExecutro类的对象,只是传了不同的参数进去而已。

所以有必要花点时间研究下这个实现类。

一、类声明:

继承了一个AbstractExecutorService,这个显然就是一个ExecutorService接口的基本抽象实现类。

二、线程池的处理机制

我们想想,要实现一个线程池,是不是有个集合来放线程;然后我们需要用这个线程池去解决我们提交的任务吧,那么如果任务提交得比线程池中的线程多怎么办,那么肯定有个队列来放这些还没来得及给线程运行的任务吧。

2.1 所以,线程池中主要就两个数据结构

一个放线程的集合:

可以看见注解,在对这个结合操作,访问的时候要先获得全局锁——mainLock。

而这个Worker是什么呢?其实就是一个线程的封装类,我们可以简单地把它看作是在线程池中用来提供服务的工作线程的代表,关于Worker这个重要的内部类待会在下面会详细介绍。

还有一个放任务的队列:

这显然是个生产者、消费者的模型吧,多个工作线程就是消费者,然后使用这个线程池的线程比如是main所在的主线程,就是生产者,因为负责submit任务(Runable或者是Callable)给线程池。既然是生产者消费者模型,那么就要考虑生产者和消费者的同步问题,所以这里用的是阻塞队列。

2.2 线程池的处理机制

我们用一张图片来看看线程池的大概处理流程先:

(图片来自:https://www.cnblogs.com/winner-0715/p/7388662.html)

这里的队列说的就是BlockQueue的workQueue也就是我们的任务队列。

由这个流程我们可以看到,有几个边界值:

  核心线程池的数量;

  任务队列的长度;

  最大线程池的数量。

任务队列大家都知道了,那么核心线程池和最大线程池呢??

2.3 在ThreadPoolExecutor类中有两个重要的类变量,

由注释可见,corePoolSize是需要维护的最小的存活的线程数量,可以这样理解,我们现在有一个线程池嘛,如果任务很少,就生产者没怎么生产任务,那么如果维护着很多活着的线程,不就很浪费内存嘛,所以当没任务的时候,这个corePoolSize就是要维持着的最少的或者的线程的数量。

注解还写了,如果你设置了allowCoreThreadTimeOut为true的话,那么这个最小的线程数量可能就为0了,因为这个参数的意思是允许coreThread有时间界限,就即使你的线程数量少于coreThreadPool的数量,但空闲时间(就是在堵塞任务队列堵住的时间)超过一个keepAliveTime(也是一个类变量)的时候,就可以继续减少线程的数量,直至0。

2.4 所以再来更细致地看看这个流程:

1、如果当前运行的线程少于corePoolSize,则创建新线程来执行任务(需要获得全局锁);——也就是说一开始直接就新建线程来执行任务
2、如果运行的线程等于或多于corePoolSize ,则将任务加入BlockingQueue;——大于这个corePool后,进来的任务就要在阻塞队列中排队了。
3、如果无法将任务加入BlockingQueue(队列已满并且正在运行的线程数量小于 maximumPoolSize),则创建新的线程来处理任务(需要获得全局锁
4、如果创建新线程将使当前运行的线程超出maxiumPoolSize(队列已满并且正在运行的线程数量大于或等于 maximumPoolSize),任务将被拒绝,并调用RejectedExecutionHandler.rejectedExecution()方法(线程池会抛出异常,告诉调用者"我不能再接受任务了");
线程池采取上述的流程进行设计是为了减少获取全局锁的次数。在线程池完成预热(当前运行的线程数大于或等于corePoolSize)之后,几乎所有的excute方法调用都执行步骤2;

5、当一个线程完成任务时,它会从队列中取下一个任务来执行;
6、当一个线程无事可做(也就是在堵塞的workQueue哪里堵着),超过一定的时间(keepAliveTime)时,线程池会判断,如果当前运行的线程数大于 corePoolSize,那么这个线程就被停掉。所以线程池的所有任务完成后,它最终会收缩到 corePoolSize 的大小。(如果设置了allowCoreThreadTimeOut为true,就会停到0)

任务的管理是一件比较容易的事,复杂的是线程的管理,这会涉及线程数量、等待/唤醒、同步/锁、线程创建和死亡等问题。ThreadPoolExecutor与线程相关的几个成员变量是:keepAliveTime、allowCoreThreadTimeOut、poolSize、corePoolSize、maximumPoolSize,它们共同负责线程的创建和销毁。

三、在分析源码之前,还要看几个重要的常量还有一些和状态有关的常量

private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
private static final int COUNT_BITS = Integer.SIZE - 3;
private static final int CAPACITY = (1 << COUNT_BITS) - 1; // 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; // Packing and unpacking ctl
private static int runStateOf(int c) { return c & ~CAPACITY; }
private static int workerCountOf(int c) { return c & CAPACITY; }
private static int ctlOf(int rs, int wc) { return rs | wc; }

ctl这个AtomicInteger的功能很强大,其高3位用于维护线程池运行状态,低29位维护线程池中线程数量。这个是很重要的一个变量!!

然后由状态常量可以看见,线程池一共有五个状态

1、RUNNING:-1<<COUNT_BITS,即高3位为1,低29位为0,该状态的线程池会接收新任务,也会处理在阻塞队列中等待处理的任务

2、SHUTDOWN:0<<COUNT_BITS,即高3位为0,低29位为0,该状态的线程池不会再接收新任务,但还会处理已经提交到阻塞队列中等待处理的任务

3、STOP:1<<COUNT_BITS,即高3位为001,低29位为0,该状态的线程池不会再接收新任务,不会处理在阻塞队列中等待的任务,而且还会中断正在运行的任务

4、TIDYING:2<<COUNT_BITS,即高3位为010,低29位为0,所有任务都被终止了,workerCount为0,为此状态时还将调用terminated()方法

5、TERMINATED:3<<COUNT_BITS,即高3位为100,低29位为0,terminated()方法调用完成后变成此状态

这些状态均由int型表示,大小关系为 RUNNING<SHUTDOWN<STOP<TIDYING<TERMINATED,这个顺序基本上也是遵循线程池从 运行 到 终止这个过程。

3.1 下面的图体现了线程池的状态变化过程:

3.2 还有三个和状态相关的方法:

runStateOf(int c) 方法:c & 高3位为1,低29位为0的~CAPACITY,用于获取高3位保存的线程池状态

workerCountOf(int c)方法:c & 高3位为0,低29位为1的CAPACITY,用于获取低29位的线程数量

ctlOf(int rs, int wc)方法:参数rs表示runState,参数wc表示workerCount,即根据runState和workerCount打包合并成ctl

四、关键execute方法源码分析

这个可以说是线程池ThreadPoolExecutor的核心方法了,不管是线程池的submit还是Executor接口中的execute实现,都是调用这个execute方法。

现在就来分析这个方法,看源码和注解:

总得来说,可以大致分为三种情况,就像上面说的:1. 任务加进来时发现线程数小于corePoolSize;2. 任务加进来时发现线程数>corePoolSize但小于Max,就尝试把任务放进堵塞的workQueue,如果workQueue也满了的话,就新建线程来完成任务;任务加进来的时候,发现这个时候的线程数目大于maxPoolSize了,就交给拒绝机制去reject。

/**
* Executes the given task sometime in the future. The task
* may execute in a new thread or in an existing pooled thread.
* 在未来的某个时刻执行给定的任务。这个任务用一个新线程执行,或者用一个线程池中已经存在的线程执行
*
* If the task cannot be submitted for execution, either because this
* executor has been shutdown or because its capacity has been reached,
* the task is handled by the current {@code RejectedExecutionHandler}.
* 如果任务无法被提交执行,要么是因为这个Executor已经被shutdown关闭,要么是已经达到其容量上限,任务会被当前的RejectedExecutionHandler处理
*
* @param command the task to execute
* @throws RejectedExecutionException at discretion of
* {@code RejectedExecutionHandler}, if the task
* cannot be accepted for execution RejectedExecutionException是一个RuntimeException
* @throws NullPointerException if {@code command} is null
*/
public void execute(Runnable command) {
if (command == null)
throw new NullPointerException(); /*
* Proceed in 3 steps:
*
* 1. If fewer than corePoolSize threads are running, try to
* start a new thread with the given command as its first
* task. The call to addWorker atomically checks runState and
* workerCount, and so prevents false alarms that would add
* threads when it shouldn't, by returning false.
* 如果运行的线程少于corePoolSize,尝试开启一个新线程去运行command,command作为这个线程的第一个任务
*
* 2. If a task can be successfully queued, then we still need
* to double-check whether we should have added a thread
* (because existing ones died since last checking) or that
* the pool shut down since entry into this method. So we
* recheck state and if necessary roll back the enqueuing if
* stopped, or start a new thread if there are none.
* 如果任务成功放入队列,我们仍需要一个双重校验去确认是否应该新建一个线程(因为可能存在有些线程在我们上次检查后死了) 或者 从我们进入这个方法后,pool被关闭了
* 所以我们需要再次检查state,如果线程池停止了需要回滚入队列,如果池中没有线程了,新开启 一个线程
*
* 3. If we cannot queue task, then we try to add a new
* thread. If it fails, we know we are shut down or saturated
* and so reject the task.
* 如果无法将任务入队列(可能队列满了),需要新开区一个线程(自己:往maxPoolSize发展)
* 如果失败了,说明线程池shutdown 或者 饱和了,所以我们拒绝任务
*/
int c = ctl.get(); /**
* 1、如果当前线程数少于corePoolSize(这里没有判断线程池的状态,可能是由于addWorker()操作已经包含对线程池状态的判断,如此处没加,而入workQueue前加了)
*/
if (workerCountOf(c) < corePoolSize) {
//addWorker()成功,返回,这个addWorker就是添加一个工作线程的意思,因为worker是理解成工作的线程嘛,也就是在workerSet里面添加一个worker,具体的参数到介绍addWorker方法再讲吧。
if (addWorker(command, true))
return; /**
* 没有成功addWorker(),再次获取c(凡是需要再次用ctl做判断时,都会再次调用ctl.get())
* 失败的原因可能是:
* 1、线程池已经shutdown,shutdown的线程池不再接收新任务
* 2、workerCountOf(c) < corePoolSize 判断后,由于并发,别的线程先创建了worker线程,导致workerCount>=corePoolSize
*/
c = ctl.get();
} /**
* 2、如果线程池RUNNING状态,且入队列成功
*/
if (isRunning(c) && workQueue.offer(command)) {
//如果到了这里的话,说明上面那if没进去或者是addWorker失败了,没进去说明线程数量大于corePoolSize了;失败了可能线程池状态shutDown,所以要判断线程池 //状态;失败了也可能是线程数量大于CorePoolSize了
//所以这里的if先判断线程池状态,再因为大于corePoolSize了,所以是上面说的情况2,要将新来的任务加入到堵塞队列workQueue中去。 int recheck = ctl.get();//再次校验位 /**
* 再次校验放入workerQueue中的任务是否能被执行、
* 这里主要考虑到,把任务加进了这个堵塞队列之后,可能线程池状态又变了,比如关闭了,所以要看double check
* 1、如果线程池不是运行状态了,这个时候会执行if里面的remove操作,其实就回滚刚刚的入队操作,从workQueue中删除任务,然后应该拒绝添加新任务,
* 2、如果线程池是运行状态,那么remove不会执行到,reject也不会执行到,然后就去下一步只要保证workerSet也就是线程池中有一个线程就好了。
* 3、如果线程池不是运行状态,然后从workQueue中删除任务失败(刚好有一个线程执行完毕,并消耗了这个任务),那也是去下一步确保还有线程执行任务(只要有一个就够了)
*/ //如果再次校验过程中,线程池不是RUNNING状态,并且remove(command)--workQueue.remove()成功,拒绝当前command
if (! isRunning(recheck) && remove(command))
reject(command);
//如果当前worker数量为0,通过addWorker(null, false)创建一个线程,其任务为null
//为什么只检查运行的worker数量是不是0呢?? 为什么不和corePoolSize比较呢??
//只保证有一个worker线程可以从queue中获取任务执行就行了??
//因为只要还有活动的worker线程,就可以消费workerQueue中的任务
else if (workerCountOf(recheck) == 0)
addWorker(null, false); //第一个参数为null,说明只为新建一个worker线程,没有指定firstTask
//第二个参数为true代表占用corePoolSize,false占用maxPoolSize
}
/**
* 3、如果线程池不是running状态 或者 无法入队列
* 尝试开启新线程,扩容至maxPoolSize,如果addWork(command, false)失败了,拒绝当前command
*/
else if (!addWorker(command, false))
//这个else呢,代表着要么不是running状态,这个时候执行addWorker肯定是失败的,addWofker里面会判断线程池状态,所以拒绝//任务;
//要么呢就是线程池是running状态,但加入任务的堵塞队列失败,说明堵塞队列也满了,也就是上面说的情况3,创建新工作worker来执行任务,如果这个失败,说明 //线程数目已经大于maxPoolSize了,就reject咯
reject(command);
}

execute(Runnable command)

参数:
    command    提交执行的任务,不能为空
执行流程:
1、如果线程池当前线程数量少于corePoolSize,则addWorker(command, true)创建新worker线程,如创建成功返回,如没创建成功,则执行后续步骤;
    addWorker(command, true)失败的原因可能是:
    A、线程池已经shutdown,shutdown的线程池不再接收新任务
    B、workerCountOf(c) < corePoolSize 判断后,由于并发,别的线程先创建了worker线程,导致workerCount>=corePoolSize
2、如果线程池还在running状态,将task加入workQueue阻塞队列中,如果加入成功,进行double-check,如果加入失败(可能是队列已满),则执行后续步骤;
    double-check主要目的是判断刚加入workQueue阻塞队列的task是否能被执行
    A、如果线程池已经不是running状态了,应该拒绝添加新任务,从workQueue中删除任务
    B、如果线程池是运行状态,或者从workQueue中删除任务失败(刚好有一个线程执行完毕,并消耗了这个任务),确保还有线程执行任务(只要有一个就够了)
3、如果线程池不是running状态 或者 无法入队列,尝试开启新线程,扩容至maxPoolSize,如果addWork(command, false)失败了,拒绝当前command

还有个要注意的就是关于shutdown和shutdownNow后,线程池分别的状态是SHUTDOWN和STOP,这两个状态都是不能接收新的任务了。在第一种情况,if里面没有判断线程池状态,但在addWorker里面会有判断,如果不是Running状态,那么会addWorker失败,然后进入下面的情况的if里面。

下面的if的话,如果状态不是running的话,会直接进入最后的else if里面,这里的addWorker肯定也失败,所以就会reject,也就是我们调用了shutdown和shutdownNow后确实是不会接受新的任务了。

看个流程图:

下面介绍在execute中用到的addWorker方法

五、addWorker()方法源码分析

5.1 认识Worker

在介绍这个方法之前,我们应该先去了解下内部类——Worker

worker封装的是线程池中的工作线程,为什么要封装呢?Worker类大体上管理着运行线程的中断状态 和 一些指标。

直接看源码吧,类前面的注解其实简单介绍了这个内部类的一些机制,像怎么用自身的AQS来控制中断等。

/**
* Class Worker mainly maintains interrupt control state for
* threads running tasks, along with other minor bookkeeping.
* This class opportunistically extends AbstractQueuedSynchronizer
* to simplify acquiring and releasing a lock surrounding each
* task execution. This protects against interrupts that are
* intended to wake up a worker thread waiting for a task from
* instead interrupting a task being run. We implement a simple
* non-reentrant mutual exclusion lock rather than use
* ReentrantLock because we do not want worker tasks to be able to
* reacquire the lock when they invoke pool control methods like
* setCorePoolSize. Additionally, to suppress interrupts until
* the thread actually starts running tasks, we initialize lock
* state to a negative value, and clear it upon start (in
* runWorker).
*
* Worker类大体上管理着运行线程的中断状态 和 一些指标
* Worker类投机取巧的继承了AbstractQueuedSynchronizer来简化在执行任务时的获取、释放锁
* 这样防止了中断在运行中的任务,只会唤醒(中断)在等待从workQueue中获取任务的线程
* 解释:
* 为什么不直接执行execute(command)提交的command,而要在外面包一层Worker呢??
* 主要是为了控制中断
* 用什么控制??
* 用AQS锁,当运行时上锁,就不能中断,TreadPoolExecutor的shutdown()方法中断前都要获取worker锁
* 只有在等待从workQueue中获取任务getTask()时才能中断
* worker实现了一个简单的不可重入的互斥锁,而不是用ReentrantLock可重入锁
* 因为我们不想让在调用比如setCorePoolSize()这种线程池控制方法时可以再次获取锁(重入)
* 解释:
* setCorePoolSize()时可能会interruptIdleWorkers(),在对一个线程interrupt时会要w.tryLock()
* 如果可重入,就可能会在对线程池操作的方法中中断线程,类似方法还有:
* setMaximumPoolSize()
* setKeppAliveTime()
* allowCoreThreadTimeOut()
* shutdown()
* 此外,为了让线程真正开始后才可以中断,初始化lock状态为负值(-1),在开始runWorker()时将state置为0,而state>=0才可以中断
*
*
* Worker继承了AQS,实现了Runnable,说明其既是一个可运行的任务,也是一把锁(不可重入)
*/
private final class Worker
extends AbstractQueuedSynchronizer
implements Runnable
{
/**
* This class will never be serialized, but we provide a
* serialVersionUID to suppress a javac warning.
*/
private static final long serialVersionUID = 6138294804551838833L; /** Thread this worker is running in. Null if factory fails. */
final Thread thread; //利用ThreadFactory和 Worker这个Runnable创建的线程对象 /** Initial task to run. Possibly null. 初始化后,可以给这个Worker工作线程的封装类一个任务,它会先执行这个任务也就是firstTask*/
Runnable firstTask; /** Per-thread task counter */
volatile long completedTasks; /**
* Creates with given first task and thread from ThreadFactory.
* @param firstTask the first task (null if none)
*/
Worker(Runnable firstTask) {
//设置AQS的同步状态private volatile int state,是一个计数器,大于0代表锁已经被获取
setState(-1); // inhibit interrupts until runWorker
// 在调用runWorker()前,禁止interrupt中断,在interruptIfStarted()方法中会判断 getState()>=0
this.firstTask = firstTask;//一定要区分,这个runnable和本身这个worker的Runnable接口没关系,Worker是一个工作线程的代表,而这个firstTask是一个用户提交的任务
this.thread = getThreadFactory().newThread(this); //根据当前worker创建一个线程对象
//当前worker本身就是一个runnable任务,也就是不会用参数的firstTask创建线程,而是调用当前worker.run()时调用firstTask.run()
} /** Delegates main run loop to outer runWorker */
public void run() {
runWorker(this); //runWorker()是ThreadPoolExecutor的方法 这也很容易理解嘛,在线程池中有个runWorker方法,就有点像调度各个工作线程去执行任务的感觉
} // Lock methods
//下面的方法很多是关于锁的实现
// The value 0 represents the unlocked state. 0代表“没被锁定”状态
// The value 1 represents the locked state. 1代表“锁定”状态 protected boolean isHeldExclusively() {
return getState() != 0;
} /**
* 尝试获取锁
* 重写AQS的tryAcquire(),AQS本来就是让子类来实现的
*/
protected boolean tryAcquire(int unused) {
//尝试一次将state从0设置为1,即“锁定”状态,但由于每次都是state 0->1,而不是+1,那么说明不可重入
//且state==-1时也不会获取到锁
if (compareAndSetState(0, 1)) {
setExclusiveOwnerThread(Thread.currentThread()); //设置exclusiveOwnerThread=当前线程
return true;
}
return false;
} /**
* 尝试释放锁
* 不是state-1,而是置为0
*/
protected boolean tryRelease(int unused) {
setExclusiveOwnerThread(null);
setState(0);
return true;
} //为啥不实现个Lock呢??
public void lock() { acquire(1); }
public boolean tryLock() { return tryAcquire(1); }
public void unlock() { release(1); }
public boolean isLocked() { return isHeldExclusively(); } /**
* 中断(如果运行)
* shutdownNow时会循环对worker线程执行
* 且不需要获取worker锁,即使在worker运行时也可以中断
*/
void interruptIfStarted() {
Thread t;
//如果state>=0、t!=null、且t没有被中断
//new Worker()时state==-1,说明不能中断
if (getState() >= 0 && (t = thread) != null && !t.isInterrupted()) {
try {
t.interrupt();
} catch (SecurityException ignore) {
}
}
}
}

5.2 了解了Worker后,就可以来看addWorker的具体实现了

addWorker说白了就是新建一个工作线程。

检查根据当前线程池的状态和给定的边界(core or maximum)是否可以创建一个新的worker
* 如果是这样的话,worker的数量做相应的调整,如果可能的话,创建一个新的worker并启动,参数中的firstTask作为worker的第一个任务
* 如果方法返回false,可能因为pool已经关闭或者调用过了shutdown
* 如果线程工厂创建线程失败,也会失败,返回false
* 如果线程创建失败,要么是因为线程工厂返回null,要么是发生了OutOfMemoryError

看addWorker()源码吧

/**
* Checks if a new worker can be added with respect to current
* pool state and the given bound (either core or maximum). If so,
* the worker count is adjusted accordingly, and, if possible, a
* new worker is created and started, running firstTask as its
* first task. This method returns false if the pool is stopped or
* eligible to shut down. It also returns false if the thread
* factory fails to create a thread when asked. If the thread
* creation fails, either due to the thread factory returning
* null, or due to an exception (typically OutOfMemoryError in
* Thread#start), we roll back cleanly.
* 检查根据当前线程池的状态和给定的边界(core or maximum)是否可以创建一个新的worker
* 如果是这样的话,worker的数量做相应的调整,如果可能的话,创建一个新的worker并启动,参数中的firstTask作为worker的第一个任务
* 如果方法返回false,可能因为pool已经关闭或者调用过了shutdown
* 如果线程工厂创建线程失败,也会失败,返回false
* 如果线程创建失败,要么是因为线程工厂返回null,要么是发生了OutOfMemoryError
*
* @param firstTask the task the new thread should run first (or
* null if none). Workers are created with an initial first task
* (in method execute()) to bypass(绕开) queuing when there are fewer
* than corePoolSize threads (in which case we always start one),
* or when the queue is full (in which case we must bypass queue).
* Initially idle threads are usually created via
* prestartCoreThread or to replace other dying workers.
*
* @param core if true use corePoolSize as bound, else
* maximumPoolSize. (A boolean indicator is used here rather than a
* value to ensure reads of fresh values after checking other pool
* state).
* @return true if successful
*/
private boolean addWorker(Runnable firstTask, boolean core) {
//外层循环,负责判断线程池状态
retry:
for (;;) {
int c = ctl.get();
int rs = runStateOf(c); //状态 // Check if queue empty only if necessary.
/**
* 线程池的state越小越是运行状态,runnbale=-1,shutdown=0,stop=1,tidying=2,terminated=3
* 1、如果线程池state已经至少是shutdown状态了
* 2、并且以下3个条件任意一个是false
* rs == SHUTDOWN (隐含:rs>=SHUTDOWN)false情况: 线程池状态已经超过shutdown,可能是stop、tidying、terminated其中一个,即线程池已经终止
* firstTask == null (隐含:rs==SHUTDOWN)false情况: firstTask不为空,rs==SHUTDOWN 且 firstTask不为空,return false,场景是在线程池已经shutdown后,还要添加新的任务,拒绝
* ! workQueue.isEmpty() (隐含:rs==SHUTDOWN,firstTask==null)false情况: workQueue为空,当firstTask为空时是为了创建一个没有任务的线程,再从workQueue中获取任务,如果workQueue已经为空,那么就没有添加新worker线程的必要了
* return false,即无法addWorker()
*/
//说那么多其实这里就从线程池状态什么的判断可以符合添加一个新的工作线程的条件吗,不行就直接return false下·
if (rs >= SHUTDOWN &&
! (rs == SHUTDOWN &&
firstTask == null &&
! workQueue.isEmpty()))
return false; //内层循环,负责worker数量+1
for (;;) {
int wc = workerCountOf(c); //worker数量 //如果worker数量>线程池最大上限CAPACITY(即使用int低29位可以容纳的最大值)
//或者( worker数量>corePoolSize 或 worker数量>maximumPoolSize ),即已经超过了给定的边界
if (wc >= CAPACITY ||
wc >= (core ? corePoolSize : maximumPoolSize))
return false; //调用unsafe CAS操作,使得worker数量+1,成功则跳出retry循环
if (compareAndIncrementWorkerCount(c))
break retry; //CAS worker数量+1失败,再次读取ctl
c = ctl.get(); // Re-read ctl //如果状态不等于之前获取的state,跳出内层循环,继续去外层循环判断 这里有点自旋改变WorkerCount的意思
if (runStateOf(c) != rs)
continue retry;
// else CAS failed due to workerCount change; retry inner loop
// else CAS失败时因为workerCount改变了,继续内层循环尝试CAS对worker数量+1
}
} /**
* worker数量+1成功的后续操作
* 添加到workers Set集合,并启动worker线程
*/
boolean workerStarted = false;
boolean workerAdded = false;
Worker w = null;
try {
final ReentrantLock mainLock = this.mainLock;
w = new Worker(firstTask); //1、设置worker这个AQS锁的同步状态state=-1
//2、将firstTask设置给worker的成员变量firstTask,意思是这个新工作线程的第一个任务
//3、使用worker自身这个runnable,调用ThreadFactory创建一个线程,并设置给worker的成员变量thread
final Thread t = w.thread;
if (t != null) {
mainLock.lock();//一般好像涉及到工作线程的操作都要用到全局锁
try {
//--------------------------------------------这部分代码是上锁的
// Recheck while holding lock.
// Back out on ThreadFactory failure or if
// shut down before lock acquired.
// 当获取到锁后,再次检查
int c = ctl.get();
int rs = runStateOf(c); //如果线程池在运行running<shutdown 或者 线程池已经shutdown,且firstTask==null(可能是workQueue中仍有未执行完成的任务,创建没有初始任务的worker线程执行)
//worker数量-1的操作在addWorkerFailed()
if (rs < SHUTDOWN ||
(rs == SHUTDOWN && firstTask == null)) {
if (t.isAlive()) // precheck that t is startable 线程已经启动,抛非法线程状态异常
throw new IllegalThreadStateException(); workers.add(w);//workers是一个HashSet<Worker> //设置最大的池大小largestPoolSize,workerAdded设置为true,这个东西就一个追踪线程池出现过的最大线程数的变量
int s = workers.size();
if (s > largestPoolSize)
largestPoolSize = s;
workerAdded = true;
}
//--------------------------------------------
}
finally {
mainLock.unlock();
} //如果往HashSet中添加worker成功,启动线程
if (workerAdded) {
t.start();
workerStarted = true;
}
}
} finally {
//如果启动线程失败
if (! workerStarted)
addWorkerFailed(w);//大概就是在Worker里面reomve这个Worker,并减少ctl中Worker的数量,然后再尝试终结线程池即调用tryTerminate()方法
}
return workerStarted;
}

解析:

addWorker(Runnable firstTask, boolean core)
参数:
    firstTask:    worker线程的初始任务,可以为空
    core:           true:将corePoolSize作为上限,false:将maximumPoolSize作为上限
addWorker方法有4种传参的方式:

1、addWorker(command, true)

2、addWorker(command, false)

3、addWorker(null, false)

4、addWorker(null, true)

在execute方法中就使用了前3种,结合这个核心方法进行以下分析
    第一个:线程数小于corePoolSize时,放一个需要处理的task进Workers Set。如果Workers Set长度超过corePoolSize,就返回false
    第二个:当队列被放满时,就尝试将这个新来的task直接放入Workers Set,而此时Workers Set的长度限制是maximumPoolSize。如果线程池也满了的话就返回false
    第三个:放入一个空的task进workers Set,长度限制是maximumPoolSize。这样一个task为空的worker在线程执行的时候会去任务队列里拿任务,这样就相当于创建了一个新的线程,只是没有马上分配任务
    第四个:这个方法就是放一个null的task进Workers Set,而且是在小于corePoolSize时,如果此时Set中的数量已经达到corePoolSize那就返回false,什么也不干。实际使用中是在prestartAllCoreThreads()方法,这个方法用来为线程池预先启动corePoolSize个worker等待从workQueue中获取任务执行
执行流程:
1、判断线程池当前是否为可以添加worker线程的状态,可以则继续下一步,不可以return false:
    A、线程池状态>shutdown,可能为stop、tidying、terminated,不能添加worker线程
    B、线程池状态==shutdown,firstTask不为空,不能添加worker线程,因为shutdown状态的线程池不接收新任务
    C、线程池状态==shutdown,firstTask==null,workQueue为空,不能添加worker线程,因为firstTask为空是为了添加一个没有任务的线程再从workQueue获取task,而workQueue为空,说明添加无任务线程已经没有意义
2、线程池当前线程数量是否超过上限(corePoolSize 或 maximumPoolSize),超过了return false,没超过则对workerCount+1,继续下一步
3、在线程池的ReentrantLock保证下,向Workers Set中添加新创建的worker实例,添加完成后解锁,并启动worker线程,如果这一切都成功了,return true,如果添加worker入Set失败或启动失败,调用addWorkerFailed()逻辑

看addWorker的流程图:

 六、runWorker()方法源码分析

我们可以看到,在addWorker方法中,如果增添workerCount成功,并添加新的Worker到workerSet成功后,就会启动这个Worker线程(实现了Runnable接口)的run方法,而这个run方法调用的是:

/** Delegates main run loop to outer runWorker  */
public void run() {
runWorker(this);
}

这个runWorker方法是线程池的一个方法,不是Worker类的。

现在就来研究下这个runWorker方法,其实也可以想到,这个方法做的大概就是不断地执行任务,先执行分配给Worker的firstTask(是个Runnable),然后再从workQueue中拿新的task(也是Runnable)来执行,就起着一个消费者调度方法的作用,而具体的Worker就是各个消费者。

6.1 看源码:

/**
* Main worker run loop. Repeatedly gets tasks from queue and
* executes them, while coping with a number of issues:
* 重复的从队列中获取任务并执行,同时应对一些问题:
*
* 1. We may start out with an initial task, in which case we
* don't need to get the first one. Otherwise, as long as pool is
* running, we get tasks from getTask. If it returns null then the
* worker exits due to changed pool state or configuration
* parameters. Other exits result from exception throws in
* external code, in which case completedAbruptly holds, which
* usually leads processWorkerExit to replace this thread.
* 我们可能使用一个初始化任务开始,即firstTask为null
* 然后只要线程池在运行,我们就从getTask()获取任务
* 如果getTask()返回null,则worker由于改变了线程池状态或参数配置而退出
* 其它退出因为外部代码抛异常了,这会使得completedAbruptly为true,这会导致在processWorkerExit()方法中替换当前线程
*
* 2. Before running any task, the lock is acquired to prevent
* other pool interrupts while the task is executing, and
* clearInterruptsForTaskRun called to ensure that unless pool is
* stopping, this thread does not have its interrupt set.
* 在任何任务执行之前,都需要对worker加锁去防止在任务运行时,其它的线程池中断操作
* clearInterruptsForTaskRun保证除非线程池正在stoping,线程不会被设置中断标示
*
* 3. Each task run is preceded by a call to beforeExecute, which
* might throw an exception, in which case we cause thread to die
* (breaking loop with completedAbruptly true) without processing
* the task.
* 每个任务执行前会调用beforeExecute(),其中可能抛出一个异常,这种情况下会导致线程die(跳出循环,且completedAbruptly==true),没有执行任务
* 因为beforeExecute()的异常没有cache住,会上抛,跳出循环
*
* 4. Assuming beforeExecute completes normally, we run the task,
* gathering any of its thrown exceptions to send to
* afterExecute. We separately handle RuntimeException, Error
* (both of which the specs guarantee that we trap) and arbitrary
* Throwables. Because we cannot rethrow Throwables within
* Runnable.run, we wrap them within Errors on the way out (to the
* thread's UncaughtExceptionHandler). Any thrown exception also
* conservatively causes thread to die.
* 假定beforeExecute()正常完成,我们执行任务
* 汇总任何抛出的异常并发送给afterExecute(task, thrown)
* 因为我们不能在Runnable.run()方法中重新上抛Throwables,我们将Throwables包装到Errors上抛(会到线程的UncaughtExceptionHandler去处理)
* 任何上抛的异常都会导致线程die
*
* 5. After task.run completes, we call afterExecute, which may
* also throw an exception, which will also cause thread to
* die. According to JLS Sec 14.20, this exception is the one that
* will be in effect even if task.run throws.
* 任务执行结束后,调用afterExecute(),也可能抛异常,也会导致线程die
* 根据JLS Sec 14.20,这个异常(finally中的异常)会生效
*
* The net effect of the exception mechanics is that afterExecute
* and the thread's UncaughtExceptionHandler have as accurate
* information as we can provide about any problems encountered by
* user code.
*
* @param w the worker
*/
final void runWorker(Worker w) {
Thread wt = Thread.currentThread();
Runnable task = w.firstTask;
w.firstTask = null;
w.unlock(); // allow interrupts
// new Worker()是state==-1,此处是调用Worker类的tryRelease()方法,将state置为0, 而interruptIfStarted()中只有state>=0才允许调用中断
boolean completedAbruptly = true; //是否“突然完成”,如果是由于异常导致的进入finally,那么completedAbruptly==true就是突然完成的
try {
/**
* 如果task不为null,或者从阻塞队列中getTask()不为null
*/
while (task != null || (task = getTask()) != null) {
w.lock(); //上锁,不是为了防止并发执行任务,为了在shutdown()时不终止正在运行的worker // If pool is stopping, ensure thread is interrupted;
// if not, ensure thread is not interrupted. This
// requires a recheck in second case to deal with
// shutdownNow race while clearing interrupt
/**
* clearInterruptsForTaskRun操作
* 确保只有在线程stoping时,才会被设置中断标示,否则清除中断标示。因为这个shutdown和shutdownnow都是通过线程的interrupt来实现的,所以如果是stop状态 * 就要确定线程是中断状态。
* 1、如果线程池状态>=stop,且当前线程没有设置中断状态,wt.interrupt()
* 2、如果一开始判断线程池状态<stop,但Thread.interrupted()为true,即线程已经被中断,又清除了中断标示,再次判断线程池状态是否>=stop
* 是,再次设置中断标示,wt.interrupt()
* 否,不做操作,清除中断标示后进行后续步骤
*/
if ((runStateAtLeast(ctl.get(), STOP) ||
(Thread.interrupted() &&
runStateAtLeast(ctl.get(), STOP))) &&
!wt.isInterrupted())
wt.interrupt(); //当前线程调用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); //这里就考验catch和finally的执行顺序了,因为要以thrown为参数
}
}
finally {
task = null; //task置为null
w.completedTasks++; //完成任务数+1
w.unlock(); //解锁
}
} completedAbruptly = false;
}
finally {
//处理worker的退出
processWorkerExit(w, completedAbruptly);
}
}

6.2 分析:

runWorker(Worker w)
执行流程:
1、Worker线程启动后,通过Worker类的run()方法调用runWorker(this)
2、执行任务之前,首先worker.unlock(),将AQS的state置为0,允许中断当前worker线程
3、开始执行firstTask,调用task.run(),在执行任务前会上锁wroker.lock(),在执行完任务后会解锁,为了防止在任务运行时被线程池一些中断操作中断
4、在任务执行前后,可以根据业务场景自定义beforeExecute() 和 afterExecute()方法
5、无论在beforeExecute()、task.run()、afterExecute()发生异常上抛,都会导致worker线程终止,进入processWorkerExit()处理worker退出的流程
6、如正常执行完当前task后,会通过getTask()从阻塞队列中获取新任务,当队列中没有任务,且获取任务超时,那么当前worker也会进入退出流程

6.3 流程图

 七、getTask()方法源码分析

在runWorker方法中,一个重要的步骤就是从workerQueue中去拿任务来执行,而相关的阻塞啊还有和生产者的同步关系都在这个getTask()方法里面了,现在就来看这个getTask方法。

getTask要考虑些情况,比如线程池如果调用了shutdown方法,那么就应该是线程池不能接受新的任务,如果还有任务就把剩下的任务执行完;但如果shutdown状态下,任务队列中没有任务了,那么就不用像普通情况一样等着,直接返回null;

如果调用了shutdownNow方法的话,就连剩下的任务都不执行了,直接返回null。

还有就是,太多空闲的工作线程,也就是工作线程数量大于coreThreadSize的时候,然后又在workQueue那里堵住很久的话,也返回null。

一般返回null的操作都伴随着工作线程数量CAS减一的操作,然后再在runWorker的最后进入processWorkerExit的操作,也就是真正把工作线程从workerSet中remove了。

7.1 看源码吧:

/**
* Performs blocking or timed wait for a task, depending on
* current configuration settings, or returns null if this worker
* must exit because of any of: 以下情况会返回null
* 1. There are more than maximumPoolSize workers (due to
* a call to setMaximumPoolSize).
* 超过了maximumPoolSize设置的线程数量(因为调用了setMaximumPoolSize())
* 2. The pool is stopped.
* 线程池被stop
* 3. The pool is shutdown and the queue is empty.
* 线程池被shutdown,并且workQueue空了
* 4. This worker timed out waiting for a task, and timed-out
* workers are subject to termination (that is,
* {@code allowCoreThreadTimeOut || workerCount > corePoolSize})
* both before and after the timed wait.
* 线程等待任务超时
*
* @return task, or null if the worker must exit, in which case
* workerCount is decremented
* 返回null表示这个worker要结束了,这种情况下workerCount-1
*/
private Runnable getTask() {
boolean timedOut = false; // Did the last poll() time out? /**
* 外层循环
* 用于判断线程池状态
*/
retry:
for (;;) {
int c = ctl.get();
int rs = runStateOf(c); // Check if queue empty only if necessary.
/**
* 对线程池状态的判断,两种情况会workerCount-1,并且返回null
* 线程池状态为shutdown,且workQueue为空(反映了shutdown状态的线程池还是要执行workQueue中剩余的任务的)
* 线程池状态为stop(shutdownNow()会导致变成STOP)(此时不用考虑workQueue的情况)
*/
if (rs >= SHUTDOWN && (rs >= STOP || workQueue.isEmpty())) {
decrementWorkerCount(); //循环的CAS减少worker数量,直到成功
return null;
}//其实就是shutdown后没任务执行了还有shutdownnow下,需要返回null而且马上停止工作线程,这里先进行工作线程的数量也就是ctl的数值上的变化,先减一 boolean timed; // Are workers subject to culling?
// 是否需要定时从workQueue中获取
//很多地方都有这个局部变量,一般就用来判断要不要进行时间上的操作的,如果没有设置allwoCoreThreadTimeOut,那么就是重要线程数目大于coreThreadSize就 //要计时,超时则搞死工作线程,让工作线程数目维持在corePoolSize数量 /**
* 内层循环
* 要么break去workQueue获取任务
* 要么超时了,worker count-1
*/
for (;;) {
int wc = workerCountOf(c);
timed = allowCoreThreadTimeOut || wc > corePoolSize; //allowCoreThreadTimeOut默认为false
//如果allowCoreThreadTimeOut为true,说明corePoolSize和maximum都需要定时 //如果当前执行线程数<maximumPoolSize,并且timedOut 和 timed 任一为false,跳出循环,开始从workQueue获取任务
if (wc <= maximumPoolSize && ! (timedOut && timed))
break; /**
* 如果到了这一步,说明要么线程数量超过了maximumPoolSize(可能maximumPoolSize被修改了)
* 要么既需要计时timed==true,也超时了timedOut==true,就是超时了,要减少工作线程Worker了
* worker数量-1,减一执行一次就行了,然后返回null,在runWorker()中会有逻辑减少worker线程
* 如果本次减一失败,继续内层循环再次尝试减一
*/
if (compareAndDecrementWorkerCount(c))
return null; //也就这里又有两种情况会返回null,并且要减少工作线程的数量 //如果减数量失败,再次读取ctl
c = ctl.get(); // Re-read ctl //如果线程池运行状态发生变化,继续外层循环
//如果状态没变,继续内层循环
if (runStateOf(c) != rs)
continue retry;
// else CAS failed due to workerCount change; retry inner loop
} try {
//poll() - 使用 LockSupport.parkNanos(this, nanosTimeout) 挂起一段时间,interrupt()时不会抛异常,但会有中断响应
//take() - 使用 LockSupport.park(this) 挂起,interrupt()时不会抛异常,但会有中断响应
Runnable r = timed ?
workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) : //一般是大于corePoolSize,如果没有任务,最多只能在哪里堵塞keepAliveTime
workQueue.take(); //一般是小于等于corePoolSize,空闲就一直等着咯,毕竟要维护<=coreThreadSize数量的工作线程 //如获取到了任务就返回
if (r != null)
return r; //没有返回,说明超时,那么在下一次内层循环时会进入worker count减一的步骤
timedOut = true;
}
/**
* blockingQueue的take()阻塞使用LockSupport.park(this)进入wait状态的,对LockSupport.park(this)进行interrupt不会抛异常,但还是会有中断响应
* 但AQS的ConditionObject的await()对中断状态做了判断,会报告中断状态 reportInterruptAfterWait(interruptMode)
* 就会上抛InterruptedException,在此处捕获,重新开始循环
* 如果是由于shutdown()等操作导致的空闲worker中断响应,在外层循环判断状态时,可能return null
*/
catch (InterruptedException retry) {
timedOut = false; //响应中断,重新开始,中断状态会被清除
}
}
}

7.2 分析吧:

getTask()
执行流程:
1、首先判断是否可以满足从workQueue中获取任务的条件,不满足return null
    A、线程池状态是否满足:
        (a)shutdown状态 + workQueue为空 或 stop状态,都不满足,因为被shutdown后还是要执行workQueue剩余的任务,但workQueue也为空,就可以退出了
        (b)stop状态,shutdownNow()操作会使线程池进入stop,此时不接受新任务,中断正在执行的任务,workQueue中的任务也不执行了,故return null返回
    B、线程数量是否超过maximumPoolSize 或 获取任务是否超时
        (a)线程数量超过maximumPoolSize可能是线程池在运行时被调用了setMaximumPoolSize()被改变了大小,否则已经addWorker()成功不会超过maximumPoolSize
        (b)如果 当前线程数量>corePoolSize,才会检查是否获取任务超时,这也体现了当线程数量达到maximumPoolSize后,如果一直没有新任务,会逐渐终止worker线程直到corePoolSize
2、如果满足获取任务条件,根据是否需要定时获取调用不同方法:
    A、workQueue.poll():如果在keepAliveTime时间内,阻塞队列还是没有任务,返回null
    B、workQueue.take():如果阻塞队列为空,当前线程会被挂起等待;当队列中有任务加入时,线程被唤醒,take方法返回任务
3、在阻塞从workQueue中获取任务时,可以被interrupt()中断,代码中捕获了InterruptedException,重置timedOut为初始值false,再次执行第1步中的判断,满足就继续获取任务,不满足return null,会进入worker退出的流程

7.3 看流程图理解下吧:

八、processWorkerExit方法的解析

在runWorker方法中,如果线程池的状态不行了,或者是getTask的时候返回null,就可能超时或者也是因为线程池shutdown巴拉巴拉,那么就会跳出runWorker中的循环,进入最后的processWorkerExit方法中,这个方法显然顾名思义,就是退出工作线程Worker的方法,所以可以大概推测这个方法应该就从workerSet中移除线程并工作线程数目减一的操作吧(当然前面的getTask也有工作线程数目减一的的操作)。

8.1 来看processWorkerExit的源码分析:

/**
* Performs cleanup and bookkeeping for a dying worker. Called
* only from worker threads. Unless completedAbruptly is set,
* assumes that workerCount has already been adjusted to account
* for exit. This method removes thread from worker set, and
* possibly terminates the pool or replaces the worker if either
* it exited due to user task exception or if fewer than
* corePoolSize workers are running or queue is non-empty but
* there are no workers.
* 大概就清楚和记录死掉的工作线程吧,其实就是把这个工作线程从workerSet中移除
* 这个方法还可能结束掉整个线程池,也可能搞死掉这个工作线程后后如果需要的话再添加工作线程,比如线程数量比coreThreadSize少;还有workQueue中还有任务但已经没 * 有工作线程的情况
* @param w the worker
* @param completedAbruptly if the worker died due to user exception
*/
private void processWorkerExit(Worker w, boolean completedAbruptly) {
/**
* 1、worker数量-1
* 如果是突然终止,说明是task执行时异常情况导致,即run()方法执行时发生了异常,那么正在工作的worker线程数量需要-1
* 如果不是突然终止,说明是worker线程没有task可执行了,不用-1,因为已经在getTask()方法中-1了
*/
if (completedAbruptly) // If abrupt, then workerCount wasn't adjusted 代码和注释正好相反啊
decrementWorkerCount();//自选CAS减一 /**
* 2、从Workers Set中移除worker
*/
final ReentrantLock mainLock = this.mainLock;//涉及到工作线程WorkerSet的操作都要获得全局锁
mainLock.lock();
try {
completedTaskCount += w.completedTasks; //把worker的完成任务数加到线程池的完成任务数
workers.remove(w); //从HashSet<Worker>中移除
} finally {
mainLock.unlock();
} /**
* 3、在对线程池有负效益的操作时,都需要“尝试终止”线程池
* 主要是判断线程池是否满足终止的状态
* 如果状态满足,但还有线程池还有线程,尝试对在线程池中空闲傻等的线程发出中断响应,使其能进入退出流程
* 没有线程了,更新状态为tidying->terminated
//具体的可以看下面的源码注解
*/
tryTerminate(); /**
* 4、是否需要增加worker线程 上面去除了一个Worker,这就可能当前线程数量不够,要加
* 线程池状态是running 或 shutdown
* 如果当前线程是突然终止的,addWorker()
* 如果当前线程不是突然终止的,但当前线程数量 < 要维护的线程数量,addWorker()
* 故如果调用线程池shutdown(),直到workQueue为空前,线程池都会维持corePoolSize个线程,然后再逐渐销毁这corePoolSize个线程
*/
int c = ctl.get();
//如果状态是running、shutdown,即tryTerminate()没有成功终止线程池,尝试再添加一个worker
if (runStateLessThan(c, STOP)) {
//不是突然完成的,即没有task任务可以获取而完成的,计算min,并根据当前worker数量判断是否需要addWorker()
//因为不是突然完成的话,说明是因为getTask返回null而进入这个processWorkerExit方法的,所以~
if (!completedAbruptly) {
int min = allowCoreThreadTimeOut ? 0 : corePoolSize; //allowCoreThreadTimeOut默认为false,即min默认为corePoolSize //如果min为0,即不需要维持核心线程数量,且workQueue不为空,至少保持一个线程
if (min == 0 && ! workQueue.isEmpty())
min = 1; //如果线程数量大于最少数量,直接返回,否则下面至少要addWorker一个
if (workerCountOf(c) >= min)
return; // replacement not needed
} //这里是因为突然停止的情况,因为突然停止的话,是因为Worker在执行Runnable任务的时候有异常而进入这个processWorkerExit方法的,然后上面移除了一个Worker //,本来这个Worker肯定是符合要求的,所以这个情况直接就add一个Worker
//添加一个没有firstTask的worker
//只要worker是completedAbruptly突然终止的,或者线程数量小于要维护的数量,就新添一个worker线程,即使是shutdown状态
addWorker(null, false);
}
}

8.2 流程分析:

processWorkerExit(Worker w, boolean completedAbruptly)
参数:
    worker:                      要结束的worker
    completedAbruptly: 是否突然完成(是否因为异常退出)
执行流程:
1、worker数量-1
    A、如果是突然终止,说明是task执行时异常情况导致,即run()方法执行时发生了异常,那么正在工作的worker线程数量需要-1
    B、如果不是突然终止,说明是worker线程没有task可执行了,不用-1,因为已经在getTask()方法中-1了
2、从Workers Set中移除worker,删除时需要上锁mainlock
3、tryTerminate():在对线程池有负效益的操作时,都需要“尝试终止”线程池,大概逻辑:
    判断线程池是否满足终止的状态
    A、如果状态满足,但还有线程池还有线程,尝试对其发出中断响应,使其能进入退出流程
    B、没有线程了,更新状态为tidying->terminated

下面顺便放了tryTerminate()源码的注解与分析
4、是否需要增加worker线程,如果线程池还没有完全终止,仍需要保持一定数量的线程
    线程池状态是running 或 shutdown
    A、如果当前线程是突然终止的,addWorker()

           因为突然停止的话,是因为Worker在执行Runnable任务的时候有异常而进入这个processWorkerExit方法的,然后上面移除了一个Worker,本来这个Worker肯定是符合要求的,所以这个情况                    直接就add一个Worker
    B、如果当前线程不是突然终止的,但当前线程数量 < 要维护的线程数量,addWorker()
    故如果调用线程池shutdown(),直到workQueue为空前,线程池都会维持corePoolSize个线程,然后再逐渐销毁这corePoolSize个线程

8.3 再附送一个tryTerminate()源码的注解:

/**
* Transitions to TERMINATED state if either (SHUTDOWN and pool
* and queue empty) or (STOP and pool empty). If otherwise
* eligible to terminate but workerCount is nonzero, interrupts an
* idle worker to ensure that shutdown signals propagate. This
* method must be called following any action that might make
* termination possible -- reducing worker count or removing tasks
* from the queue during shutdown. The method is non-private to
* allow access from ScheduledThreadPoolExecutor.
*/
final void tryTerminate() {
for (;;) {
int c = ctl.get();
if (isRunning(c) ||
runStateAtLeast(c, TIDYING) ||//大于等于TIDYING好像已经是terminate了
(runStateOf(c) == SHUTDOWN && ! workQueue.isEmpty()))//SHUTDOWN还有执行任务队列中的任务呢
return;//以上情况不符合结束线程池的条件,返回
if (workerCountOf(c) != 0) { // Eligible to terminate
//这里应该还有几种情况:1.SHUTDOWN然后workQueue为空;2.STOP状态
//然后这两种情况如果pool中还有工作线程,都要调用下面的方法来interrupt空闲在堵塞的线程。
interruptIdleWorkers(ONLY_ONE);
return;
} //到这里的话,剩下就是1. SHUTDOWN然后workQUeue为空,工作线程的数量也为空;2.STOP状态然后工作线程为空的状态,也就是可以terminate线程池的状态
//terminate这么大的事肯定要涉及到全局锁
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
if (ctl.compareAndSet(c, ctlOf(TIDYING, 0))) {//把CTLCAS改了,改成状态为TIDYING,工作线程数量为0下
try {
terminated();//这个方法是个protected的空方法,用户可以重写这个方法在线程池毁灭之前做点什么
} finally {
ctl.set(ctlOf(TERMINATED, 0));
termination.signalAll();//大概是唤醒之前有等过mainLock的线程吧
}
return;
}
} finally {
mainLock.unlock();
}
// else retry on failed CAS
}
}

大概思路就是:

首先我们要知道终结的条件

  1. SHUTDOWN状态,工作线程WorkerSet为空,工作队列workQueue里面没有任务;

  2. STOP状态,工作线程为空。

如果状态不满足这些,就直接返回。

如果是SHUTDOWN或者是STOP,但worker线程池中还有线程,那么就要interrupt一个在等待中的Worker,然后返回。

如果满足情况,则获取全局锁,先改状态为TIDYING,然后再改成TERMINATED,不行就自旋。

8.4 顺便附送一个interruptIdleWorkers()方法的源码和注解,注意这也算是操作Worker,所以也要全局锁:

/**
* Interrupts threads that might be waiting for tasks (as
* indicated by not being locked) so they can check for
* termination or configuration changes. Ignores
* SecurityExceptions (in which case some threads may remain
* uninterrupted).
*
* @param onlyOne If true, interrupt at most one worker. This is
* called only from tryTerminate when termination is otherwise
* enabled but there are still other workers. In this case, at
* most one waiting worker is interrupted to propagate shutdown
* signals in case all threads are currently waiting.
* Interrupting any arbitrary thread ensures that newly arriving
* workers since shutdown began will also eventually exit.
* To guarantee eventual termination, it suffices to always
* interrupt only one idle worker, but shutdown() interrupts all
* idle workers so that redundant workers exit promptly, not
* waiting for a straggler task to finish.
*/
private void interruptIdleWorkers(boolean onlyOne) {//这个方法应该只是尝试interrupt那些空闲在堵塞队列中等待任务的Worker
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();//操作WorkerSet的东西,所以要全局锁
try {
for (Worker w : workers) {
Thread t = w.thread;
if (!t.isInterrupted() && w.tryLock()) {
//空闲的Worker是没有lock的,所以有机会获得,如果是运行中的Worker是有锁的这里无法获得锁,所以不能interrupt运行中的Worker
try {
t.interrupt();
} catch (SecurityException ignore) {
} finally {
w.unlock();
}
}
if (onlyOne)
break;
}
} finally {
mainLock.unlock();
}
}

九、shutdown方法和shutdownnow方法

9.1 shutdown方法源码:

/**
* Initiates an orderly shutdown in which previously submitted
* tasks are executed, but no new tasks will be accepted.
* Invocation has no additional effect if already shut down.
*
* <p>This method does not wait for previously submitted tasks to
* complete execution. Use {@link #awaitTermination awaitTermination}
* to do that.
*
* @throws SecurityException {@inheritDoc}
*/
public void shutdown() {
final ReentrantLock mainLock = this.mainLock;//全局锁
mainLock.lock();
try {
checkShutdownAccess();//检查每一个线程池的线程是否有可以ShutDown的权限。
advanceRunState(SHUTDOWN);//过自旋的CAS操作来将ctl中的状态变为SHUTDOWN
interruptIdleWorkers();//对所有的空闲的在workQueue的线程进行interrupt操作
onShutdown(); // hook for ScheduledThreadPoolExecutor堵
//这个方法是空方法的,你可以重写它来进行一些清理性的操作
} finally {
mainLock.unlock();
}
tryTerminate();//看看可以结束线程池吗
}

这个方法会把线程池的状态设为SHUTDOWN

这个方法调用的是interruptIdleWorkers()方法,也就是要获得worker的锁才能执行interrupt,但worker在运行的时候也就是runWorker中是要lock才执行任务的,也就是这个方法无法interrupt正在执行任务的Worker。

然后最后会调用tryTerminate方法,我们上面的分析知道了,在这个tryTerminate方法中,如果状态是SHUTDOWN的话,只有workerSet为空,而且WorkQueue也为空才会是可以毁灭的时机,所以shutdown方法是会执行完已经提交了的任务的。

9.2 shutdownnow方法源码:

/**
* Attempts to stop all actively executing tasks, halts the
* processing of waiting tasks, and returns a list of the tasks
* that were awaiting execution. These tasks are drained (removed)
* from the task queue upon return from this method.
* 尝试暂停所有正在执行任务的线程,剩下的还没执行的已经提交的任务也不会执行,但会返回。
* 还没执行的任务会被从WorkQueue移除并返回
*
* <p>This method does not wait for actively executing tasks to
* terminate. Use {@link #awaitTermination awaitTermination} to
* do that.
*
* <p>There are no guarantees beyond best-effort attempts to stop
* processing actively executing tasks. This implementation
* cancels tasks via {@link Thread#interrupt}, so any task that
* fails to respond to interrupts may never terminate.
* 这个方法是会企图停止正在执行任务的工作线程,但不保证可以stop,因为这个shutdownnow方法是通过线程的interrupt方法来实现的,
* 如果无法正确相应interrupt的话,就可能不会停止
*
* @throws SecurityException {@inheritDoc}
*/
public List<Runnable> shutdownNow() {
List<Runnable> tasks;
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
checkShutdownAccess();//检查每一个线程池的线程是否有可以ShutDown的权限。
advanceRunState(STOP);//通过自旋的CAS操作来将ctl中的状态变为STOP
interruptWorkers();//这个方法和interruptIdleWorker就不同了
tasks = drainQueue();//大概做的就是把WorkQueue中的Runnable任务移除到一个List<Runnable>中再返回
} finally {
mainLock.unlock();
}
tryTerminate();//尝试结束线程池
return tasks;
}

这个方法会把线程池的状态设为STOP

这个方法调用的是interruptWorkers方法,这个方法是interrupt所有的工作线程,和上面那个interruptIdleWorkers不一样,看看源码:

interruptWorkers的源码:

/**
* Interrupts all threads, even if active. Ignores SecurityExceptions
* (in which case some threads may remain uninterrupted).
*/
private void interruptWorkers() {
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
for (Worker w : workers)
w.interruptIfStarted();//不用获得worker的锁,只要线程或者,就进行interrupt操作
} finally {
mainLock.unlock();
}
} void interruptIfStarted() {
Thread t;
if (getState() >= 0 && (t = thread) != null && !t.isInterrupted()) {
try {
t.interrupt();
} catch (SecurityException ignore) {
}
}
}

9.3 所以总结下shutdown和shutdownnow方法的区别:

1. shutdown把线程池的状态变成SHUTDOWN,shutdownnow把线程池的状态变成STOP

2. 两者都是通过Thread的interrupt方法来实现的,但不同的是,shutdown在执行各个worker也就是工作线程的interrupt之前需要先获得各个worker的锁,而worker在执行方法的时候是要加锁的,所以shutdown是要加锁的,所以shutdown方法不会去interrupt正在执行任务的工作线程,只会去interrupt空闲在workQueue堵塞的线程;而shutdownnow是会interrupt所有的worker;

3. 两个方法最后都会调用tryTerminate方法来尝试结束线程池,结束而这个方法的结束条件是:1. SHUTDOWN & workSet为空 & workQueue为空;2. STOP & workSet为空。

所以总结就是,Shutdown方法的话,会把已经提交的任务执行完再结束;而Shutdownnow方法就不会去理会在任务队列中的任务了

参考文章:

http://www.cnblogs.com/trust-freedom/p/6681948.html#autoid-2-0-0——《Java线程池ThreadPoolExecutor使用和分析(二) - execute()原理》主要是参考这篇来写的

https://www.cnblogs.com/-wyl/p/9760670.html——《线程池的五种状态 》用了它一个线程池状态的图咯。

线程池ThreadPoolExecutor的学习的更多相关文章

  1. java线程API学习 线程池ThreadPoolExecutor(转)

    线程池ThreadPoolExecutor继承自ExecutorService.是jdk1.5加入的新特性,将提交执行的任务在内部线程池中的可用线程中执行. 构造函数 ThreadPoolExecut ...

  2. 多线程学习笔记八之线程池ThreadPoolExecutor实现分析

    目录 简介 继承结构 实现分析 ThreadPoolExecutor类属性 线程池状态 构造方法 execute(Runnable command) addWorker(Runnable firstT ...

  3. 并发编程之线程池ThreadPoolExecutor

    前言 在我们平时自己写线程的测试demo时,一般都是用new Thread的方式来创建线程.但是,我们知道创建线程对象,就会在内存中开辟空间,而线程中的任务执行完毕之后,就会销毁. 单个线程的话还好, ...

  4. 线程池 ThreadPoolExecutor 原理及源码笔记

    前言 前面在学习 JUC 源码时,很多代码举例中都使用了线程池 ThreadPoolExecutor,并且在工作中也经常用到线程池,所以现在就一步一步看看,线程池的源码,了解其背后的核心原理. 公众号 ...

  5. jdk线程池ThreadPoolExecutor工作原理解析(自己动手实现线程池)(一)

    jdk线程池ThreadPoolExecutor工作原理解析(自己动手实现线程池)(一) 线程池介绍 在日常开发中经常会遇到需要使用其它线程将大量任务异步处理的场景(异步化以及提升系统的吞吐量),而在 ...

  6. java线程池ThreadPoolExecutor使用简介

    一.简介线程池类为 java.util.concurrent.ThreadPoolExecutor,常用构造方法为:ThreadPoolExecutor(int corePoolSize, int m ...

  7. 线程池ThreadPoolExecutor

    线程池类为 java.util.concurrent.ThreadPoolExecutor,常用构造方法为: ThreadPoolExecutor(int corePoolSize, int maxi ...

  8. 关于线程池ThreadPoolExecutor使用总结

    本文引用自: http://blog.chinaunix.net/uid-20577907-id-3519578.html 一.简介 线程池类为 java.util.concurrent.Thread ...

  9. [转] 引用 Java自带的线程池ThreadPoolExecutor详细介绍说明和实例应用

    PS: Spring ThreadPoolTaskExecutor vs Java Executorservice cachedthreadpool 引用 [轰隆隆] 的 Java自带的线程池Thre ...

随机推荐

  1. AOP和IOC的作用(转)

    AOP和IOC的作用 转载▼     IOC:控制反转,是一种设计模式.一层含义是控制权的转移:由传统的在程序中控制依赖转移到由容器来控制:第二层是依赖注入:将相互依赖的对象分离,在spring配置文 ...

  2. leetcode 66. Plus One(高精度加法)

    Given a non-negative number represented as an array of digits, plus one to the number. The digits ar ...

  3. Ubuntu下安装deb包命令

    原文地址:http://www.xitongzhijia.net/xtjc/20150206/37464.html 1.下载需要安装的deb包,输入以下命令安装: sudo dpkg -i packa ...

  4. BZOJ-3881:Divljak (AC自动机+DFS序+树链求并+树状数组)

    Alice有n个字符串S_1,S_2...S_n,Bob有一个字符串集合T,一开始集合是空的. 接下来会发生q个操作,操作有两种形式: “1 P”,Bob往自己的集合里添加了一个字符串P. “2 x” ...

  5. MySQL学习_查看各仓库产品的销售情况_20161102

    订单表结构是具体到每个订单下面多个产品,而仓库出货的表结构是对每个订单的金额汇总 不区分订单产品 因此如果想计算每个仓库每个产品的销售情况 需要将两个表连接起来 并且产品是昨天在线且有库存的产品 #昨 ...

  6. ACM学习历程—HDU 4287 Intelligent IME(字典树 || map)

    Description We all use cell phone today. And we must be familiar with the intelligent English input ...

  7. forEach、for in 和for of的区别

    forEach  不能使用break return 结束并退出循环 for in 和 for of 可以使用break return: for in遍历的是数组的索引(即键名),而for of遍历的是 ...

  8. Chrome检查更新总失败?安装细则讲解

    现在 Google Chrome 的稳定版都已经发布 68.0 版本了,我机上还是 54, 本想在线更新一下,结果点击菜单项中的“关于 Google Chrome”后,进入的界面提示“更新失败(错误: ...

  9. Node.js集成支付宝接口注意事项

    目录 签名 发送请求表单 验签 总结 签名 使用node.js自带的加密模块crypto和字符编码模块iconv-lite 根据支付宝接口文档参数格式得到签名之前的字符串beforeSignStr,然 ...

  10. 洛谷P1525关押罪犯——并查集

    题目:https://www.luogu.org/problemnew/show/P1525 并查集+贪心,从大到小排序,将二人分在不同房间,找到第一个不满足的即为答案. 代码如下: #include ...