Quartz框架多个trigger任务执行出现漏执行的问题分析--转

原文地址：http://blog.csdn.net/dailywater/article/details/51470779

一、问题描述 
使用Quartz配置定时任务，配置了超过10个定时任务，这些定时任务配置的触发时间都是5分钟执行一次，实际运行时，发现总有几个定时任务不能执行到。

二、示例程序 
1、简单介绍 
采用spring+quartz整合方案实现定时任务，Quartz的SchedulerFactoryBean配置参数中不注入taskExecutor属性，使用默认自带的线程池。准备了15个定时任务，全部设置为每隔10秒触发一次，定时任务的实现逻辑是使用休眠8秒的方式模拟执行定时任务的时间耗费。

2、配置文件信息如下（节选）：

<bean id="startQuertz" lazy-init="false" autowire="no" class="org.springframework.scheduling.quartz.SchedulerFactoryBean">
        <property name="triggers">
            <list>
                <ref bean="testMethod1Trigger"/>
                <ref bean="testMethod2Trigger"/>
                // 以下省略13个 触发器的配置
           </list>
        </property>
    </bean>

    <bean id="testMethod1Trigger"  class="org.springframework.scheduling.quartz.CronTriggerFactoryBean">
        <property name="jobDetail" ref="testMethod1" />
        <!-- 指定Cron表达式：每10秒触发一次 --> 
        <property name="cronExpression"  value="0/10 * * * * ?"/>
    </bean>
    <bean id="testMethod1" class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean">
        <property name="targetObject" ref="triggerService" /> 
        <!-- 要执行的方法名称 -->
        <property name="targetMethod" value="method1" />
    </bean>
     // 以下省略14个定时任务的配置

3、Java定时任务类程序如下（节选）

@Service("triggerService")
public class TriggerService {

    private int cnt1;


    public void method1() {
        try {
            Thread.sleep(8000);
        } catch (InterruptedException e) {
        }
        cnt1++;
    }

    public void print() {
        StringBuffer sb = new StringBuffer();
        sb.append("\nmethod1:" + cnt1);
        sb.append("\nmethod2:" + cnt2);
        sb.append("\nmethod3:" + cnt3);
        sb.append("\nmethod4:" + cnt4);
        sb.append("\nmethod5:" + cnt5);
        sb.append("\nmethod6:" + cnt6);
        sb.append("\nmethod7:" + cnt7);
        sb.append("\nmethod8:" + cnt8);
        sb.append("\nmethod9:" + cnt9);
        sb.append("\nmethod10:" + cnt10);
        sb.append("\nmethod11:" + cnt11);
        sb.append("\nmethod12:" + cnt12);
        sb.append("\nmethod13:" + cnt13);
        sb.append("\nmethod14:" + cnt14);
        sb.append("\nmethod15:" + cnt15);
        System.out.println(sb.toString());
    }
}

实现逻辑很简单，总共定义15个方法，方法内休眠6秒，同时每个方法都使用一个成员变量记录被调用的次数，并在该类的print()方法里统一输出所有方法调用次数的概况。

4、client启动程序如下：

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = "classpath:applicationContext.xml")
public class TriggerServiceTest extends TestCase {

    @Autowired
    private TriggerService triggerService;

    @Test
    public void testService() {
        try {
            while (true) {
                Thread.sleep(11000);
                triggerService.print();
            }
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }
}

一个简单的单元测试用例，每隔11秒调用一次定时任务服务类的print()方法，输出定时任务调用次数的统计值。

5、运行结果 
我们让这个demo程序跑了几分钟，控制台输出的取样结果如下：

method1:25
method2:25
method3:25
method4:25
method5:12
method6:12
method7:12
method8:12
method9:12
method10:25
method11:25
method12:25
method13:25
method14:25
method15:25

6、结果分析 
此次采样的数据结果表示：15个任务中，有10个执行了25次，另外5个只执行了12次，执行的次数不一样，说明在定时任务调度过程中，有的任务会被遗漏不执行，目前的实验结果能够重现上文描述的问题。

三、源码分析 
刚开始我们对此也是感觉到很疑惑，因为任务被漏执行时，没有任何警告或报错的日志信息，这个问题若在实际生产中出现了，很难查明原因。 
我们来看一下相关的源码实现，希望能在源码中发现一些有价值的信息： 
1）SchedulerFactoryBean类的初始化操作 
其中关于线程池属性注入的相关代码如下（省略了部分代码）：

/**
 * Load and/or apply Quartz properties to the given SchedulerFactory.
 * @param schedulerFactory the SchedulerFactory to initialize
 */
private void initSchedulerFactory(SchedulerFactory schedulerFactory) throws SchedulerException, IOException {
    if (!(schedulerFactory instanceof StdSchedulerFactory)) {
        if (this.configLocation != null || this.quartzProperties != null ||
                this.taskExecutor != null || this.dataSource != null) {
            throw new IllegalArgumentException(
                    "StdSchedulerFactory required for applying Quartz properties: " + schedulerFactory);
        }
        // Otherwise assume that no initialization is necessary...
        return;
    }

    // 省略其他代码...

    // 此为需要关注的代码
    if (this.taskExecutor != null) {
        mergedProps.setProperty(StdSchedulerFactory.PROP_THREAD_POOL_CLASS,
                LocalTaskExecutorThreadPool.class.getName());
    }
    else {
        // Set necessary default properties here, as Quartz will not apply
        // its default configuration when explicitly given properties.
        mergedProps.setProperty(StdSchedulerFactory.PROP_THREAD_POOL_CLASS, SimpleThreadPool.class.getName());
        mergedProps.setProperty(PROP_THREAD_COUNT, Integer.toString(DEFAULT_THREAD_COUNT));
    }

    // 省略其他代码...
}

此代码的逻辑是，如果taskExecutor属性有注入值，就使用指定的线程池，一般Spring是会配置线程池的，线程池的参数可以自行指定。如果taskExecutor未注入值，就使用org.quartz.simple.SimpleThreadPool线程池，DEFAULT_THREAD_COUNT的值为10，即该线程池的大小为10。 
我们现在演示的场景是未设置taskExecutor的，所以线程池是SimpleThreadPool的实例对象，池的大小为10。

2）运行过程中，定时任务的触发过程 
首先，要从线程池获取可用资源，该实现在org.quartz.core.QuartzSchedulerThread线程类的run方法中，如代码所示：

int availThreadCount = qsRsrcs.getThreadPool().blockForAvailableThreads();

//这个方法的实现在SimpleThreadPool类里
    public int blockForAvailableThreads() {
        synchronized(nextRunnableLock) {

            while((availWorkers.size() < 1 || handoffPending) && !isShutdown) {
                try {
                    nextRunnableLock.wait(500);
                } catch (InterruptedException ignore) {
                }
            }

            return availWorkers.size();
        }
    }

注意这个获取线程池资源的方法是阻塞式的，若线程池资源不够用，会一直等待直至获取到可用的资源。这里是产生等待的原因。

然后我们看一下定时任务允许被触发的条件，实现的源码还是在 
org.quartz.core.QuartzSchedulerThread线程类的run方法中：

try {
    triggers = qsRsrcs.getJobStore().acquireNextTriggers(
            now + idleWaitTime, Math.min(availThreadCount, qsRsrcs.getMaxBatchSize()), qsRsrcs.getBatchTimeWindow());
    lastAcquireFailed = false;
    if (log.isDebugEnabled())
        log.debug("batch acquisition of " + (triggers == null ? 0 : triggers.size()) + " triggers");
} catch (JobPersistenceException jpe) {
    if(!lastAcquireFailed) {
        qs.notifySchedulerListenersError(
            "An error occurred while scanning for the next triggers to fire.",jpe);
    }
    lastAcquireFailed = true;
    continue;
} catch (RuntimeException e) {
    if(!lastAcquireFailed) {
        getLog().error("quartzSchedulerThreadLoop: RuntimeException "
                +e.getMessage(), e);
    }
    lastAcquireFailed = true;
    continue;
}

最关键的是acquireNextTriggers方法，这个方法是获取所有可用的触发器，定位到org.quartz.simpl.RAMJobStore实现类中，代码如下：

/**
 * <p>
 * Get a handle to the next trigger to be fired, and mark it as 'reserved'
 * by the calling scheduler.
 * </p>
 *
 * @see #releaseAcquiredTrigger(OperableTrigger)
 */
public List<OperableTrigger> acquireNextTriggers(long noLaterThan, int maxCount, long timeWindow) {
    synchronized (lock) {
        List<OperableTrigger> result = new ArrayList<OperableTrigger>();
        Set<JobKey> acquiredJobKeysForNoConcurrentExec = new HashSet<JobKey>();
        Set<TriggerWrapper> excludedTriggers = new HashSet<TriggerWrapper>();
        long firstAcquiredTriggerFireTime = 0;

        // return empty list if store has no triggers.
        if (timeTriggers.size() == 0)
            return result;

        while (true) {
            TriggerWrapper tw;

            try {
                tw = timeTriggers.first();
                if (tw == null)
                    break;
                timeTriggers.remove(tw);
            } catch (java.util.NoSuchElementException nsee) {
                break;
            }

            if (tw.trigger.getNextFireTime() == null) {
                continue;
            }

            if (applyMisfire(tw)) {
                if (tw.trigger.getNextFireTime() != null) {
                    timeTriggers.add(tw);
                }
                continue;
            }

            if (tw.getTrigger().getNextFireTime().getTime() > noLaterThan + timeWindow) {
                timeTriggers.add(tw);
                break;
            }

            // 省略部分代码...

            if (result.size() == maxCount)
                break;
        }

        // If we did excluded triggers to prevent ACQUIRE state due to DisallowConcurrentExecution, we need to add them back to store.
        if (excludedTriggers.size() > 0)
            timeTriggers.addAll(excludedTriggers);
        return result;
    }
}

请注意一下while循环内调用的applyMisfire方法，实现如下：

protected boolean applyMisfire(TriggerWrapper tw) {

    long misfireTime = System.currentTimeMillis();
    if (getMisfireThreshold() > 0) {
        misfireTime -= getMisfireThreshold();
    }

    Date tnft = tw.trigger.getNextFireTime();
    if (tnft == null || tnft.getTime() > misfireTime
            || tw.trigger.getMisfireInstruction() == Trigger.MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY) {
        return false;
    }

    // 省略其他代码...

    return true;
}

以上源码为了节省篇幅有部分省略，有兴趣的可以自行阅读完整代码。

注意一下这里返回为false的判断逻辑，这个方法返回为false，表示acquireNextTriggers将不再接收这个定时任务，并且没有任何信息输出，这样该定时任务在触发过程中就被忽略不执行了。

顺便留意一下misfireTime，它取当前的时间点，另外减小了5秒钟（减小的时间参数可以设置，默认是5秒），如果我们把tnft.getTime()理解为定时任务预先设定的执行时间，那么”nextFireTime + misfireThreshold”我们可以理解为任务执行的过期时间，misfireTime这个变量是用来跟nextFireTime比较的参数，如果nextFireTime大于misfireTime，即任务当前执行的时间点大于过期时间”nextFireTime + misfireThreshold”，表示任务已经超过了等待的限度，那么这个任务就不再被执行了。 
简单地说，就是一个定时任务经过获取可用的线程池资源，到执行这段逻辑的时间，如果5秒内无法完成的话， 这个任务就不再执行了。

回想我们的演示案例，定时任务是超过了10个，就肯定存在线程池资源获取等待的问题，而每个定时任务的方法是休眠6秒钟，又超过了5秒的限度，所以每次调度时，总有一些任务是被略过了的。

四、解决方案 
经过以上分析，我们已经了解到出现些问题的原因，解决方案有两种： 
1、注入taskExecutor属性，保证线程池资源是够用的。 
2、各个定时任务错峰触发。 
演示案例的定时任务触发时间均为10秒一次，错峰时间配置可以参照素数原理，减小冲突可能性，比如配置时间为5分钟，7分钟，11分钟，13分钟，17分钟等，这样高峰相遇的概率会低一些。 
以上两个方案可根据实际情况挑选，也可以组合使用。

五、总结 
1、经过阅读源码分析，可以了解到两个关键点：线程池资源获取等待定时任务过期作废机制。 
2、Quartz框架的定时任务执行是绝对时间触发的，所以存在“过期不候”的现象。 
3、在使用Quartzs框架时，一定要预先计算好triggers数量与线程池大小的匹配程度，资源一定要够，或者任务执行密度不能太大，否则等到线程任务释放完，trigger早已过期，就无法按预期时间触发了。

六、FAQ 
Q1、Quartz框架使用绝对时间触发机制有什么好处？ 
A1、我个人觉得这种机制对运行环境是一种过载保护，如果任务负荷过重，已经来不及执行的，就适当放弃。如此一来，我们使用就需要注意实际业务场景这种特性的存在，并通过适当增加线程资源，减小任务执行密度，任务错峰触发等方法来避免这种情况发生。只是个人见解，仅作参考。