坑爹！Quartz 重复调度问题，你遇到过么？

互联网架构师后台回复 2T 有特别礼包

上一篇：“35岁门槛”，公务员招录要率先突破

作者：Lavender
来源：https://segmentfault.com/a/1190000015492260

1. 引子

2. 准备

3）Quartz自带的表里面，本文主要涉及以下3张表：

• triggers表。triggers表里记录了，某个trigger的PREV_FIRE_TIME（上次触发时间），NEXT_FIRE_TIME（下一次触发时间），TRIGGER_STATE（当前状态）。虽未尽述，但是本文用到的只有这些。

• locks表。Quartz支持分布式，也就是会存在多个线程同时抢占相同资源的情况，而Quartz正是依赖这张表，处理这种状况，至于如何做到，参见3.1。

• fired_triggers表，记录正在触发的triggers信息。

4）TRIGGER_STATE，也就是trigger的状态，主要有以下几类：

trigger的初始状态是WAITING，处于WAITING状态的trigger等待被触发。调度线程会不停地扫triggers表，根据NEXT_FIRE_TIME提前拉取即将触发的trigger，如果这个trigger被该调度线程拉取到，它的状态就会变为ACQUIRED。

3. 开始排查

3.1分布式状态下的数据访问

这个方法的官方介绍：

/**

*Execute the given callback having acquired the given lock.

*Depending on the JobStore,the surrounding transaction maybe

*assumed to be already present(managed).

*

*@param lockName The name of the lock to acquire,for example

*"TRIGGER_ACCESS".If null, then no lock is acquired ,but the

*lockCallback is still executed in a transaction.

*/

也就是说，传入的callback方法在执行的过程中是携带了指定的锁，并开启了事务，注释也提到，lockName就是指定的锁的名字，如果lockName是空的，那么callback方法的执行不在锁的保护下，但依然在事务中。

这意味着，我们使用这个方法，不仅可以保证事务，还可以选择保证，callback方法的线程安全。

3.2 quartz的调度过程

1）拉取待触发trigger:

调度线程会一次性拉取距离现在，一定时间窗口内的，一定数量内的，即将触发的trigger信息。那么，时间窗口和数量信息如何确定呢，我们先来看一下，以下几个参数：

• idleWaitTime：默认30s，可通过配置属性org.quartz.scheduler.idleWaitTime设置。
• availThreadCount：获取可用（空闲）的工作线程数量，总会大于1，因为该方法会一直阻塞，直到有工作线程空闲下来。
• maxBatchSize：一次拉取trigger的最大数量，默认是1，可通过org.quartz.scheduler.batchTriggerAcquisitionMaxCount改写
• batchTimeWindow：时间窗口调节参数，默认是0，可通过org.quartz.scheduler.batchTriggerAcquisitionFireAheadTimeWindow改写
• misfireThreshold：超过这个时间还未触发的trigger,被认为发生了misfire,默认60s，可通过org.quartz.jobStore.misfireThreshold设置。

2）触发trigger：

3）包装trigger，丢给工作线程池：

遍历triggers，如果其中某个trigger在第二步出错，即返回值里面有exception或者为null，就会做一些triggers表，fired_triggers表的内容修正，跳过这个trigger，继续检查下一个。否则，则根据trigger信息实例化JobRunShell（实现了Thread接口），同时依据JOB_CLASS_NAME实例化Job，随后我们将JobRunShell实例丢入工作线。

另外，关注公众号互联网架构师，在后台回复：面试，可以获取我整理的 Java 多线程系列教程，非常齐全。

3.3 排查问题

在前文，我们可以看到，Quartz的调度过程中有3次（可选的）上锁行为，为什么称为可选？因为这三个步骤虽然在executeInNonManagedTXLock方法的保护下，但executeInNonManagedTXLock方法可以通过设置传入参数lockName为空，取消上锁。在翻阅代码时，我们看到第一步拉取待触发的trigger时：

public List<OperableTrigger> acquireNextTriggers(final long noLaterThan, final int maxCount, final long timeWindow)throws JobPersistenceException {
    String lockName;
    //判断是否需要上锁
    if (isAcquireTriggersWithinLock() || maxCount > 1) {
        lockName = LOCK_TRIGGER_ACCESS;
    } else {
        lockName = null;
    }
    return executeInNonManagedTXLock(lockName,
                                     new TransactionCallback<List<OperableTrigger>>(){
        public List<OperableTrigger> execute(Connection conn) throws JobPersistenceException {
            return acquireNextTrigger(conn, noLaterThan, maxCount, timeWindow);
        }
    }, new TransactionValidator<List<OperableTrigger>>() {
         //省略
    });
}

在加锁之前对lockName做了一次判断，而非像其他加锁方法一样，默认传入的就是LOCK_TRIGGER_ACCESS：

public List<TriggerFiredResult> triggersFired(final List<OperableTrigger> triggers) throws JobPersistenceException {
    //默认上锁
    return executeInNonManagedTXLock(LOCK_TRIGGER_ACCESS,
        new TransactionCallback<List<TriggerFiredResult>>() {
        //省略
        },new TransactionValidator<List<TriggerFiredResult>>() {
            //省略
           });
}

通过调试发现isAcquireTriggersWithinLock()的值是false，因而导致传入的lockName是null。我在代码中加入日志，可以更清楚的看到这个过程。

由图3-5可以清楚看到，在拉取待触发的trigger时，默认是不上锁。如果这种默认配置有问题，岂不是会频繁发生重复调度的问题？而事实上并没有，原因在于Quartz默认采取乐观锁，也就是允许多个线程同时拉取同一个trigger。我们看一下Quartz在调度流程的第二步fire trigger的时候做了什么，注意此时是上锁状态：

protected TriggerFiredBundle triggerFired(Connection conn, OperableTrigger trigger)
    throws JobPersistenceException {
    JobDetail job;
    Calendar cal = null;
    // Make sure trigger wasn't deleted, paused, or completed...
    try { // if trigger was deleted, state will be STATE_DELETED
        String state = getDelegate().selectTriggerState(conn,trigger.getKey());
         if (!state.equals(STATE_ACQUIRED)) {
            return null;
        }
    } catch (SQLException e) {
            throw new JobPersistenceException("Couldn't select trigger state: "
                    + e.getMessage(), e);
    }

调度线程如果发现当前trigger的状态不是ACQUIRED，也就是说，这个trigger被其他线程fire了，就会返回null。在3.2，我们提到，在调度流程的第三步，如果发现某个trigger第二步的返回值是null，就会跳过第三步，取消fire。在通常的情况下，乐观锁能保证不发生重复调度，但是难免发生ABA问题，我们看一下这是发生重复调度时的日志：

3.4 解决办法

如何去解决这个问题呢？在配置文件加上org.quartz.jobStore.acquireTriggersWithinLock=true，这样，在调度流程的第一步，也就是拉取待即将触发的triggers时，是上锁的状态，即不会同时存在多个线程拉取到相同的trigger的情况，也就避免的重复调度的危险。

3.5 心得

此次排查过程并非一帆风顺，走过一些坑，也有一些非技术相关的体会：

1）学习是一个需要不断打磨，修正的能力。就我个人而言，为了学Quartz，刚开始去翻一个2.4MB大小的源码是毫无头绪，并且效率低下的，所以立刻转换方向，先了解这个框架的运行模式，在做什么，有哪些模块，是怎么做的，再找主线，翻相关的源码。之后在一次次使用中，碰到问题再翻之前没看的源码，就越来越顺利。

之前也听过其他同事的学习方法，感觉并不完全适合自己，可能每个人状态经验不同，学习方法也稍有不同。在平时的学习中，需要去感受自己的学习效率，参考建议，尝试，感受效果，改进，会越来越清晰自己适合什么。这里很感谢我的师父，用简短的话先帮我捋顺了调度流程，这样我再看源码就不那么吃力了。

2）要质疑“经验”和“理所应当”，惯性思维会蒙住你的双眼。在大规模的代码中很容易被习惯迷惑，一开始，我们看到上锁的那个方法的时候，认为这个上锁技巧很棒，这个方法就是为了解决并发的问题，“应该”都上锁了，上锁了就不会有并发的问题了，怎么可能几次与数据库的交互都上锁，突然某一次不上锁呢？直到看到拉取待触发的trigger方法时，觉得有丝丝不对劲，打下日志，才发现实际上是没上锁的。

3）日志很重要。虽然我们可以调试，但是没有日志，我们是无法发现并证明，程序发生了ABA问题。

4）最重要的是，不要害怕问题，即使是Quartz这样大型的框架，解决问题也不一定需要把2.4MB的源码通通读懂。只要有时间，问题都能解决，只是好的技巧能缩短这个时间，而我们需要在一次次实战中磨练技巧。