线程池（ThreadPoolExecutor）
一：Executor知识点
线程池知识点.png
二：线程池模型
1：线程池模型：生产者-消费者模式（与一般的池化资源模式不同），线程池的使用方法是生产者，线程池本身是消费者。
问题1：为什么认为"线程池的使用方法是生产者，线程池本身是消费者"呢？
因此线程池内部维护了队列，线程池的方法提交一个任务就是将其加入到队列中，对应的就是生产者，然后线程池从队列中获取任务执行来消费任务，对应的就是消费者。
三：线程池原理
线程池原理.png
1：执行原理
线程池中的核心线程数，当提交一个任务时，线程池创建一个新线程执行任务，直到当前线程数等于corePoolSize；如果当前线程数为corePoolSize，继续提交的任务被保存到阻塞队列中，等待被执行；如果阻塞队列满了，那就创建新的线程执行当前任务；直到线程池中的线程数达到maxPoolSize,这时再有任务来，只能执行RejectedExecutionHandler处理该任务。
2：核心参数
- corePollSize：核心线程数。在创建了线程池后，线程中没有任何线程，等到有任务到来时才创建线程去执行任务。默认情况下，在创建了线程池后，线程池中的线程数为0，当有任务来之后，就会创建一个线程去执行任务，当线程池中的线程数目达到corePoolSize后，就会把到达的任务放到阻塞队列当中。
- maximumPoolSize：最大线程数。表明线程中最多能够创建的线程数量。
- keepAliveTime：空闲的线程保留的时间，超过该时间线程会被回收<font color='red'>（指非核心线程=maximumPoolSize-corePollSize，核心线程不会被回收）</font>。
注：JDK从1.6开始，提供 allowCoreThreadTimeOut(boolean value) 允许空闲核心线程超时释放，节省资源。 - TimeUnit：空闲线程的保留时间单位。
- BlockingQueue<Runnable>：阻塞队列，存储等待执行的任务。参数有ArrayBlockingQueue、LinkedBlockingQueue、SynchronousQueue可选。
- ThreadFactory：线程工厂，用来创建线程。
- RejectedExecutionHandler：（拒绝策略）创建的线程数量大于线程池的最大线程数的时候，新的任务就会被拒绝，就会调用拒绝策略。
AbortPolicy：中止政策。默认的拒绝策略就是AbortPolicy。抛弃添加的任务，直接抛出异常。
CallerRunsPolicy：调用者运行政策。在任务被拒绝添加后，会调用当前线程池的所在的线程去执行被拒绝的任务。
DiscardPolicy：丢弃政策。会让被线程池拒绝的任务直接抛弃，不会抛异常也不会执行。
DiscardOldestPolicy：丢失最老的政策。任务被拒绝添加时，会抛弃任务队列中最旧的任务也就是最先加入队列的，再把这个新任务添加进去。
四：线程池核心API
- submit：提交任务，返回类型是void，定义在Executor接口中。
- execute：提交任务，返回持有计算结果的Future对象，定义在ExecutorService接口中，扩展了Executor接口。
- shutdown：不会立即终止线程池，而是要等所有任务缓存队列中的任务都执行完后才终止，但再也不会接受新的任务。
- shutdownNow：立即终止线程池，并尝试打断正在执行的任务，并且清空任务缓存队列，返回尚未执行的任务。
五：线程池的作用
资源的利用性增加。
-
减少创建和销毁线程的次数，每个工作线程都可以被重复利用，可执行多个任务。
-
可以根据系统的承受能力，调整线程池中工作线程的数量，防止因为消耗过多的内存，而宕机。
六：线程池的巧妙设计
1：AtomicInteger变量设计
在线程池中，使用了一个原子类AtomicInteger的变量来表示线程池状态和线程数量，该变量在内存中会占用4个字节，也就是32bit，其中高3位用来表示线程池的状态，低29位用来表示线程的数量。线程池的状态一共有5中状态，用3bit最多可以表示8种状态，因此采用高3位来表示线程池的状态完全能满足需求。
注：用1个变量来保存2个变量状态，非常的巧妙，2个变量之间自身的耦合关系也非常好处理。
七：Executors
- newFixedThreadPool：固定线程池，核心线程数和最大线程数一样， 维护LinkedBlockingQuene，即使当线程池没有可执行任务时，也不会释放线程。（一般多用这个）。
- newCachedThreadPool：缓存线程池，核心线程数默认为0，最大线程数默认为Integer.MAX_VALUE，维护SynchronousQueue。
- newSingleThreadExecutor：单一线程池，核心线程数和最大线程数为1，维护LinkedBlockingQuene。
- newScheduledThreadPool：定时线程池，核心线程数默认为用户传递，最大线程数默认为Integer.MAX_VALUE，维护了一个基于BlockingQueue实现的DelayedWorkQueue队列。
- ......
《阿里巴巴Java开发规范》建议：不要使用Executors来创建线程池。
原因：Executors提供的四种线程池创建策略容易造成OOM。
1：FixedThreadPool 和 SingleThreadPool：允许LinkedBlockingQueue的请求队列长度为 Integer.MAX_VALUE，可能会堆积大量的请求，从而导致 OOM。
2：CachedThreadPool 和 ScheduledThreadPool：允许的创建线程数量为 Integer.MAX_VALUE，可能会创建大量的线程，从而导致 OOM。
八：合理的设置线程池
1：理论设置
线程池的理论设置需要依据程序是CPU密集型任务还是IO密集型任务来进行设置。
CPU密集型任务：特点是要进行大量的计算，消耗CPU资源，比如计算圆周率、对视频进行高清解码等等，全靠CPU的运算能力。
IO密集型任务：涉及到网络、磁盘IO的任务都是IO密集型任务，这类任务的特点是CPU消耗很少，任务的大部分时间都在等待IO操作完成（因为IO的速度远远低于CPU和内存的速度）。因此CPU会在进行IO的时候处于空闲。
-
如果是CPU密集型任务（就是需要CPU进行大量计算的），就需要尽量压榨CPU，参考值可以设为 Num(CPU+1) 。
注：多出来的一个线程是为了防止线程偶发的缺页中断，或者其它原因导致的任务暂停而带来的影响。
-
如果是IO密集型任务（IO比较多），参考值可以设置为 2 * CPU核数。
2：生产环境设置
生产环境设置需要在压测的基础上进行设置。
八：实际项目经验
1：项目中自定义线程池中线程名字
/**
* JDK构造线程池
*
* @return
*/
public Executor constructExecutor() {
return new ThreadPoolExecutor(1, 2, 1, TimeUnit.MINUTES, new LinkedBlockingQueue<>(10),
new ThreadFactory() {
private AtomicInteger tag = new AtomicInteger(0);
@Override
public Thread newThread(Runnable runnable) {
Thread thread = new Thread(runnable);
thread.setName("线程name-" + tag.getAndIncrement());
return thread;
}
}, new ThreadPoolExecutor.AbortPolicy());
}
/**
* Spring Boot Bean构造异步线程池
*/
@Bean
public AsyncTaskExecutor asyncTaskExecutor() {
ThreadPoolTaskExecutor asyncTaskExecutor = new ThreadPoolTaskExecutor();
asyncTaskExecutor.setCorePoolSize(1);
asyncTaskExecutor.setMaxPoolSize(1);
asyncTaskExecutor.setThreadNamePrefix("线程名");
return asyncTaskExecutor;
}
2：项目中如何定义线程池
一个项目中如果多个业务需要用到线程池，是定义一个公共的线程池比较好，还是按照业务定义各自不同的线程池？如果定义一个公共的线程池那里面的线程数的理论值应该是按照老师前面章节讲的去计算吗？还是按照如果有多少个业务就分别去计算他们各自创建线程池线程数的加和?如果不同的业务各自定义不同的线程池，那线程数的理论值也是按照前面的去计算吗？
极客时间上建议：建议不同类别的业务用不同的线程池，至于线程池的数量，各自计算各自的，然后去做压测（APM做压测）。虽然你的系统有多个线程池，但是并不是所有的线程池里的线程都是忙碌的，你只需要针对有性能瓶颈的业务优化就可以了。
3：线程池监控和动态修改
项目中使用线程池时，线程池的参数主要是核心线程数和最大线程数的设置需要通过压测来选取最适合业务类型的参数，因此会有线上环境动态修改线程池的需求。线上的运行环境需要监控线程池的参数来了解线程池的的运行状态。
代码示例参考：threadpool-monitor
