ThreadPoolExecutor运行过程分析（直接看execute()方法的走向）

从execue方法说线程池。

ExecutorService exec = Executors.newFixedThreadPool(5);
exec.execute(
              ()->{
   System.out.println(""); }
            );

上面的代码大家都不陌生，我们从execute的流程一窥线程池的工作机制。
首先进入execute方法。

    public void execute(Runnable command) {
   
        if (command == null)//任务不能为空
            throw new NullPointerException();
        int c = ctl.get();    // 1
        if (workerCountOf(c) < corePoolSize) {
    //2
            if (addWorker(command, true))   //3
                return;
            c = ctl.get();
        }
        if (isRunning(c) && workQueue.offer(command)) {
     //4
            int recheck = ctl.get();
            if (! isRunning(recheck) && remove(command)) //5
                reject(command);
            else if (workerCountOf(recheck) == 0)  //6
                addWorker(null, false);
        }
        else if (!addWorker(command, false))
            reject(command);
    }

ctl是个AtomicInteger全局变量。
注释原话：ctl是线程池的主要控制声明，概念上它包含两个字段，
workerCount 表明有效的线程数量。
runState 表明线程池是否运行或者关闭等。
我们只需要直到通过ctl可以拿到线程池的当前运行状态即工作线程数量即可。
标号与代码中的注释对应。
//2 代码：如果现有线程数小于核心线程数，对于新任务，直接启动一个线程来处理。

//4 代码：线程数量已经达到核心线程数，在线程池处于运行状态的情况下往任务队列加入任务。
//5 代码： 注释原话：在进入这个方法后也许线程池会关闭，所以我们需要再次检查。
//6 代码：注释原话：有可能从上次check到这之间线程死亡了，所以仍需要再次检查。
//4处的两个操作并不是原子操作，5和6的担心是有道理的。举一个极端的例子，假设核心线程数为0，空闲线程等待关闭时间也为0，//4处的两个操作并不是原子操作，isRunning判定虽然成功了，在入队之前也许线程状态改变了。若没有双重检查，那这个入队的任务是不会被处理的。
从上面代码来看，真正的处理在
//3处，我们看addWorker(command, true)方法。

第二个参数core true表明是用核心线程数作为限制，fasle则用最大线程数作为限制。
我们上面的execute方法是在小于核心线程数的情况下调用的该方法。故为true。

   private boolean addWorker