1. 背景

随着计算技术的不断发展，3纳米制程芯片已进入试产阶段，摩尔定律在现有工艺下逐渐面临巨大的物理瓶颈，通过多核处理器技术来提升服务器的性能成为提升算力的主要方向。

在服务器领域，基于java构建的后端服务器占据着领先地位，因此，掌握java并发编程技术，充分利用CPU的并发处理能力是一个开发人员必修的基本功，本文结合线程池源码和实践，简要介绍了线程池和线程变量的使用。

2. 线程池概述

2.1 什么是线程池

线程池是一种“池化”的线程使用模式，通过创建一定数量的线程，让这些线程处于就绪状态来提高系统响应速度，在线程使用完成后归还到线程池来达到重复利用的目标，从而降低系统资源的消耗。

2.2 为什么要使用线程池

总体来说，线程池有如下的优势：

1. 降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
2. 提高响应速度。当任务到达时，任务可以不需要等到线程创建就能立即执行。
3. 提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。

3. 线程池的使用

3.1 线程池创建&核心参数设置

在java中，线程池的实现类是ThreadPoolExecutor，构造函数如下：

public ThreadPoolExecutor(int corePoolSize,  int maximumPoolSize,  long keepAliveTime,  TimeUnit timeUnit,  BlockingQueue workQueue,  ThreadFactory threadFactory,  RejectedExecutionHandler handler)

可以通过 new ThreadPoolExecutor(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, threadFactory,handler)来创建一个线程池。

• corePoolSize参数

在构造函数中，corePoolSize为线程池核心线程数。默认情况下，核心线程会一直存活，但是当将allowCoreThreadTimeout设置为true时，核心线程超时也会回收。

• maximumPoolSize参数

在构造函数中，maximumPoolSize为线程池所能容纳的最大线程数。

• keepAliveTime参数

在构造函数中，keepAliveTime表示线程闲置超时时长。如果线程闲置时间超过该时长，非核心线程就会被回收。如果将allowCoreThreadTimeout设置为true时，核心线程也会超时回收。

• timeUnit参数

在构造函数中，timeUnit表示线程闲置超时时长的时间单位。常用的有：TimeUnit.MILLISECONDS（毫秒）、TimeUnit.SECONDS（秒）、TimeUnit.MINUTES（分）。

• blockingQueue参数

在构造函数中，blockingQueue表示任务队列，线程池任务队列的常用实现类有：

1. ArrayBlockingQueue ：一个数组实现的有界阻塞队列，此队列按照FIFO的原则对元素进行排序，支持公平访问队列。
2. LinkedBlockingQueue ：一个由链表结构组成的可选有界阻塞队列，如果不指定大小，则使用Integer.MAX_VALUE作为队列大小，按照FIFO的原则对元素进行排序。
3. PriorityBlockingQueue ：一个支持优先级排序的无界阻塞队列，默认情况下采用自然顺序排列，也可以指定Comparator。
4. DelayQueue：一个支持延时获取元素的无界阻塞队列，创建元素时可以指定多久以后才能从队列中获取当前元素，常用于缓存系统设计与定时任务调度等。
5. SynchronousQueue：一个不存储元素的阻塞队列。存入操作必须等待获取操作，反之亦然。
6. LinkedTransferQueue：一个由链表结构组成的无界阻塞队列，与LinkedBlockingQueue相比多了transfer和tryTranfer方法，该方法在有消费者等待接收元素时会立即将元素传递给消费者。
7. LinkedBlockingDeque：一个由链表结构组成的双端阻塞队列，可以从队列的两端插入和删除元素。

• threadFactory参数

在构造函数中，threadFactory表示线程工厂。用于指定为线程池创建新线程的方式，threadFactory可以设置线程名称、线程组、优先级等参数。如通过Google工具包可以设置线程池里的线程名：

new ThreadFactoryBuilder().setNameFormat("general-detail-batch-%d").build()

• RejectedExecutionHandler参数

在构造函数中，rejectedExecutionHandler表示拒绝策略。当达到最大线程数且队列任务已满时需要执行的拒绝策略，常见的拒绝策略如下：

1. ThreadPoolExecutor.AbortPolicy：默认策略，当任务队列满时抛出RejectedExecutionException异常。
2. ThreadPoolExecutor.DiscardPolicy：丢弃掉不能执行的新任务，不抛任何异常。
3. ThreadPoolExecutor.CallerRunsPolicy：当任务队列满时使用调用者的线程直接执行该任务。
4. ThreadPoolExecutor.DiscardOldestPolicy：当任务队列满时丢弃阻塞队列头部的任务（即最老的任务），然后添加当前任务。

3.2 线程池状态转移图

ThreadPoolExecutor线程池有如下几种状态：

1. RUNNING：运行状态，接受新任务，持续处理任务队列里的任务；
2. SHUTDOWN：不再接受新任务，但要处理任务队列里的任务；
3. STOP：不再接受新任务，不再处理任务队列里的任务，中断正在进行中的任务；
4. TIDYING：表示线程池正在停止运作，中止所有任务，销毁所有工作线程，当线程池执行terminated()方法时进入TIDYING状态；
5. TERMINATED：表示线程池已停止运作，所有工作线程已被销毁，所有任务已被清空或执行完毕，terminated()方法执行完成；

3.3 线程池任务调度机制

线程池提交一个任务时任务调度的主要步骤如下：

1. 当线程池里存活的核心线程数小于corePoolSize核心线程数参数的值时，线程池会创建一个核心线程去处理提交的任务；
2. 如果线程池核心线程数已满，即线程数已经等于corePoolSize，新提交的任务会被尝试放进任务队列workQueue中等待执行；
3. 当线程池里面存活的线程数已经等于corePoolSize了，且任务队列workQueue已满，再判断当前线程数是否已达到maximumPoolSize，即最大线程数是否已满，如果没到达，创建一个非核心线程执行提交的任务；
4. 如果当前的线程数已达到了maximumPoolSize，还有新的任务提交过来时，执行拒绝策略进行处理。

核心代码如下：

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.  *  * 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.  *  * 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.  */ 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);     else if (workerCountOf(recheck) == 0)  addWorker(null, false); } else if (!addWorker(command, false))     reject(command);    }

3.4 Tomcat线程池分析

• Tomcat请求处理过程

Tomcat 的整体架构包含连接器和容器两大部分，其中连接器负责与外部通信，容器负责内部逻辑处理。在连接器中：

1. 使用 ProtocolHandler 接口来封装I/O模型和应用层协议的差异，其中I/O模型可以选择非阻塞I/O、异步I/O或APR，应用层协议可以选择HTTP、HTTPS或AJP。ProtocolHandler将I/O模型和应用层协议进行组合，让EndPoint只负责字节流的收发，Processor负责将字节流解析为Tomcat Request/Response对象，实现功能模块的高内聚和低耦合，ProtocolHandler接口继承关系如下图示。
2. 通过适配器 Adapter 将Tomcat Request对象转换为标准的ServletRequest对象。

Tomcat为了实现请求的快速响应，使用线程池来提高请求的处理能力。下面我们以HTTP非阻塞I/O为例对Tomcat线程池进行简要的分析。

• Tomcat线程池创建

在Tomcat中，通过AbstractEndpoint类提供底层的网络I/O的处理，若用户没有配置自定义公共线程池，则AbstractEndpoint通过createExecutor方法来创建Tomcat默认线程池。

核心部分代码如下：

public void createExecutor() { internalExecutor = true; TaskQueue taskqueue = new TaskQueue(); TaskThreadFactory tf = new TaskThreadFactory(getName() + "-exec-", daemon, getThreadPriority()); executor = new ThreadPoolExecutor(getMinSpareThreads(), getMaxThreads(), 60, TimeUnit.SECONDS,taskqueue, tf); taskqueue.setParent( (ThreadPoolExecutor) executor);    }

其中，TaskQueue、ThreadPoolExecutor分别为Tomcat自定义任务队列、线程池实现。

• Tomcat自定义ThreadPoolExecutor

Tomcat自定义线程池继承于java.util.concurrent.ThreadPoolExecutor，并新增了一些成员变量来更高效地统计已经提交但尚未完成的任务数量（submittedCount），包括已经在队列中的任务和已经交给工作线程但还未开始执行的任务。

/** * Same as a java.util.concurrent.ThreadPoolExecutor but implements a much more efficient * {@link #getSubmittedCount()} method, to be used to properly handle the work queue. * If a RejectedExecutionHandler is not specified a default one will be configured * and that one will always throw a RejectedExecutionException * */public class ThreadPoolExecutor extends java.util.concurrent.ThreadPoolExecutor {    /**     * The number of tasks submitted but not yet finished. This includes tasks     * in the queue and tasks that have been handed to a worker thread but the     * latter did not start executing the task yet.     * This number is always greater or equal to {@link #getActiveCount()}.     */    // 新增的submittedCount成员变量，用于统计已提交但还未完成的任务数    private final AtomicInteger submittedCount = new AtomicInteger(0);    private final AtomicLong lastContextStoppedTime = new AtomicLong(0L);    // 构造函数    public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue workQueue, ThreadFactory threadFactory,     RejectedExecutionHandler handler) { super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, threadFactory, handler); // 预启动所有核心线程 prestartAllCoreThreads();    }}

Tomcat在自定义线程池ThreadPoolExecutor中重写了execute()方法，并实现对提交执行的任务进行submittedCount加一。Tomcat在自定义ThreadPoolExecutor中，当线程池抛出RejectedExecutionException异常后，会调用force()方法再次向TaskQueue中进行添加任务的尝试。如果添加失败，则submittedCount减一后，再抛出RejectedExecutionException。

@Override    public void execute(Runnable command) { execute(command,0,TimeUnit.MILLISECONDS);    }    public void execute(Runnable command, long timeout, TimeUnit unit) { submittedCount.incrementAndGet(); try {     super.execute(command); } catch (RejectedExecutionException rx) {     if (super.getQueue() instanceof TaskQueue) {  final TaskQueue queue = (TaskQueue)super.getQueue();  try {      if (!queue.force(command, timeout, unit)) {   submittedCount.decrementAndGet();   throw new RejectedExecutionException("Queue capacity is full.");      }  } catch (InterruptedException x) {      submittedCount.decrementAndGet();      throw new RejectedExecutionException(x);  }     } else {  submittedCount.decrementAndGet();  throw rx;     } }    }

• Tomcat自定义任务队列

在Tomcat中重新定义了一个阻塞队列TaskQueue，它继承于LinkedBlockingQueue。在Tomcat中，核心线程数默认值为10，最大线程数默认为200，为了避免线程到达核心线程数后后续任务放入队列等待，Tomcat通过自定义任务队列TaskQueue重写offer方法实现了核心线程池数达到配置数后线程的创建。

具体地，从线程池任务调度机制实现可知，当offer方法返回false时，线程池将尝试创建新新线程，从而实现任务的快速响应。TaskQueue核心实现代码如下：

/** * As task queue specifically designed to run with a thread pool executor. The * task queue is optimised to properly utilize threads within a thread pool * executor. If you use a normal queue, the executor will spawn threads when * there are idle threads and you wont be able to force items onto the queue * itself. */public class TaskQueue extends LinkedBlockingQueue {    public boolean force(Runnable o, long timeout, TimeUnit unit) throws InterruptedException { if ( parent==null || parent.isShutdown() ) throw new RejectedExecutionException("Executor not running, can't force a command into the queue"); return super.offer(o,timeout,unit); //forces the item onto the queue, to be used if the task is rejected    }    @Override    public boolean offer(Runnable o) { // 1. parent为线程池，Tomcat中为自定义线程池实例      //we can't do any checks if (parent==null) return super.offer(o); // 2. 当线程数达到最大线程数时，新提交任务入队 //we are maxed out on threads, simply queue the object if (parent.getPoolSize() == parent.getMaximumPoolSize()) return super.offer(o); // 3. 当提交的任务数小于线程池中已有的线程数时，即有空闲线程，任务入队即可 //we have idle threads, just add it to the queue if (parent.getSubmittedCount()<=(parent.getPoolSize())) return super.offer(o); // 4. 【关键点】如果当前线程数量未达到最大线程数，直接返回false，让线程池创建新线程 //if we have less threads than maximum force creation of a new thread if (parent.getPoolSize()<parent.getMaximumPoolSize()) return false; // 5. 最后的兜底，放入队列 //if we reached here, we need to add it to the queue return super.offer(o);    }   }

• Tomcat自定义任务线程

Tomcat中通过自定义任务线程TaskThread实现对每个线程创建时间的记录；使用静态内部类WrappingRunnable对Runnable进行包装，用于对StopPooledThreadException异常类型的处理。

/** * A Thread implementation that records the time at which it was created. * */public class TaskThread extends Thread {    private final long creationTime;    public TaskThread(ThreadGroup group, Runnable target, String name) { super(group, new WrappingRunnable(target), name); this.creationTime = System.currentTimeMillis();    }    /**     * Wraps a {@link Runnable} to swallow any {@link StopPooledThreadException}     * instead of letting it go and potentially trigger a break in a debugger.     */    private static class WrappingRunnable implements Runnable { private Runnable wrappedRunnable; WrappingRunnable(Runnable wrappedRunnable) {     this.wrappedRunnable = wrappedRunnable; } @Override public void run() {     try {  wrappedRunnable.run();     } catch(StopPooledThreadException exc) {  //expected : we just swallow the exception to avoid disturbing  //debuggers like eclipse's  log.debug("Thread exiting on purpose", exc);     } }    }}

• 思考&小结

1. Tomcat为什么要自定义线程池和任务队列实现？

   JUC原生线程池在提交任务时，当工作线程数达到核心线程数后，继续提交任务会尝试将任务放入阻塞队列中，只有当前运行线程数未达到最大设定值且在任务队列任务满后，才会继续创建新的工作线程来处理任务，因此JUC原生线程池无法满足Tomcat快速响应的诉求。

2. Tomcat为什么使用无界队列？

   Tomcat在EndPoint中通过acceptCount和maxConnections两个参数来避免过多请求积压。其中maxConnections为Tomcat在任意时刻接收和处理的最大连接数，当Tomcat接收的连接数达到maxConnections时，Acceptor不会读取accept队列中的连接；这时accept队列中的线程会一直阻塞着，直到Tomcat接收的连接数小于maxConnections（maxConnections默认为10000，如果设置为-1，则连接数不受限制）。acceptCount为accept队列的长度，当accept队列中连接的个数达到acceptCount时，即队列满，此时进来的请求一律被拒绝，默认值是100（基于Tomcat 8.5.43版本）。因此，通过acceptCount和maxConnections两个参数作用后，Tomcat默认的无界任务队列通常不会造成OOM。

/** * Allows the server developer to specify the acceptCount (backlog) that * should be used for server sockets. By default, this value * is 100. */private int acceptCount = 100;private int maxConnections = 10000;

4. 最佳实践

• 避免用Executors 的创建线程池

Executors常用方法有以下几个：

4.1 FixedThreadPool

4.1.1 介绍

创建固定数目线程的线程池，线程数小于nThreads时，提交新的任务会创建新的线程，当线程数等于nThreads时，提交新的任务后任务会被加入到阻塞队列，正在执行的线程执行完毕后从队列中取任务执行，FiexedThreadPool适用于负载略重但任务不是特别多的场景，为了合理利用资源，需要限制线程数量；

FixedThreadPool 被称为可重用固定线程数的线程池。通过 Executors 类中的相关源代码来看一下相关实现：

   /**     * 创建一个可重用固定数量线程的线程池     */    public static ExecutorService newFixedThreadPool(int nThreads, ThreadFactory threadFactory) { return new ThreadPoolExecutor(nThreads, nThreads,   0L, TimeUnit.MILLISECONDS,   new LinkedBlockingQueue<Runnable>(),   threadFactory);    }

另外还有一个 FixedThreadPool 的实现方法，和上面的类似，所以这里不多做阐述：

    public static ExecutorService newFixedThreadPool(int nThreads) { return new ThreadPoolExecutor(nThreads, nThreads,   0L, TimeUnit.MILLISECONDS,   new LinkedBlockingQueue<Runnable>());    }

从上面源代码可以看出新创建的 FixedThreadPool 的 corePoolSize 和 maximumPoolSize 都被设置为 nThreads，这个 nThreads 参数是我们使用的时候自己传递的。

4.1.2 执行任务过程介绍

FixedThreadPool 的 execute() 方法运行示意图（该图片来源：《Java 并发编程的艺术》）：

上图说明：

1. 如果当前运行的线程数小于 corePoolSize， 如果再来新任务的话，就创建新的线程来执行任务；
2. 当前运行的线程数等于 corePoolSize 后， 如果再来新任务的话，会将任务加入 LinkedBlockingQueue；
3. 线程池中的线程执行完 手头的任务后，会在循环中反复从 LinkedBlockingQueue 中获取任务来执行；

4.1.3 为什么不推荐使用FixedThreadPool？

FixedThreadPool 使用无界队列 LinkedBlockingQueue（队列的容量为 Integer.MAX_VALUE）作为线程池的工作队列会对线程池带来如下影响 ：

1. 当线程池中的线程数达到 corePoolSize 后，新任务将在无界队列中等待，因此线程池中的线程数不会超过 corePoolSize；
2. 由于使用无界队列时 maximumPoolSize 将是一个无效参数，因为不可能存在任务队列满的情况。所以，通过创建 FixedThreadPool的源码可以看出创建的 FixedThreadPool 的 corePoolSize 和 maximumPoolSize 被设置为同一个值。
3. 由于 1 和 2，使用无界队列时 keepAliveTime 将是一个无效参数；
4. 运行中的 FixedThreadPool（未执行 shutdown()或 shutdownNow()）不会拒绝任务，在任务比较多的时候会导致 OOM（内存溢出）。

4.2 SingleThreadExecutor 详解

创建一个单线程化的 Executor，SingleThreadExecutor适用于串行执行任务的场景，每个任务按顺序执行，不需要并发执行；

4.2.1 介绍

SingleThreadExecutor 是只有一个线程的线程池。下面看看SingleThreadExecutor 的实现：

   /**     *返回只有一个线程的线程池     */    public static ExecutorService newSingleThreadExecutor(ThreadFactory threadFactory) { return new FinalizableDelegatedExecutorService     (new ThreadPoolExecutor(1, 1, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>(), threadFactory));    }

   public static ExecutorService newSingleThreadExecutor() { return new FinalizableDelegatedExecutorService     (new ThreadPoolExecutor(1, 1, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>()));    }

从上面源代码可以看出新创建的 SingleThreadExecutor 的 corePoolSize 和 maximumPoolSize 都被设置为 1.其他参数和 FixedThreadPool 相同。

4.2.2 执行任务过程介绍

SingleThreadExecutor 的运行示意图（该图片来源：《Java 并发编程的艺术》）：

上图说明 :

1. 如果当前运行的线程数少于 corePoolSize，则创建一个新的线程执行任务；
2. 当前线程池中有一个运行的线程后，将任务加入 LinkedBlockingQueue
3. 线程执行完当前的任务后，会在循环中反复从LinkedBlockingQueue 中获取任务来执行；

4.2.3 为什么不推荐使用SingleThreadExecutor？

SingleThreadExecutor 使用无界队列 LinkedBlockingQueue 作为线程池的工作队列（队列的容量为 Intger.MAX_VALUE）。SingleThreadExecutor 使用无界队列作为线程池的工作队列会对线程池带来的影响与 FixedThreadPool 相同。说简单点就是可能会导致 OOM，

4.3 CachedThreadPool 详解

创建一个可缓存的线程池，调用 execute 将重用以前构造的线程（如果线程可用）。如果没有可用的线程，则创建一个新线程并添加到线程池中。终止并从缓存中移除那些已有 60 秒钟未被使用的线程。CachedThreadPool适用于并发执行大量短期耗时短的任务，或者负载较轻的服务器；

4.3.1 介绍

CachedThreadPool 是一个会根据需要创建新线程的线程池。下面通过源码来看看 CachedThreadPool 的实现：

    /**     * 创建一个线程池，根据需要创建新线程，但会在先前构建的线程可用时重用它。     */    public static ExecutorService newCachedThreadPool(ThreadFactory threadFactory) { return new ThreadPoolExecutor(0, Integer.MAX_VALUE,   60L, TimeUnit.SECONDS,   new SynchronousQueue<Runnable>(),   threadFactory);    }

    public static ExecutorService newCachedThreadPool() { return new ThreadPoolExecutor(0, Integer.MAX_VALUE,   60L, TimeUnit.SECONDS,   new SynchronousQueue<Runnable>());    }

CachedThreadPool 的corePoolSize 被设置为空（0），maximumPoolSize被设置为 Integer.MAX.VALUE，即它是无界的，这也就意味着如果主线程提交任务的速度高于 maximumPool 中线程处理任务的速度时，CachedThreadPool 会不断创建新的线程。极端情况下，这样会导致耗尽 cpu 和内存资源。

4.3.2 执行任务过程介绍

CachedThreadPool 的 execute() 方法的执行示意图（该图片来源：《Java 并发编程的艺术》）：

上图说明：

1. 首先执行 SynchronousQueue.offer(Runnable task) 提交任务到任务队列。如果当前 maximumPool 中有闲线程正在执行 SynchronousQueue.poll(keepAliveTime,TimeUnit.NANOSECONDS)，那么主线程执行 offer 操作与空闲线程执行的 poll 操作配对成功，主线程把任务交给空闲线程执行，execute()方法执行完成，否则执行下面的步骤 2；
2. 当初始 maximumPool 为空，或者 maximumPool 中没有空闲线程时，将没有线程执行 SynchronousQueue.poll(keepAliveTime,TimeUnit.NANOSECONDS)。这种情况下，步骤 1 将失败，此时 CachedThreadPool 会创建新线程执行任务，execute 方法执行完成；

4.3.3 为什么不推荐使用CachedThreadPool？

CachedThreadPool允许创建的线程数量为 Integer.MAX_VALUE ，可能会创建大量线程，从而导致 OOM。

4.2. ScheduledThreadPoolExecutor 详解

ScheduledThreadPoolExecutor 主要用来在给定的延迟后运行任务，或者定期执行任务。 这个在实际项目中基本不会被用到，也不推荐使用，大家只需要简单了解一下它的思想即可。

4.2.1 简介

ScheduledThreadPoolExecutor 使用的任务队列 DelayQueue 封装了一个 PriorityQueue，PriorityQueue 会对队列中的任务进行排序，执行所需时间短的放在前面先被执行(ScheduledFutureTask 的 time 变量小的先执行)，如果执行所需时间相同则先提交的任务将被先执行(ScheduledFutureTask 的 squenceNumber 变量小的先执行)。

ScheduledThreadPoolExecutor 和 Timer 的比较：

• Timer 对系统时钟的变化敏感，ScheduledThreadPoolExecutor不是；
• Timer 只有一个执行线程，因此长时间运行的任务可以延迟其他任务。 ScheduledThreadPoolExecutor 可以配置任意数量的线程。 此外，如果你想（通过提供 ThreadFactory），你可以完全控制创建的线程;
• 在TimerTask 中抛出的运行时异常会杀死一个线程，从而导致 Timer 死机:-( …即计划任务将不再运行。ScheduledThreadExecutor 不仅捕获运行时异常，还允许您在需要时处理它们（通过重写 afterExecute 方法ThreadPoolExecutor）。抛出异常的任务将被取消，但其他任务将继续运行。

综上，在 JDK1.5 之后，你没有理由再使用 Timer 进行任务调度了。

4.2.2 运行机制

ScheduledThreadPoolExecutor 的执行主要分为两大部分：

1. 当调用 ScheduledThreadPoolExecutor 的 scheduleAtFixedRate() 方法或者 scheduleWithFixedDelay() 方法时，会向 ScheduledThreadPoolExecutor 的 DelayQueue 添加一个实现了 RunnableScheduledFuture 接口的 ScheduledFutureTask 。
2. 线程池中的线程从 DelayQueue 中获取 ScheduledFutureTask，然后执行任务。

ScheduledThreadPoolExecutor 为了实现周期性的执行任务，对 ThreadPoolExecutor做了如下修改：

• 使用 DelayQueue 作为任务队列；
• 获取任务的方不同
• 执行周期任务后，增加了额外的处理

4.2.3 ScheduledThreadPoolExecutor 执行周期任务的步骤

1. 线程 1 从 DelayQueue 中获取已到期的 ScheduledFutureTask（DelayQueue.take()）。到期任务是指 ScheduledFutureTask的 time 大于等于当前系统的时间；
2. 线程 1 执行这个 ScheduledFutureTask；
3. 线程 1 修改 ScheduledFutureTask 的 time 变量为下次将要被执行的时间；
4. 线程 1 把这个修改 time 之后的 ScheduledFutureTask 放回 DelayQueue 中（DelayQueue.add())。

5. 推荐使用 ThreadPoolExecutor 构造函数创建线程池

在《阿里巴巴 Java 开发手册》“并发处理”这一章节，明确指出线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。

为什么呢？

使用线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源开销，解决资源不足的问题。如果不使用线程池，有可能会造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题。

另外，《阿里巴巴 Java 开发手册》中强制线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 构造函数的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险

Executors 返回线程池对象的弊端如下(后文会详细介绍到)：

• FixedThreadPool 和 SingleThreadExecutor ： 允许请求的队列长度为 Integer.MAX_VALUE,可能堆积大量的请求，从而导致 OOM。
• CachedThreadPool 和 ScheduledThreadPool ： 允许创建的线程数量为 Integer.MAX_VALUE ，可能会创建大量线程，从而导致 OOM。

方式一：通过ThreadPoolExecutor构造函数实现（推荐）

方式二：通过 Executor 框架的工具类 Executors 来实现 我们可以创建三种类型的 ThreadPoolExecutor：

• FixedThreadPool
• SingleThreadExecutor
• CachedThreadPool

对应 Executors 工具类中的方法如图所示：

6. 线程池大小确定

线程池数量的确定一直是困扰着程序员的一个难题，大部分程序员在设定线程池大小的时候就是随心而定。

很多人甚至可能都会觉得把线程池配置过大一点比较好！我觉得这明显是有问题的。就拿我们生活中非常常见的一例子来说：并不是人多就能把事情做好，增加了沟通交流成本。你本来一件事情只需要 3 个人做，你硬是拉来了 6 个人，会提升做事效率嘛？我想并不会。 线程数量过多的影响也是和我们分配多少人做事情一样，对于多线程这个场景来说主要是增加了上下文切换成本。不清楚什么是上下文切换的话，可以看我下面的介绍。

上下文切换：

多线程编程中一般线程的个数都大于 CPU 核心的个数，而一个 CPU 核心在任意时刻只能被一个线程使用，为了让这些线程都能得到有效执行，CPU 采取的策略是为每个线程分配时间片并轮转的形式。当一个线程的时间片用完的时候就会重新处于就绪状态让给其他线程使用，这个过程就属于一次上下文切换。概括来说就是：当前任务在执行完 CPU 时间片切换到另一个任务之前会先保存自己的状态，以便下次再切换回这个任务时，可以再加载这个任务的状态。任务从保存到再加载的过程就是一次上下文切换。

上下文切换通常是计算密集型的。也就是说，它需要相当可观的处理器时间，在每秒几十上百次的切换中，每次切换都需要纳秒量级的时间。所以，上下文切换对系统来说意味着消耗大量的 CPU 时间，事实上，可能是操作系统中时间消耗最大的操作。

Linux 相比与其他操作系统（包括其他类 Unix 系统）有很多的优点，其中有一项就是，其上下文切换和模式切换的时间消耗非常少。

类比于现实世界中的人类通过合作做某件事情，我们可以肯定的一点是线程池大小设置过大或者过小都会有问题，合适的才是最好。

如果我们设置的线程池数量太小的话，如果同一时间有大量任务/请求需要处理，可能会导致大量的请求/任务在任务队列中排队等待执行，甚至会出现任务队列满了之后任务/请求无法处理的情况，或者大量任务堆积在任务队列导致 OOM。这样很明显是有问题的！ CPU 根本没有得到充分利用。

但是，如果我们设置线程数量太大，大量线程可能会同时在争取 CPU 资源，这样会导致大量的上下文切换，从而增加线程的执行时间，影响了整体执行效率。

1. 有一个简单并且适用面比较广的公式：

• CPU 密集型任务(N+1)： 这种任务消耗的主要是 CPU 资源，可以将线程数设置为 N（CPU 核心数）+1，比 CPU 核心数多出来的一个线程是为了防止线程偶发的缺页中断，或者其它原因导致的任务暂停而带来的影响。一旦任务暂停，CPU 就会处于空闲状态，而在这种情况下多出来的一个线程就可以充分利用 CPU 的空闲时间。
• I/O 密集型任务(2N)： 这种任务应用起来，系统会用大部分的时间来处理 I/O 交互，而线程在处理 I/O 的时间段内不会占用 CPU 来处理，这时就可以将 CPU 交出给其它线程使用。因此在 I/O 密集型任务的应用中，我们可以多配置一些线程，具体的计算方法是 2N。

2. 一个复杂点的公式：在工程实践中，通常使用下述公式来计算核心线程数：

nThreads=(w+c)/c*n*u=(w/c+1)*n*u

其中，w为等待时间，c为计算时间，n为CPU核心数（通常可通过 Runtime.getRuntime().availableProcessors()方法获取），u为CPU目标利用率（取值区间为[0, 1]）；在最大化CPU利用率的情况下，当处理的任务为计算密集型任务时，即等待时间w为0，此时核心线程数等于CPU核心数。

上述计算公式是理想情况下的建议核心线程数，而不同系统/应用在运行不同的任务时可能会有一定的差异，因此最佳线程数参数还需要根据任务的实际运行情况和压测表现进行微调。

如何判断是 CPU 密集任务还是 IO 密集任务？

CPU 密集型简单理解就是利用 CPU 计算能力的任务比如你在内存中对大量数据进行排序。但凡涉及到网络读取，文件读取这类都是 IO 密集型，这类任务的特点是 CPU 计算耗费时间相比于等待 IO 操作完成的时间来说很少，大部分时间都花在了等待 IO 操作完成上。

7. 避免使用局部线程池

使用局部线程池时，若任务执行完后没有执行shutdown()方法或有其他不当引用，极易造成系统资源耗尽。

8. 增加异常处理

为了更好地发现、分析和解决问题，建议在使用多线程时增加对异常的处理，异常处理通常有下述方案：

1. 在任务代码处增加try…catch异常处理
2. 如果使用的Future方式，则可通过Future对象的get方法接收抛出的异常
3. 为工作线程设置setUncaughtExceptionHandler，在uncaughtException方法中处理异常

9. 优雅关闭线程池

public void destroy() { try {     poolExecutor.shutdown();     if (!poolExecutor.awaitTermination(AWAIT_TIMEOUT, TimeUnit.SECONDS)) {  poolExecutor.shutdownNow();     } } catch (InterruptedException e) {     // 如果当前线程被中断，重新取消所有任务     pool.shutdownNow();     // 保持中断状态     Thread.currentThread().interrupt(); }    }

为了实现优雅停机的目标，我们应当先调用shutdown方法，调用这个方法也就意味着，这个线程池不会再接收任何新的任务，但是已经提交的任务还会继续执行。之后我们还应当调用awaitTermination方法，这个方法可以设定线程池在关闭之前的最大超时时间，如果在超时时间结束之前线程池能够正常关闭则会返回true，否则，超时会返回false。通常我们需要根据业务场景预估一个合理的超时时间，然后调用该方法。

如果awaitTermination方法返回false，但又希望尽可能在线程池关闭之后再做其他资源回收工作，可以考虑再调用一下shutdownNow方法，此时队列中所有尚未被处理的任务都会被丢弃，同时会设置线程池中每个线程的中断标志位。shutdownNow并不保证一定可以让正在运行的线程停止工作，除非提交给线程的任务能够正确响应中断。

10. 几个常见的对比

10.1 Runnable vs Callable

Runnable自 Java 1.0 以来一直存在，但Callable仅在 Java 1.5 中引入,目的就是为了来处理Runnable不支持的用例。Runnable 接口不会返回结果或抛出检查异常，但是 Callable 接口可以。所以，如果任务不需要返回结果或抛出异常推荐使用 Runnable 接口，这样代码看起来会更加简洁。

工具类 Executors 可以实现将 Runnable 对象转换成 Callable 对象。（Executors.callable(Runnable task) 或 Executors.callable(Runnable task, Object result)）。

Runnable.java

@FunctionalInterfacepublic interface Runnable {   /**    * 被线程执行，没有返回值也无法抛出异常    */    public abstract void run();}

Callable.java

@FunctionalInterfacepublic interface Callable<V> {    /**     * 计算结果，或在无法这样做时抛出异常。     * @return 计算得出的结果     * @throws 如果无法计算结果，则抛出异常     */    V call() throws Exception;}

10.2 execute() vs submit()

• execute()方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功与否；
• submit()方法用于提交需要返回值的任务。线程池会返回一个 Future 类型的对象，通过这个 Future 对象可以判断任务是否执行成功，并且可以通过 Future 的 get()方法来获取返回值，get()方法会阻塞当前线程直到任务完成，而使用 get（long timeout，TimeUnit unit）方法的话，如果在 timeout 时间内任务还没有执行完，就会抛出 java.util.concurrent.TimeoutException。

这里只是为了演示使用，推荐使用 ThreadPoolExecutor 构造方法来创建线程池。

示例1：使用 get() 方法获取返回值。

ExecutorService executorService = Executors.newFixedThreadPool(3);Future<String> submit = executorService.submit(() -> {    try { Thread.sleep(5000L);    } catch (InterruptedException e) { e.printStackTrace();    }    return "abc";});String s = submit.get();System.out.println(s);executorService.shutdown();

输出：

abc

示例2：使用 get（long timeout，TimeUnit unit） 方法获取返回值。

ExecutorService executorService = Executors.newFixedThreadPool(3);Future<String> submit = executorService.submit(() -> {    try { Thread.sleep(5000L);    } catch (InterruptedException e) { e.printStackTrace();    }    return "abc";});String s = submit.get(3, TimeUnit.SECONDS);System.out.println(s);executorService.shutdown();

输出：

Exception in thread "main" java.util.concurrent.TimeoutExceptionat java.util.concurrent.FutureTask.get(FutureTask.java:205)

10.3 shutdown()VSshutdownNow()

• shutdown（） :关闭线程池，线程池的状态变为 SHUTDOWN。线程池不再接受新任务了，但是队列里的任务得执行完毕。
• shutdownNow（） :关闭线程池，线程的状态变为 STOP。线程池会终止当前正在运行的任务，并停止处理排队的任务并返回正在等待执行的 List。

10.4 isTerminated() VS isShutdown()

• isShutDown 当调用 shutdown() 方法后返回为 true。
• isTerminated 当调用 shutdown() 方法后，并且所有提交的任务完成后返回为 true

10.5 加餐:Callable+ThreadPoolExecutor示例代码

MyCallable.java

import java.util.concurrent.Callable;public class MyCallable implements Callable<String> {    @Override    public String call() throws Exception { Thread.sleep(1000); //返回执行当前 Callable 的线程名字 return Thread.currentThread().getName();    }}

CallableDemo.java

import java.util.ArrayList;import java.util.Date;import java.util.List;import java.util.concurrent.ArrayBlockingQueue;import java.util.concurrent.Callable;import java.util.concurrent.ExecutionException;import java.util.concurrent.Future;import java.util.concurrent.ThreadPoolExecutor;import java.util.concurrent.TimeUnit;public class CallableDemo {    private static final int CORE_POOL_SIZE = 5;    private static final int MAX_POOL_SIZE = 10;    private static final int QUEUE_CAPACITY = 100;    private static final Long KEEP_ALIVE_TIME = 1L;    public static void main(String[] args) { //使用阿里巴巴推荐的创建线程池的方式 //通过ThreadPoolExecutor构造函数自定义参数创建 ThreadPoolExecutor executor = new ThreadPoolExecutor(  CORE_POOL_SIZE,  MAX_POOL_SIZE,  KEEP_ALIVE_TIME,  TimeUnit.SECONDS,  new ArrayBlockingQueue<>(QUEUE_CAPACITY),  new ThreadPoolExecutor.CallerRunsPolicy()); List<Future<String>> futureList = new ArrayList<>(); Callable<String> callable = new MyCallable(); for (int i = 0; i < 10; i++) {     //提交任务到线程池     Future<String> future = executor.submit(callable);     //将返回值 future 添加到 list，我们可以通过 future 获得 执行 Callable 得到的返回值     futureList.add(future); } for (Future<String> fut : futureList) {     try {  System.out.println(new Date() + "::" + fut.get());     } catch (InterruptedException | ExecutionException e) {  e.printStackTrace();     } } //关闭线程池 executor.shutdown();    }}

Output:

Wed Nov 13 13:40:41 CST 2019::pool-1-thread-1Wed Nov 13 13:40:42 CST 2019::pool-1-thread-2Wed Nov 13 13:40:42 CST 2019::pool-1-thread-3Wed Nov 13 13:40:42 CST 2019::pool-1-thread-4Wed Nov 13 13:40:42 CST 2019::pool-1-thread-5Wed Nov 13 13:40:42 CST 2019::pool-1-thread-3Wed Nov 13 13:40:43 CST 2019::pool-1-thread-2Wed Nov 13 13:40:43 CST 2019::pool-1-thread-1Wed Nov 13 13:40:43 CST 2019::pool-1-thread-4Wed Nov 13 13:40:43 CST 2019::pool-1-thread-5

11.监测线程池运行状态

你可以通过一些手段来检测线程池的运行状态比如 SpringBoot 中的 Actuator 组件。

除此之外，我们还可以利用 ThreadPoolExecutor 的相关 API做一个简陋的监控。从下图可以看出， ThreadPoolExecutor提供了获取线程池当前的线程数和活跃线程数、已经执行完成的任务数、正在排队中的任务数等等。

下面是一个简单的 Demo。printThreadPoolStatus()会每隔一秒打印出线程池的线程数、活跃线程数、完成的任务数、以及队列中的任务数。

    /**     * 打印线程池的状态     *     * @param threadPool 线程池对象     */    public static void printThreadPoolStatus(ThreadPoolExecutor threadPool) { ScheduledExecutorService scheduledExecutorService = new ScheduledThreadPoolExecutor(1, createThreadFactory("print-images/thread-pool-status", false)); scheduledExecutorService.scheduleAtFixedRate(() -> {     log.info("=========================");     log.info("ThreadPool Size: [{}]", threadPool.getPoolSize());     log.info("Active Threads: {}", threadPool.getActiveCount());     log.info("Number of Tasks : {}", threadPool.getCompletedTaskCount());     log.info("Number of Tasks in Queue: {}", threadPool.getQueue().size());     log.info("========================="); }, 0, 1, TimeUnit.SECONDS);    }

12.建议不同类别的业务用不同的线程池

很多人在实际项目中都会有类似这样的问题：我的项目中多个业务需要用到线程池，是为每个线程池都定义一个还是说定义一个公共的线程池呢？

一般建议是不同的业务使用不同的线程池，配置线程池的时候根据当前业务的情况对当前线程池进行配置，因为不同的业务的并发以及对资源的使用情况都不同，重心优化系统性能瓶颈相关的业务。

我们再来看一个真实的事故案例！ (本案例来源自：《线程池运用不当的一次线上事故》open in new window ，很精彩的一个案例)

上面的代码可能会存在死锁的情况，为什么呢？画个图给大家捋一捋。

试想这样一种极端情况：假如我们线程池的核心线程数为 n，父任务（扣费任务）数量为 n，父任务下面有两个子任务（扣费任务下的子任务），其中一个已经执行完成，另外一个被放在了任务队列中。由于父任务把线程池核心线程资源用完，所以子任务因为无法获取到线程资源无法正常执行，一直被阻塞在队列中。父任务等待子任务执行完成，而子任务等待父任务释放线程池资源，这也就造成了 “死锁”。

解决方法也很简单，就是新增加一个用于执行子任务的线程池专门为其服务。

13. 别忘记给线程池命名

初始化线程池的时候需要显示命名（设置线程池名称前缀），有利于定位问题。

默认情况下创建的线程名字类似 pool-1-thread-n 这样的，没有业务含义，不利于我们定位问题。

给线程池里的线程命名通常有下面两种方式：

**1.利用 guava 的 ThreadFactoryBuilder **

ThreadFactory threadFactory = new ThreadFactoryBuilder()   .setNameFormat(threadNamePrefix + "-%d")   .setDaemon(true).build();ExecutorService threadPool = new ThreadPoolExecutor(corePoolSize, maximumPoolSize, keepAliveTime, TimeUnit.MINUTES, workQueue, threadFactory)

1
2
3
4

2.自己实现 ThreadFactor。

import java.util.concurrent.Executors;import java.util.concurrent.ThreadFactory;import java.util.concurrent.atomic.AtomicInteger;/** * 线程工厂，它设置线程名称，有利于我们定位问题。 */public final class NamingThreadFactory implements ThreadFactory {    private final AtomicInteger threadNum = new AtomicInteger();    private final ThreadFactory delegate;    private final String name;    /**     * 创建一个带名字的线程池生产工厂     */    public NamingThreadFactory(ThreadFactory delegate, String name) { this.delegate = delegate; this.name = name; // TODO consider uniquifying this    }    @Override     public Thread newThread(Runnable r) { Thread t = delegate.newThread(r); t.setName(name + " [#" + threadNum.incrementAndGet() + "]"); return t;    }}

14 .美团的骚操作

美团技术团队在《Java线程池实现原理及其在美团业务中的实践》open in new window这篇文章中介绍到对线程池参数实现可自定义配置的思路和方法。

美团技术团队的思路是主要对线程池的核心参数实现自定义可配置。这三个核心参数是：

• corePoolSize : 核心线程数线程数定义了最小可以同时运行的线程数量。
• maximumPoolSize : 当队列中存放的任务达到队列容量的时候，当前可以同时运行的线程数量变为最大线程数。
• workQueue: 当新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。

为什么是这三个参数？

我在这篇《新手也能看懂的线程池学习总结》open in new window 中就说过这三个参数是 ThreadPoolExecutor 最重要的参数，它们基本决定了线程池对于任务的处理策略。

如何支持参数动态配置？ 且看 ThreadPoolExecutor 提供的下面这些方法。

格外需要注意的是corePoolSize， 程序运行期间的时候，我们调用 setCorePoolSize（） 这个方法的话，线程池会首先判断当前工作线程数是否大于corePoolSize，如果大于的话就会回收工作线程。

另外，你也看到了上面并没有动态指定队列长度的方法，美团的方式是自定义了一个叫做 ResizableCapacityLinkedBlockIngQueue 的队列（主要就是把LinkedBlockingQueue的capacity 字段的final关键字修饰给去掉了，让它变为可变的）。

最终实现的可动态修改线程池参数效果如下。👏👏👏

还没看够？推荐 why神的《如何设置线程池参数？美团给出了一个让面试官虎躯一震的回答。》open in new window这篇文章，深度剖析，很不错哦！