Java 线程池ThreadPoolExecutor（基于jdk1.8）（二）

    上一篇分析了ThreadPoolExecutor的execute方法的具体执行过程，这一篇主要分析当中的几个重要的函数。 http://blog.csdn.net/youxitongyongming/article/details/77751874

private boolean addWorker(Runnable firstTask, boolean core) 首先分析一下参数，firstTask就是指我们用户传入的需要执行的认为，core参数，当为真时，表示当前线程数小于corePoolSize，为假就是线程数大于corePoolSize。该方法主要有两块大的逻辑，第一部分是通过CAS操作去跟新当前的线程数量： retry: for (;;) { int c = ctl.get(); int rs = runStateOf(c); // Check if queue empty only if necessary. if (rs >= SHUTDOWN && ! (rs == SHUTDOWN && firstTask == null && ! workQueue.isEmpty())) return false; for (;;) { int wc = workerCountOf(c); if (wc >= CAPACITY || wc >= (core ? corePoolSize : maximumPoolSize)) return false; if (compareAndIncrementWorkerCount(c)) break retry; c = ctl.get(); // Re-read ctl if (runStateOf(c) != rs) continue retry; // else CAS failed due to workerCount change; retry inner loop } }

    两个大的for无限循环体，外边的循环就是不断检测当前线程池的状态，一旦发现不处于Running状态了，就立刻返回false了，因为通过前边文章分析我们知道，当线程池调用了shutdown方法后，就不再接收心的任务了。     再看内层的循环体，主要就是通过CAS操作去更新线程池数量， if (compareAndIncrementWorkerCount(c))如果更新成功，那么就会跳出外层循环，继续后边的逻辑。如果更新失败，需要再次检查当前线程池的状态，因为CAS操作是没有进行同步操作的，所以有可能此时线程池的状态已经变了，需要再次检测。发现状态发生变化，那么需要跳出内层循环直接进行下一次的外层循环，重新检查线程池状态。如果线程池的状态没有发生变化，则继续下一次的内层循环，重新尝试更新线程池数量直至更新成功。     线程池数量更新成功了，就进入下一个逻辑块，添加线程：

boolean workerStarted = false; boolean workerAdded = false; Worker w = null; try { w = new Worker(firstTask); final Thread t = w.thread; if (t != null) { final ReentrantLock mainLock = this.mainLock; mainLock.lock(); try { // Recheck while holding lock. // Back out on ThreadFactory failure or if // shut down before lock acquired. int rs = runStateOf(ctl.get()); if (rs < SHUTDOWN || (rs == SHUTDOWN && firstTask == null)) { if (t.isAlive()) // precheck that t is startable throw new IllegalThreadStateException(); workers.add(w); int s = workers.size(); if (s > largestPoolSize) largestPoolSize = s; workerAdded = true; } } finally { mainLock.unlock(); } if (workerAdded) { t.start(); workerStarted = true; } } } finally { if (! workerStarted) addWorkerFailed(w); } return workerStarted; }

    第5行首先新建了一个worker，这个类内部封装了我们的runnable对象还有线程对象（随后会进行分析），第9行进行加锁，在线程池操作中，所有涉及到线程池状态变化的代码都需要进行同步操作，前一部分用的是CAS，这一部分用到了可重入锁。      在判断线程池是处于running状态后，在20行workers.add(w)，把工作线程添加到一个Set集合中，workers就是一个HashSet用于存放当前线程池中存活的线程。后边就很简单，记录了一下最大的线程数。      关键看30行，t.start()启动了线程。这个t就是我们新建的worker中的线程。这样一下来我们在线程数小于corePoolSize的时候，发起的任务就直接通过新建线程开始运行了。     为了了解发出的任务到底是怎么运行的，还得继续分析Worker这个类。

private final class Worker extends AbstractQueuedSynchronizer implements Runnable { /** Thread this worker is running in. Null if factory fails. */ final Thread thread; /** Initial task to run. Possibly null. */ Runnable firstTask; /** Per-thread task counter */ volatile long completedTasks; Worker(Runnable firstTask) { setState(-1); // inhibit interrupts until runWorker this.firstTask = firstTask; this.thread = getThreadFactory().newThread(this); } public void run() { runWorker(this); } ...//省略了重写AbstractQueuedSynchronizer类中的方法 }

     这个worker还是继承了Runnable接口，内部有三个成员变量，注释中已经写得很明白都要什么作用。我们关注一下run方法，其实就调用了一个runWorker(this)，把自己作为参数传递进去。那么继续跟进这个方法（请保持清醒，因为已经有好几层调用了。。）：

final void runWorker(Worker w) { Thread wt = Thread.currentThread(); Runnable task = w.firstTask; w.firstTask = null; w.unlock(); // allow interrupts boolean completedAbruptly = true; try { 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); } }

     主体是一个while循环，判断当前task是否为空，不为空就直接运行此任务，关键代码在第19行task.run()，直接调用Runnable的run方法，那就是在当前线程运行它，那么问题来了，现在当前线程到底是哪个线程了？是不是有点乱了，赶紧来个流程图，我们观察一下函数调用：

     第一二步都是在用户线程（调用execute方法时的那个线程），后边三步之后已经切换到新建的worker线程中去了，所以最终用户传递给execute的那个Runnable对象是在新的线程中运行的。     ok！回到上边代码的while循环，或条件判断的第二个条件回去调用getTask方法。看名字都知道，肯定是去BlockingQueue（任务缓存队列）中去取下一个需要执行的任务了。

private Runnable getTask() { boolean timedOut = false; // Did the last poll() time out? for (;;) { int wc = workerCountOf(c); // Are workers subject to culling? boolean timed = allowCoreThreadTimeOut || wc > corePoolSize; if ((wc > maximumPoolSize || (timed && timedOut)) && (wc > 1 || workQueue.isEmpty())) { if (compareAndDecrementWorkerCount(c)) return null; continue; } try { Runnable r = timed ? workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) : workQueue.take(); if (r != null) return r; timedOut = true; } catch (InterruptedException retry) { timedOut = false; } } }

    第7行的boolean timed = allowCoreThreadTimeOut || wc > corePoolSize，主要是判断当前线程是否需要进行销毁，allowCoreThreadTimeOut 为真，就是说不管当前的线程数有没有超过corePoolSize，都需要根据keepAliveTime去判断线程的存活期。如果为假那么就看第二个语句，就是当前线程数大于corePoolSize就需要判断线程的存活期，如果不大于，那么就不需要判断存活期了。     接下来主要关注一下16-25行的try代码块，需要判断线程的存活期那么r就为workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS)返回的值，也就是说尝试从缓存队列取任务，时间限制为keepAliveTime，如果在这段时间内取到了任务，就返回，如果没取到那么会抛出异常，那么就表明这个线程已经在keepAliveTime这个时间段里没有执行了，那么该线程就该被销毁了。      time为false的话，就表明不需要判断线程的存活期，直接调用workQueue.take()，由于线程池采用的阻塞队列，那么该线程就会一直阻塞，直到从队列中取到新的任务，然后返回。     到此我们的ThreadPoolExecutor的大致流程就分析完毕了，其中还有很多细节就没法完全覆盖到了，如果有理解不当的地方，欢迎大家指出，共同学习交流！