线程池概述

1、基本概念

    public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) {
    }

1.1、主要参数

序号	参数	含义
1	corePoolSize	核心线程数量
2	maximumPoolSize	最大线程数量
3	keepAliveTime	线程最大空闲时间
4	unit	空闲时间单位
5	workQueue	线程的等待队列
6	threadFactory	线程创建工厂
7	handler	拒绝策略

1.2、拒绝策略

1.2.1、AbortPolicy（中止策略）

这是线程池默认的拒绝策略，在任务不能再提交的时候，抛出异常RejectedExecutionException，及时反馈程序运行状态。
如果是比较关键的业务，推荐使用此拒绝策略，这样子在系统不能承载更大的并发量的时候，能够及时的通过异常发现。

1.2.2、DiscardPolicy（丢弃策略）

丢弃任务，但是不抛出异常。如果线程队列已满，则后续提交的任务都会被丢弃，且是静默丢弃。

场景：一些无关紧要的业务采用此策略

1.2.3、DiscardOldestPolicy（弃老策略）

丢弃队列最前面的任务，然后重新提交被拒绝的任务。

场景：发布消息和修改消息，当消息发布出去后，还未执行，此时更新的消息又来了，这个时候未执行的消息的版本比现在提交的消息版本要低就可以被丢弃了。因为队列中还有可能存在消息版本更低的消息会排队执行，所以在真正处理消息的时候一定要做好消息的版本比较

1.2.4、CallerRunsPolicy（调用者运行策略）

由调用线程处理该任务，如果任务被拒绝了，则由调用线程（提交任务的线程）直接执行此任务，我们可以通过代码来验证这一点：

场景：一般在不允许失败的、对性能要求不高、并发量较小的场景下使用

1.2.5、自定义拒绝策略

public class ThreadPoolTest {
    public static void main(String[] args) {
        ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(5, 5, 10, TimeUnit.SECONDS, new ArrayBlockingQueue<>(10), new RejectedExecutionHandler() {
            @Override
            public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
                System.out.println("我是自定义的拒绝策略");
                r.run();
            }
        });
        for (int i=0;i<100000;i++){
            threadPoolExecutor.execute(new TaskDemo());
        }
    }

}
class TaskDemo implements Runnable{

    @Override
    public void run() {
        try {
            TimeUnit.SECONDS.sleep(3);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(Thread.currentThread().getName() + "执行完毕！");
    }
}

1.2.6、Dubbo提供的拒绝策略

public static class AbortPolicy implements RejectedExecutionHandler;

public class AbortPolicyWithReport extends ThreadPoolExecutor.AbortPolicy {
	protected static final Logger logger = LoggerFactory.getLogger(AbortPolicyWithReport.class);
	private final String threadName;
	private final URL url;
	private static volatile long lastPrintTime = 0;
	private static Semaphore guard = new Semaphore(1);
	public AbortPolicyWithReport(String threadName, URL url) {
		this.threadName = threadName;
		this.url = url;
	 }
	@Override
	public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
		String msg = String.format("Thread pool is EXHAUSTED!" +
	" Thread Name: %s, Pool Size: %d (active: %d, core: %d, max: %d, largest: %d), Task: %d (completed: %d)," +
	" Executor status:(isShutdown:%s, isTerminated:%s, isTerminating:%s), in %s://%s:%d!",
	threadName, e.getPoolSize(), e.getActiveCount(), e.getCorePoolSize(),e.getMaximumPoolSize(), e.getLargestPoolSize(),
	e.getTaskCount(), e.getCompletedTaskCount(), e.isShutdown(), e.isTerminated(), e.isTerminating(),
	url.getProtocol(), url.getIp(), url.getPort());
		logger.warn(msg);
		dumpJStack();
		throw new RejectedExecutionException(msg);
	}
	private void dumpJStack() {
	//省略实现
	}
}

本质是中止策略，只不过它的处理方式会让使用者更清楚触发线程拒绝策略的真实原因

1. 输出了一条警告级别的日志，日志内容为线程池的详细设置参数，以及线程池当前的状态，还有当前拒绝任务的一些详细信息。可以说，这条日志，使用dubbo的有过生产运维经验的或多或少是见过的，这个日志简直就是日志打印的典范（spring的日志一样很优秀），得益于这么详细的日志，可以很容易定位到问题所在
2. 输出当前线程堆栈详情，当你通过上面的日志信息还不能定位问题时，案发现场的dump线程上下文信息就是你发现问题的救命稻草。
3. 继续抛出拒绝执行异常，使本次任务失败，这个继承了JDK默认拒绝策略的特性

1.2.7、Netty提供的拒绝策略

private static final class NewThreadRunsPolicy implements RejectedExecutionHandler {
 	NewThreadRunsPolicy() {
		super();
 	}
 	public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
 		try {
 			final Thread t = new Thread(r, "Temporary task executor");
 			t.start();
 		} catch (Throwable e) {
			 throw new RejectedExecutionException(
 			"Failed to start a new thread", e);
 		}
	 }
 }

Netty中的实现很像JDK中的CallerRunsPolicy，舍不得丢弃任务。不同的是，CallerRunsPolicy是直接在调用者线程执行的任务。而 Netty是新建了一个线程来处理的。所以，Netty的实现相较于调用者执行策略的使用面就可以扩展到支持高效率高性能的场景了。但是也要注意一点，Netty的实现里，在创建线程时未做任何的判断约束，也就是说只要系统还有资源就会创建新的线程来处理，直到new不出新的线程了，才会抛创建线程失败的异常

1.2.8、activeMq中的线程池拒绝策略

new RejectedExecutionHandler() {
 	@Override
	public void rejectedExecution(final Runnable r, final ThreadPoolExecutor executor) {
 		try {
 			executor.getQueue().offer(r, 60, TimeUnit.SECONDS);
		} catch (InterruptedException e) {
 			throw new RejectedExecutionException("Interrupted waiting for BrokerService.worker");
 		}
 		throw new RejectedExecutionException("Timed Out while attempting to enqueue Task.");
 	}
 });

activeMq中的策略属于最大努力执行任务型，当触发拒绝策略时，在尝试一分钟的时间重新将任务塞进任务队列，当一分钟超时还没成功时，就抛出异常

1.2.9、pinpoint中的线程池拒绝策略

public class RejectedExecutionHandlerChain implements RejectedExecutionHandler {
	private final RejectedExecutionHandler[] handlerChain;
	public static RejectedExecutionHandler build(List<RejectedExecutionHandler> chain) {
		Objects.requireNonNull(chain, "handlerChain must not be null");
		RejectedExecutionHandler[] handlerChain = chain.toArray(new RejectedExecutionHandler[0]);
		return new RejectedExecutionHandlerChain(handlerChain);
	}
	private RejectedExecutionHandlerChain(RejectedExecutionHandler[] handlerChain) {
		this.handlerChain = Objects.requireNonNull(handlerChain, "handlerChain must not be null");
	}
	@Override
	public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
		for (RejectedExecutionHandler rejectedExecutionHandler : handlerChain) {
			rejectedExecutionHandler.rejectedExecution(r, executor);
		}
	}
}

pinpoint的拒绝策略是定义了一个拒绝策略链，包装了一个拒绝策略列表，当触发拒绝策略时，会将策略链中的rejectedExecution依次执行一遍

2、工作原理

3、Executors

3.1、newFixedThreadPool

创建固定数目线程的线程池。

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

1、核心线程数量于最大线程的数量相等，都是nThreads;
2、等待任务存放的队列使用的是无界队列进行存放。以下是LinkedBlockingQueue的默认构造方法；

   public LinkedBlockingQueue() {
     this(Integer.MAX_VALUE);
}

3、拒绝策略采用的是默认拒绝策略AbortPolicy，当任务不能进行提交的时候，抛出异常，由于任务队列是无界队列，所以可能该拒绝策略不会生效，直到OOM，这也是为何不建议使用该方法创建线程池的重要原因。

3.2、newCachedThreadPool

创建一个可缓存的线程池，调用execute 将重用以前构造的线程（如果线程可用）。如果没有可用的线程，则创建一个新线程并添加到池中。终止并从缓存中移除那些已有 60 秒钟未被使用的线程。

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

1、它是一个可以无限扩大的线程池；
2、它比较适合处理执行时间比较小的任务；
3、corePoolSize为0，maximumPoolSize为无限大，意味着线程数量可以无限大；
4、keepAliveTime为60S，意味着线程空闲时间超过60S就会被杀死；
5、采用SynchronousQueue装等待的任务，这个阻塞队列没有存储空间，默认是非公平的，这意味着只要有请求到来，就必须要找到一条工作线程处理他，如果当前没有空闲的线程，那么就会再创建一条新的线程，如果任务执行时间过长，则近似于无线创建线程，造成OOM

3.3、SingleThreadExecutor

创建一个单线程化的Executor。

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

1、它只会创建一条工作线程处理任务；
2、采用的阻塞队列为无界队列LinkedBlockingQueue；

3.4、ScheduledThreadPool

创建一个支持定时及周期性的任务执行的线程池，多数情况下可用来替代Timer类。

    public static ScheduledExecutorService newSingleThreadScheduledExecutor() {
        return new DelegatedScheduledExecutorService
            (new ScheduledThreadPoolExecutor(1));
    }

Timer	ScheduledThreadPoolExecutor
单线程	多线程
单个任务执行时间影响其他任务调度	多线程，不会影响
基于绝对时间	基于相对时间
一旦执行任务出现异常不会捕获，其他任务得不到执行	多线程，单个任务的执行不会影响其他线程

它接收SchduledFutureTask类型的任务，有两种提交任务的方式：
scheduledAtFixedRate

public ScheduledFuture<?> scheduleAtFixedRate(Runnable command,
                                             long initialDelay,
                                             long period,
                                             TimeUnit unit) 

scheduledWithFixedDelay

public ScheduledFuture<?> scheduleWithFixedDelay(Runnable command,
                                                 long initialDelay,
                                                 long delay,
                                                 TimeUnit unit)

4、线程池的使用

显示的创建线程池

private static ExecutorService executor = new ThreadPoolExecutor(10, 10,
        60L, TimeUnit.SECONDS,
        new ArrayBlockingQueue(10));

利用第三方库创建线程池

public class ExecutorsDemo {

    private static ThreadFactory namedThreadFactory = new ThreadFactoryBuilder()
        .setNameFormat("demo-pool-%d").build();

    private static ExecutorService pool = new ThreadPoolExecutor(5, 200,
        0L, TimeUnit.MILLISECONDS,
        new LinkedBlockingQueue<Runnable>(1024), namedThreadFactory, new ThreadPoolExecutor.AbortPolicy());

    public static void main(String[] args) {

        for (int i = 0; i < Integer.MAX_VALUE; i++) {
            pool.execute(new SubThread());
        }
    }
}

5、常见问题

5.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之前的实现是，必须等队列满了之后，才开始消费。

5.2、线程池创建之后，会立即创建核心线程么？

  不会。从上面的源码可以看出，在刚刚创建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.

5.3、核心线程永远不会销毁么？

  虽然在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，但实现细节其实不同。

5.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);

        // allowCoreThreadTimeOut ：核心线程超时是否需要关闭
        // wc > corePoolSize：当前工作线程数是否大于核心线程数量
        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.5、空闲线程过多会有什么问题？

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

一个线程的内存模型：虚拟机栈、本地方法栈、程序计数器

ThreadLocal：业务代码是否使用了ThreadLocal？就算没有，Spring框架中也大量使用了ThreadLocal；

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

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

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

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

5.6、keepAliveTime=0会怎么样？

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

默认情况下，keepAliveTime小于0，初始化的时候才会报错；

但如果allowsCoreThreadTimeOut，keepAliveTime必须大于0，不然初始化报错。

    public void allowCoreThreadTimeOut(boolean value) {
        if (value && keepAliveTime <= 0)
            throw new IllegalArgumentException("Core threads must have nonzero keep alive times");
        if (value != allowCoreThreadTimeOut) {
            allowCoreThreadTimeOut = value;
            if (value)
                interruptIdleWorkers();
        }
    }

5.7、怎么进行异常处理?

很多代码的写法，我们都习惯按照常见范式去编写，而没有去思考为什么。比如：

如果我们使用execute()提交任务，我们一般要在Runable任务的代码加上try-catch进行异常处理。
如果我们使用submit()提交任务，我们一般要在主线程中，对Future.get()进行try-catch进行异常处理。

—— 但是在上面，我提到过，submit()底层实现依赖execute()，两者应该统一呀，为什么有差异呢？下面再扒一扒submit()的源码，它的实现蛮有意思。

首先，ThreadPoolExecutor中没有submit的代码，而是在它的父类AbstractExecutorService中，有三个submit的重载方法，代码非常简单，关键代码就两行：

public Future<?> submit(Runnable task) {
    if (task == null) throw new NullPointerException();
    RunnableFuture<Void> ftask = newTaskFor(task, null);
    execute(ftask);
    return ftask;
}
public <T> Future<T> submit(Runnable task, T result) {
    if (task == null) throw new NullPointerException();
    RunnableFuture<T> ftask = newTaskFor(task, result);
    execute(ftask);
    return ftask;
}
public <T> Future<T> submit(Callable<T> task) {
    if (task == null) throw new NullPointerException();
    RunnableFuture<T> ftask = newTaskFor(task);
    execute(ftask);
    return ftask;
}

正是因为这三个重载方法，都调用了execute，submit底层依赖execute。通过查看这里execute的实现，我们不难发现，它就是ThreadPoolExecutor中的实现，所以，造成submit和execute的差异化的代码，不在这。那么造成差异的一定在newTaskFor方法中。这个方法也就new了一个FutureTask而已，FutureTask实现RunnableFuture接口，RunnableFuture接口继承Runnable接口和Future接口。而Callable只是FutureTask的一个成员变量。

所以讲到这里，就有另一个Java基础知识点：Callable和Future的关系。我们一般用Callable编写任务代码，·Future是异步返回对象，通过它的get方法，阻塞式地获取结果·。FutureTask的核心代码就是实现了Future接口，也就是get方法的实现：

public V get() throws InterruptedException, ExecutionException {
    int s = state;
    if (s <= COMPLETING)
        // 核心代码
        s = awaitDone(false, 0L);
    return report(s);
}

private int awaitDone(boolean timed, long nanos)
    throws InterruptedException {
    final long deadline = timed ? System.nanoTime() + nanos : 0L;
    WaitNode q = null;
    boolean queued = false;
    // 死循环
    for (;;) {
        if (Thread.interrupted()) {
            removeWaiter(q);
            throw new InterruptedException();
        }

        int s = state;
        // 只有任务的状态是’已完成‘，才会跳出死循环
        if (s > COMPLETING) {
            if (q != null)
                q.thread = null;
            return s;
        }
        else if (s == COMPLETING) // cannot time out yet
            Thread.yield();
        else if (q == null)
            q = new WaitNode();
        else if (!queued)
            queued = UNSAFE.compareAndSwapObject(this, waitersOffset,
                                                 q.next = waiters, q);
        else if (timed) {
            nanos = deadline - System.nanoTime();
            if (nanos <= 0L) {
                removeWaiter(q);
                return state;
            }
            LockSupport.parkNanos(this, nanos);
        }
        else
            LockSupport.park(this);
    }
}

get的核心实现是有个awaitDone方法，这是一个死循环，只有任务的状态是“已完成”，才会跳出死循环；否则会依赖UNSAFE包下的LockSupport.park原语进行阻塞，等待LockSupport.unpark信号量。而这个信号量只有当运行结束获得结果、或者出现异常的情况下，才会发出来。分别对应方法set和setException。这就是异步执行、阻塞获取的原理，扯得有点远了。

回到最初我们的疑问，为什么submit之后，通过get方法可以获取到异常？原因是FutureTask有一个Object类型的outcome成员变量，用来记录执行结果。这个结果可以是传入的泛型，也可以是Throwable异常：

public void run() {
    if (state != NEW ||
        !UNSAFE.compareAndSwapObject(this, runnerOffset,
                                     null, Thread.currentThread()))
        return;
    try {
        Callable<V> c = callable;
        if (c != null && state == NEW) {
            V result;
            boolean ran;
            try {
                result = c.call();
                ran = true;
            } catch (Throwable ex) {
                result = null;
                ran = false;
                setException(ex);
            }
            if (ran)
                set(result);
        }
    } finally {
        // runner must be non-null until state is settled to
        // prevent concurrent calls to run()
        runner = null;
        // state must be re-read after nulling runner to prevent
        // leaked interrupts
        int s = state;
        if (s >= INTERRUPTING)
            handlePossibleCancellationInterrupt(s);
    }
}

// get方法中依赖的，报告执行结果
private V report(int s) throws ExecutionException {
    Object x = outcome;
    if (s == NORMAL)
        return (V)x;
    if (s >= CANCELLED)
        throw new CancellationException();
    throw new ExecutionException((Throwable)x);
}

FutureTask的另一个巧妙的地方就是借用RunnableAdapter内部类，将submit的Runnable封装成Callable。所以就算你submit的是Runnable，一样可以用get获取到异常。

不论是用execute还是submit，都可以自己在业务代码上加try-catch进行异常处理。

如果是execute，还可以自定义线程池，继承ThreadPoolExecutor并复写其afterExecute(Runnable r, Throwable t)方法。或者实现Thread.UncaughtExceptionHandler接口，实现void uncaughtException(Thread t, Throwable e);方法，并将该handler传递给线程池的ThreadFactory。

但是注意，afterExecute和UncaughtExceptionHandler都不适用submit。因为通过上面的FutureTask.run()不难发现，它自己对Throwable进行了try-catch，封装到了outcome属性，所以底层方法execute的Worker是拿不到异常信息的。

5.8、线程池需不需要关闭?

  一般来讲，线程池的生命周期跟随服务的生命周期。如果一个服务（Service）停止服务了，那么需要调用shutdown方法进行关闭。所以ExecutorService.shutdown在Java以及一些中间件的源码中，是封装在Service的shutdown方法内的。如果是Server端不重启就不停止提供服务，我认为是不需要特殊处理的。

5.9、shutdown和shutdownNow的区别？

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

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

5.10、Spring中有哪些和ThreadPoolExecutor类似的工具？

名称	描述
SimpleAsyncTaskExcutor	每次请求新开线程，没有最大线程数设置，不是真的线程池，这个类不重用线程，每次调用都会新建一个线程
SyncTaskExcutor	不是异步的线程。同步可以用SyncTaskExcutor，但这个不算一个线程池，那位还在原线程执行，这个类没有实现异步调用，只是一个同步操作。
ConcurrentTaskExcutor	Excutor的适配类，不推荐使用，使用ThreadPoolTaskExecutor不满足要求时，才会考虑使用这个类
SimpleThreadPoolTaskExecutor	监听Spring's lifecycle callbacks，并且可以和Quartz的Component兼容，是 Quartz的SimpleThreadPool的类，线程池同时被Qurtz和非Quartz使用，才需要使用此类。

这里我想着重强调的就是SimpleAsyncTaskExecutor，Spring中使用的@Async注解，底层就是基于SimpleAsyncTaskExecutor去执行任务，只不过它不是线程池，而是每次都新开一个线程。

另外想要强调的是Executor接口。Java初学者容易想当然的以为Executor结尾的类就是一个线程池，而上面的都是反例。我们可以在JDK的execute方法上看到这个注释：

所以，它的职责并不是提供一个线程池的接口，而是提供一个“将来执行命令”的接口。真正能代表线程池意义的，是ThreadPoolExecutor类，而不是Executor接口。

6、最佳实践总结

【强制】使用ThreadPoolExecutor的构造函数声明线程池，避免使用Executors类的 newFixedThreadPool和newCachedThreadPool。

【强制】 创建线程或线程池时请指定有意义的线程名称，方便出错时回溯。即threadFactory参数要构造好。

【建议】建议不同类别的业务用不同的线程池。

【建议】CPU密集型任务(N+1)：这种任务消耗的主要是CPU资源，可以将线程数设置为N（CPU核心数）+1，比CPU核心数多出来的一个线程是为了防止线程偶发的缺页中断，或者其它原因导致的任务暂停而带来的影响。一旦任务暂停，CPU就会处于空闲状态，而在这种情况下多出来的一个线程就可以充分利用CPU的空闲时间。

【建议】I/O密集型任务(2N)：这种任务应用起来，系统会用大部分的时间来处理I/O交互，而线程在处理I/O的时间段内不会占用CPU来处理，这时就可以将CPU交出给其它线程使用。因此在I/O密集型任务的应用中，我们可以多配置一些线程，具体的计算方法是2N。

【建议】workQueue不要使用无界队列，尽量使用有界队列。避免大量任务等待，造成OOM。

【建议】如果是资源紧张的应用，使用allowsCoreThreadTimeOut可以提高资源利用率。

【建议】虽然使用线程池有多种异常处理的方式，但在任务代码中，使用try-catch最通用，也能给不同任务的异常处理做精细化。

【建议】对于资源紧张的应用，如果担心线程池资源使用不当，可以利用ThreadPoolExecutor的API实现简单的监控，然后进行分析和优化。

6.1、线程池初始化示例

private static final ThreadPoolExecutor pool;

static {
    ThreadFactory threadFactory = new ThreadFactoryBuilder().setNameFormat("po-detail-pool-%d").build();
    pool = new ThreadPoolExecutor(4, 8, 60L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<>(512),
        threadFactory, new ThreadPoolExecutor.AbortPolicy());
    pool.allowCoreThreadTimeOut(true);
}

threadFactory：给出带业务语义的线程命名。
corePoolSize：快速启动4个线程处理该业务，是足够的。
maximumPoolSize：IO密集型业务，所以4*2=8。
keepAliveTime：服务器资源紧张，让空闲的线程快速释放。
pool.allowCoreThreadTimeOut(true)：也是为了在可以的时候，让线程释放，释放资源。
workQueue：一个任务的执行时长在100~300ms，业务高峰期8个线程，按照10s超时（已经很高了）。10s钟，8个线程，可以处理10 1000ms / 200ms 8 = 400个任务左右，往上再取一点，512已经很多了。
handler：极端情况下，一些任务只能丢弃，保护服务端。

参考文献：

【Java 线程池】Java 创建线程池的正确姿势： Executors 和 ThreadPoolExecutor 详解;

10问10答：你真的了解线程池吗？