线程池学习记录

注：此文参照阿里技术公众号《10问10答：你真的了解线程池吗？》，仅作为个人学习记录。

《Java开发手册》中强调，线程资源必须通过线程池提供，而创建线程池必须使用ThreadPoolExecutor。手册主要强调利用线程池避免两个问题，一是线程过渡切换，二是避免请求过多时造成OOM。但是如果参数配置错误，还是会引发上面的两个问题。所以本节我们主要是讨论ThreadPoolExecutor的一些技术细节，并且给出几个常用的最佳实践建议。

我在查找资料的过程中，发现有些问题存在争议。后面发现，一部分原因是因为不同JDK版本的现实是有差异的。因此，下面的分析是基于当下最常用的版本JDK1.8，并且对于存在争议的问题，我们分析源码，源码才是最准确的。

1. corePoolSize=0会怎么样

这是一个争议点。我发现大部分博文，不论是国内的还是国外的，都是这样回答这个问题的：

• 提交任务后，先判断当前池中线程数是否小于corePoolSize，如果小于，则创建新线程执行这个任务。

• 否则，判断等待队列是否已满，如果没有满，则添加到等待队列。

• 否则，判断当前池中线程数是否大于maximumPoolSize，如果大于则拒绝。

• 否则，创建一个新的线程执行这个任务。

按照上面的描述，如果corePoolSize=0，则会判断等待队列的容量，如果还有容量，则排队，并且不会创建新的线程。

—— 但其实，这是老版本的实现方式，从1.6之后，实现方式就变了。我们直接看execute的源码（submit也依赖它），我备注出了关键一行：

int c = ctl.get();
        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);

• 线程池提交任务后，首先判断当前池中线程数是否小于corePoolSize。

• 如果小于则尝试创建新的线程执行该任务；否则尝试添加到等待队列。

• 如果添加队列成功，判断当前池内线程数是否为0，如果是则创建一个firstTask为null的worker，这个worker会从等待队列中获取任务并执行。

• 如果添加到等待队列失败，一般是队列已满，才会再尝试创建新的线程。

• 但在创建之前需要与maximumPoolSize比较，如果小于则创建成功。

• 否则执行拒绝策略。

答：

上述问题需区分JDK版本。在1.6版本之后，如果corePoolSize=0，提交任务时如果线程池为空，则会立即创建一个线程来执行任务（先排队再获取）；如果提交任务的时候，线程池不为空，则先在等待队列中排队，只有队列满了才会创建新线程。

所以，优化在于，在队列没有满的这段时间内，会有一个线程在消费提交的任务；1.6之前的实现是，必须等队列满了之后，才开始消费。

2. 线程池创建之后，会立即创建核心线程么
之前有人问过我这个问题，因为他发现应用中有些Bean创建了线程池，但是这个Bean一般情况下用不到，所以咨询我是否需要把这个线程池注释掉，以减少应用运行时的线程数（该应用运行时线程过多。）

答：

不会。从上面的源码可以看出，在刚刚创建ThreadPoolExecutor的时候，线程并不会立即启动，而是要等到有任务提交时才会启动，除非调用了prestartCoreThread/prestartAllCoreThreads事先启动核心线程。

• prestartCoreThread：Starts a core thread, causing it to idly wait for work. This overrides the default policy of starting core threads only when new tasks are executed.

• prestartAllCoreThreads：Starts all core threads.

3. 核心线程永远不会销毁么
这个问题有点tricky。首先我们要明确一下概念，虽然在JavaDoc中也使用了“core/non-core threads”这样的描述，但其实这是一个动态的概念，JDK并没有给一部分线程打上“core”的标记，做什么特殊化的处理。这个问题我认为想要探讨的是闲置线程终结策略的问题。

在JDK1.6之前，线程池会尽量保持corePoolSize个核心线程，即使这些线程闲置了很长时间。这一点曾被开发者诟病，所以从JDK1.6开始，提供了方法allowsCoreThreadTimeOut，如果传参为true，则允许闲置的核心线程被终止。
请注意这种策略和corePoolSize=0的区别。我总结的区别是：

• corePoolSize=0：在一般情况下只使用一个线程消费任务，只有当并发请求特别多、等待队列都满了之后，才开始用多线程。

• allowsCoreThreadTimeOut=true && corePoolSize>1：在一般情况下就开始使用多线程（corePoolSize个），当并发请求特别多，等待队列都满了之后，继续加大线程数。但是当请求没有的时候，允许核心线程也终止。

所以corePoolSize=0的效果，基本等同于allowsCoreThreadTimeOut=true && corePoolSize=1，但实现细节其实不同。

答：

在JDK1.6之后，如果allowsCoreThreadTimeOut=true，核心线程也可以被终止。

4. 如何保证线程不被销毁

首先我们要明确一下线程池模型。线程池有个内部类Worker，它实现了Runnable接口，首先，它自己要run起来。然后它会在合适的时候获取我们提交的Runnable任务，然后调用任务的run()接口。一个Worker不终止的话可以不断执行任务。

我们前面说的“线程池中的线程”，其实就是Worker；等待队列中的元素，是我们提交的Runnable任务。

每一个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循环执行结束，则被终止了。

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 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
                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);
        }
    }
    
    private Runnable getTask() {
        boolean timedOut = false; // Did the last poll() time out?

        for (;;) {
            int c = ctl.get();
            int rs = runStateOf(c);

            // Check if queue empty only if necessary.
            if (rs >= SHUTDOWN && (rs >= STOP || workQueue.isEmpty())) {
                decrementWorkerCount();
                return null;
            }

            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;
            }
        }
    }

答：

实现方式非常巧妙，核心线程（Worker）即使一直空闲也不终止，是通过workQueue.take()实现的，它会一直阻塞到从等待队列中取到新的任务。非核心线程空闲指定时间后终止是通过workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS)实现的，一个空闲的Worker只等待keepAliveTime，如果还没有取到任务则循环终止，线程也就运行结束了。

引申思考

Worker本身就是个线程，它再调用我们传入的Runnable.run()，会启动一个子线程么？如果你还没有答案，再回想一下Runnable和Thread的关系。

5. 空闲线程过多会有什么问题

笼统地回答是会占用内存，我们分析一下占用了哪些内存。首先，比较普通的一部分，一个线程的内存模型：

• 虚拟机栈

• 本地方法栈

• 程序计数器

我想额外强调是下面这几个内存占用，需要小心：

• ThreadLocal：业务代码是否使用了ThreadLocal？就算没有，Spring框架中也大量使用了ThreadLocal，你所在公司的框架可能也是一样。

• 局部变量：线程处于阻塞状态，肯定还有栈帧没有出栈，栈帧中有局部变量表，凡是被局部变量表引用的内存都不能回收。所以如果这个线程创建了比较大的局部变量，那么这一部分内存无法GC。

• TLAB机制：如果你的应用线程数处于高位，那么新的线程初始化可能因为Eden没有足够的空间分配TLAB而触发YoungGC。

答：

• 线程池保持空闲的核心线程是它的默认配置，一般来讲是没有问题的，因为它占用的内存一般不大。怕的就是业务代码中使用ThreadLocal缓存的数据过大又不清理。

• 如果你的应用线程数处于高位，那么需要观察一下YoungGC的情况，估算一下Eden大小是否足够。如果不够的话，可能要谨慎地创建新线程，并且让空闲的线程终止；必要的时候，可能需要对JVM进行调参。

6. keepAliveTime=0会怎么样

这也是个争议点。有的博文说等于0表示空闲线程永远不会终止，有的说表示执行完立刻终止。还有的说等于-1表示空闲线程永远不会终止。其实稍微看一下源码知道了，这里我直接抛出答案。

答：

在JDK1.8中，keepAliveTime=0表示非核心线程执行完立刻终止。

public RunnableScheduledFuture<?> poll(long timeout, TimeUnit unit)
            throws InterruptedException {
            long nanos = unit.toNanos(timeout);
            final ReentrantLock lock = this.lock;
            lock.lockInterruptibly();
            try {
                for (;;) {
                    RunnableScheduledFuture<?> first = queue[0];
                    if (first == null) {
                    //keepAliveTime=0直接返回null
                        if (nanos <= 0)
                            return null;
                        else
                            nanos = available.awaitNanos(nanos);
                    } else {
                        long delay = first.getDelay(NANOSECONDS);
                        if (delay <= 0)
                            return finishPoll(first);
                        if (nanos <= 0)
                            return null;
                        first = null; // don't retain ref while waiting
                        if (nanos < delay || leader != null)
                            nanos = available.awaitNanos(nanos);
                        else {
                            Thread thisThread = Thread.currentThread();
                            leader = thisThread;
                            try {
                                long timeLeft = available.awaitNanos(delay);
                                nanos -= delay - timeLeft;
                            } finally {
                                if (leader == thisThread)
                                    leader = null;
                            }
                        }
                    }
                }
            } finally {
                if (leader == null && queue[0] != null)
                    available.signal();
                lock.unlock();
            }
        }

默认情况下，keepAliveTime小于0，初始化的时候才会报错；但如果allowsCoreThreadTimeOut，keepAliveTime必须大于0，不然初始化报错。

public void setKeepAliveTime(long time, TimeUnit unit) {
        if (time < 0)
            throw new IllegalArgumentException();
        if (time == 0 && allowsCoreThreadTimeOut())
            throw new IllegalArgumentException("Core threads must have nonzero keep alive times");
        long keepAliveTime = unit.toNanos(time);
        long delta = keepAliveTime - this.keepAliveTime;
        this.keepAliveTime = keepAliveTime;
        if (delta < 0)
            interruptIdleWorkers();
    }

7. 怎么进行异常处理

。。。。

8. 线程池需不需要关闭

答：

一般来讲，线程池的生命周期跟随服务的生命周期。如果一个服务（Service）停止服务了，那么需要调用shutdown方法进行关闭。所以ExecutorService.shutdown在Java以及一些中间件的源码中，是封装在Service的shutdown方法内的。

如果是Server端不重启就不停止提供服务，我认为是不需要特殊处理的。

9. shutdown和shutdownNow的区别

答：

• shutdown => 平缓关闭，等待所有已添加到线程池中的任务执行完再关闭。

• shutdownNow => 立刻关闭，停止正在执行的任务，并返回队列中未执行的任务。

本来想分析一下两者的源码的，但是发现本文的篇幅已经过长了，源码也贴了不少。感兴趣的朋友自己看一下即可。

10. Spring中有哪些和ThreadPoolExecutor类似的工具
未完待续