继上篇《ThreadPoolExecutor源码分析（一）：重要成员变量》续...
作为一个执行服务ExecutorService的实例，ThreadPoolExecutor的首要任务当然是提交任务进行处理，那么，在任务提交时，ThreadPoolExecutor的处理流程是怎样的？它是一味的开启线程进行处理，还是有一套完整的逻辑来处理呢？本文，我们将继续分析ThreadPoolExecutor，看下它在任务提交时的主逻辑。
任务的提交是通过execute()方法完成的，代码如下：
/**
* 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}.
*
* @param command the task to execute
* @throws RejectedExecutionException at discretion of
* {@code RejectedExecutionHandler}, if the task
* cannot be accepted for execution
* @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.
* 1、如果少于corePoolSize数量的线程正在运行，尝试利用给定的Runnable实例command开启一个新的线程作为它的第一个任务。
* addWorker()方法的调用会对线程池运行状态runState、worker线程数量workerCount进行原子性检测，返回值为启动新线程结果。
*
* 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.
* 2、如果一个任务可以成功地进入队列，然后我们还需要再次检查（即双份检查）自从进入这个方法后，我们是否应该添加一个线程
* （因为自从上一次检查以来可能存在死亡情况），
* 所以我们重新检查状态，如果有必要的话，即线程池已停止，回滚之前的入队操作，或者在没有线程时启动一个新线程。
*
* 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.
* 3、如果我们不能入列一个任务，那么我们尝试添加一个新线程。
* 如果添加失败，我们知道线程池可能已被关闭或者数量饱和，所以我们会拒绝这个任务。
*/
// 获取ctl的值c
int c = ctl.get();
// 如果c中有效线程数目小于corePoolSize大小，尝试添加新的worker线程处理任务command：
// 从c中获取有效线程数目调用的是workerCountOf()方法，
// 添加新的worker线程处理任务command调用的是addWorker()方法，
// 线程数的判断利用corePoolSize作为边界约束条件
// 方法返回值是标志添加worker是否成功的标志位，ture表示成功，false表示失败，
// 如果为true，则直接返回，否则重新获取ctl的值c
if (workerCountOf(c) < corePoolSize) {
if (addWorker(command, true))
return;
// 添加work线程失败则再次获取ctl的值
c = ctl.get();
}
// 根据c判断当前线程池的状态是否为RUNNING状态，即既可以接受新任务，又会处理队列任务的状态，
// 并且通过offer()方法，尝试将commond添加到队列workQueue中
// BlockingQueue的offer()方法表示如果可能的话，将参数对象加到BlockingQueue里，
// 即如果BlockingQueue可以容纳，则返回true，否则返回false
if (isRunning(c) && workQueue.offer(command)) {
// 如果当前线程池处于RUNNING状态，且workQueue能够容纳command，并添加成功的话，
// 再次获取ctl的值recheck，
int recheck = ctl.get();
// 如果当前线程池的状态不是RUNNING，并且从队列workQueue移除command成功的话，
// 调用reject()方法拒绝任务command，
if (! isRunning(recheck) && remove(command))
reject(command);
// 否则如果当前工作线程woker数目为0，尝试添加新的worker线程，但是不携带任务
else if (workerCountOf(recheck) == 0)
addWorker(null, false);
}
// 如果尝试添加新的worker线程处理任务command失败，
// 调用reject()方法拒绝任务command，线程数的判断利用maximumPoolSize作为边界约束条件
else if (!addWorker(command, false))
reject(command);
} execute()方法的运行逻辑比较简单，它会首先检查待处理任务command是否为空，为空的话直接抛出空指针NullPointerException异常，并获取ctl的值c，ctl我们在上一篇文章中已讲到过，它是ThreadPoolExecutor当前线程池的一个综合控制状态，然后再根据当前ThreadPoolExecutor具体情况做如下处理：
1、如果当前线程池有效线程数目小于corePoolSize，那么尝试添加新的worker线程处理任务command：
从c中获取有效线程数目调用的是workerCountOf()方法，添加新的worker线程处理任务command调用的是addWorker()方法，且第二个参数为true表示线程数的判断利用corePoolSize作为边界约束条件，方法返回值是标志添加worker是否成功的标志位，ture表示成功，false表示失败，如果为true，则直接返回，否则重新获取ctl的值c；
2、根据c判断当前线程池的状态是否为RUNNING状态，即既可以接受新任务，又会处理队列任务的状态，注意此时c是重新获取的最新的数据，并且通过offer()方法，尝试将commond添加到队列workQueue中，BlockingQueue的offer()方法表示如果可能的话，将参数对象加到BlockingQueue里，即如果BlockingQueue可以容纳，则返回true，否则返回false：
此时，如果当前线程池处于RUNNING状态，且workQueue能够容纳command，并添加成功的话，再次获取ctl的值recheck，做第二次检查，如果当前线程池的状态不是RUNNING，并且从队列workQueue移除command成功的话，否则如果当前工作线程woker数目为0，尝试添加新的worker线程，但是不携带任务；
3、如果尝试添加新的worker线程处理任务command失败，调用reject()方法拒绝任务command，这时线程数的判断利用maximumPoolSize作为边界约束条件。
从上面的逻辑我们大致可以分析出如下一个主要思路：
1、如果ThreadPoolExecutor中当前有效线程数低于corePoolSize，那么我们总是优先尝试启动新的worker线程处理任务command；
2、如果ThreadPoolExecutor中当前有效线程数高于或等于corePoolSize，亦或者低于的情况下启动新的worker线程失败，我们会根据当前线程池状态是否为RUNNING，将任务command添加到任务队列workQueue中；
3、最后实在不行，在maximumPoolSize允许的情况下，强行开启一个线程处理任务。
这里，还有一点需要说明，在第2步中，既然已经将任务成功加入workQueue队列，为什么还需要再次做线程池状态检查呢？因为在我们刚刚把任务成功添加到任务队列workQueue中的那一刻，或者前一刻，任务还是RUNNING状态，但是保不齐其他调用者或者线程此时会修改线程池状态，那么此时我们就需要将任务再进行必要的移除，这是考虑复杂情况的一种安全机制的保障！
