线程池简单整理（一）

线程池简单梳理

ThreadPoolExecutor的成员变量AtomicInteger ctl

• 高3位：线程池的状态
  – RUNNING：一切正常
  – SHUTDOWN：已接的活都能干，不接新活
  – STOP：什么活都不干了
  – TIDYING：线程池准备倒闭
  – TERMINATED：线程池倒闭了
• 低29位：工作线程的数量。刚创建的线程池没有线程，线程池是运行状态。（工作线程，就是线程池中new的Thread，然后start起来的线程）

线程池7个参数：

• 核心线程
• 最大线程数
• 最大空闲时间
• 空闲时间单位
• 阻塞队列
• 线程工厂
• 拒绝策略

构建好的线程池内部，有多少个线程？

0个，工作线程都是懒加载，随着任务提交才会被创建

线程池的执行流程

• 工作线程数 < 核心线程数：直接构建核心线程来处理当前任务，不管是否存在核心线程正在空闲状态
• 工作线程数 >= 核心线程数：将任务放到阻塞队列中，空闲的线程会到阻塞队列来获取任务进行处理
• 阻塞队列已满：创建非核心线程来处理刚刚提交的任务，等任务处理完，才会去阻塞队列取任务处理
• 工作线程数>=最大线程数 且 阻塞队列已满：执行拒绝策略

特殊情况：任务被丢到阻塞队列，但是没有工作线程的情况，此时会构建一个非核心线程去处理阻塞队列中的任务，避免任务长时间在阻塞队列中等待不能被处理（核心线程数可以为0，最大线程数不能为0）

核心线程和非核心线程的区别：

没有区别
线程池构建线程，也是基于Thread t = new Thread() 去构建，虽然在构建前，有一些判断上的不同，但是构建出来的都是线程，不分核心还是非核心。
线程池最终只确保数量满足参数要求即可。无论线程创建之初被认为是核心还是非核心，到后面都是工作线程，而且线程池在维护一个工作线程的属性，增加复杂性，而且对效率有影响，所以线程没有区别。

线程池中的工作线程，在处理网手头的任务之后，都会去阻塞多列中常识那新任务，在尝试的过程中，工作线程都处于阻塞状态。

尝试的时间略有不同：

• 有的工作线程会死等，没任务，我就死等，等到有任务（核心线程。没有超过和线程数时，都是死等）WAITING，take方法
• 有的工作线程会等待最大空闲时间，这段时间没拿到任务，这个线程就销毁。（非核心线程，超过核心线程数之后，都是等一会） TIMED_WAITING，poll(最大空闲时间)方法

工作线程没拿到任务就销毁：
无论是线程池中的线程还是new Thread，都是同一种线程，都是start起来的。
销毁方式很简单，run方法结束即可
线城市也是一样的操作，让fun方法结束即可，而结束的方式，是让runWorker方法里的while循环结束。（工作线程可以一直干活的原因就是在一个while循环中不停的去阻塞队列获取任务）

• 当没有从阻塞队列在指定的时间范围内，拿到数据，线程就会销毁。（非核心线程）
• 等待任务的线程装特爱们出于WAITING或者TIMED_WAITING，只要线程在这个状态下中断了，就会被立即唤醒，没有拿到任务没这种也会被销毁

原理都是一样的，都在阻塞队列中尝试获取任务，但是最后没拿到，就要被干掉，干掉的方式，就是run方法结束，线程销毁。

线程回收

当在方法内构建一个线程池去处理任务后，几遍方法弹栈了，线程池引用没有了，工作线程一眼无法被正常回收，严重会导致OOM问题。
在方法内部使用线程池完毕后，一定要基于执行shutdown方法，先让线程池将工作线程回收，否则存活的线程会让线程池对象无法被GC回收。
线程池构建的线程，属于GCRoot的一种。
同时工作线程的run方法的参数里传入了Worker对象（Worker属于Thread线程的包装），Worker无法被回收。
Worker是线程池的内部类，内部类还在，外部类无法被回收。

线程池核心参数如何设置：

核心线程数：

• 任务类型是CPU密集还是IO密集
  – CPU密集：线程需要CPU尽可能调度，核心线程数一般要设置到CPU内核数±1，减少上下文切换，尽可能压榨CPU能力
  – IO密集：核心线程数设置的共识跟实际情况是有出入的，IO密集的时间不确定，这里一定要基于压测，找到一个合适的中间值，在短时间内可以按照任务的RT时间以及任务数来决定核心线程数大小

阻塞队列

• 考虑任务处理允许的延迟时间，基于每秒任务大致多少的数量，来预测队列最长时，任务会延迟多久
• JVM内存问题，如果大量的任务扔到阻塞队列中，占用的内存尽量不要太多

最大线程数：

• 建议推荐和核心线程数的大小设置为一样。如果设置太大，反而会造成线程池处理任务的效率低（CPU频繁上下文切换，导致浪费CPU资源，这个完全没必要）。

拒绝策略

• 贴近业务去聊，比如日志，丢就丢了，采用抛弃策略、discard都可以
• 如果任务要求必须完成，设置为CallerRuns都可以接收
• 或者abort抛出异常，日志记录信息，知道线程池处理能力不足
• 任务允许延迟，但是有不能影响当前效率，可以记录信息写入数据库（或队列），后面定时、消息处理