本文源码阅读的主角是JobTriggerPoolHelper，作业触发线程池助手，通过阅读此部分源码，我们可以学习到：
- 线程池隔离技术
- 多线程知识
快慢线程池
在JobTriggerPoolHelper类中，有这么两个变量，定义了两个线程池
// fast/slow thread pool
private ThreadPoolExecutor fastTriggerPool = null;
private ThreadPoolExecutor slowTriggerPool = null;
复制代码两个线程池在启动的时候会被初始化
public void start() {
fastTriggerPool = new ThreadPoolExecutor(
10,
XxlJobAdminConfig.getAdminConfig().getTriggerPoolFastMax(), // 最大线程数，最小为200
60L,
TimeUnit.SECONDS,
new LinkedBlockingQueue<>(1000), // 队列数1000
r -> new Thread(r, "xxl-job, admin JobTriggerPoolHelper-fastTriggerPool-" + r.hashCode()));
slowTriggerPool = new ThreadPoolExecutor(
10,
XxlJobAdminConfig.getAdminConfig().getTriggerPoolSlowMax(), // 最大线程数，最小为100
60L,
TimeUnit.SECONDS,
new LinkedBlockingQueue<>(2000), // 队列数2000
r -> new Thread(r, "xxl-job, admin JobTriggerPoolHelper-slowTriggerPool-" + r.hashCode()));
}
复制代码通过源码，我们发现，快慢线程池除了最大线程数和队列数不一致外，其他是相同的，这一开始让我很困惑，难道修改最大线程数和任务队列数，可以让线程跑的更快吗？
查阅其他资料后，恍然大悟，还是功力不够。
实际上不是线程池本身的快慢，而是线程池里面的任务执行有快慢一说，只有执行快的，才有资格加入fastTriggerPool，执行慢的就只能被打入slowTriggerPool。
总的来讲，使用线程池隔离技术，将快任务和慢任务分开执行，可以避免某些任务执行过慢，从而拖累原本执行快的任务，优化整体的任务执行性能。
这一招在Hystrix里面似乎见过。
慢任务的定义
既然要将慢任务打入冷宫，那么我们怎么定义这个任务执行的慢呢？
XXL-Job是这么定义的：任务执行时间大于500ms，那么认为是慢任务（超时），此时记为一次；如果1分钟内超时次数大于10次，就会被打入冷宫。
具体做法：
- 定义变量
minTim，记录当前任务执行结束时间和60000（1分钟的毫秒值）的比值
private volatile long minTim = System.currentTimeMillis() / 60000; // ms > min
复制代码- 定义变量
jobTimeoutCountMap，记录每个任务的执行超时次数，该变量间隔大于等于1分钟会重置
// 此map用来记录任务超时次数，不过实际上并不是超时，只是执行时间大于500ms，应该叫做执行慢的次数才对
private volatile ConcurrentMap<Integer, AtomicInteger> jobTimeoutCountMap = new ConcurrentHashMap<>();
// check timeout-count-map
long minTim_now = System.currentTimeMillis() / 60000;
// 当前时间戳和60000相除的结果，如果和既定变量不一致，那么肯定已经过去1分钟甚至更久，那么清空jobTimeoutCountMap
if (minTim != minTim_now) {
minTim = minTim_now;
jobTimeoutCountMap.clear();
}
复制代码- 在每次任务执行结束后，判断任务执行时长是否大于500ms，如果是，那么记为超时一次
// incr timeout-count-map
long cost = System.currentTimeMillis() - start;
// 如果任务执行时间大于500ms，那么记为超时一次
if (cost > 500) { // ob-timeout threshold 500ms
AtomicInteger timeoutCount = jobTimeoutCountMap.putIfAbsent(jobId, new AtomicInteger(1));
if (timeoutCount != null) {
timeoutCount.incrementAndGet();
}
}
复制代码- 在每次任务调度前，选择合适的线程池来执行
// choose thread pool
ThreadPoolExecutor triggerPool_ = fastTriggerPool;
AtomicInteger jobTimeoutCount = jobTimeoutCountMap.get(jobId);
// 作业-1分钟内超时10次，将会使用慢线程池来执行
if (jobTimeoutCount != null && jobTimeoutCount.get() > 10) { // job-timeout 10 times in 1 min
triggerPool_ = slowTriggerPool;
}
复制代码看到这里，感觉这个慢任务线程池我司似乎用不上，因为定时任务都是批处理任务，耗时都挺长的，永远也达不成1分钟内超时10次的硬指标，因为任务本身耗时就大于1分钟。
其他多线程知识
volatile的使用
开始前，先复习下volatile的语义：所有线程都能看到共享内存的最新状态。也就是说，线程总是能拿到该变量最新的值。
minTim和jobTimeoutCountMap都使用了volatile进行修饰。
这里要注意一下，任务调度的部分，是无锁并发，没有使用任何锁。
// trigger
triggerPool_.execute(() -> {
long start = System.currentTimeMillis();
try {
// do trigger
XxlJobTrigger.trigger(jobId, triggerType, failRetryCount, executorShardingParam, executorParam, addressList);
} catch (Exception e) {
LOGGER.error(e.getMessage(), e);
} finally {
// check timeout-count-map
...
// incr timeout-count-map
...
}
});
复制代码minTim好理解，因为要和当前计算的值进行比较，所以使用volatile，取最新值进行比较就行。
但是jobTimeoutCountMap的用法存疑，因为本身类型就是ConcurrentMap，读写是原子性的，而且volatile修饰的是容器类，实际上容器类我们可以使用final来修饰更好一点，因为容器本身不需要改变，改变的只是其中的元素而已。
结合Do we need to make ConcurrentHashMap volatile?，我感觉这边应该使用final修饰更好一点，有没有懂哥赐教下的，欢迎评论留言。
线程池初始化
我们来看一下快线程池的初始化
fastTriggerPool = new ThreadPoolExecutor(
10,
XxlJobAdminConfig.getAdminConfig().getTriggerPoolFastMax(), // 最大线程数，最小为200
60L,
TimeUnit.SECONDS,
new LinkedBlockingQueue<>(1000), // 队列数1000
r -> new Thread(r, "xxl-job, admin JobTriggerPoolHelper-fastTriggerPool-" + r.hashCode()));
复制代码- 核心线程数：10
- 最大线程数：可配置，如果配置数小于200，那么设置为200，意味着最小是200
- 线程空闲时间：60秒
- 任务队列：容量为1000的有界阻塞队列
- 线程工厂：定义了下线程名称
回顾一下线程池的知识，什么情况下会到达最大线程数呢？
答：当添加一个任务时，核心线程数已满，线程池还没达到最大线程数，并且没有空闲线程，工作队列已满的情况下，创建一个新线程并执行。
也就是说，10个任务在运行，1000个任务待运行，然后此时添加任务，就会创建线程，并且短时间内疯狂的调度200个任务，才能到达最大线程数。
此时应该是极端情况了，一般是不会积压这么多待运行任务的。
算是巩固了下对线程池的理解，在实际业务场景遇到也可作为参考。