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

一、问题描述
使用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" />
         
        <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实现类中,代码如下:

/**
 * 

* Get a handle to the next trigger to be fired, and mark it as 'reserved' * by the calling scheduler. *

* * @see #releaseAcquiredTrigger(OperableTrigger) */
public List acquireNextTriggers(long noLaterThan, int maxCount, long timeWindow) { synchronized (lock) { List result = new ArrayList(); Set acquiredJobKeysForNoConcurrentExec = new HashSet(); Set excludedTriggers = new HashSet(); 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、我个人觉得这种机制对运行环境是一种过载保护,如果任务负荷过重,已经来不及执行的,就适当放弃。如此一来,我们使用就需要注意实际业务场景这种特性的存在,并通过适当增加线程资源,减小任务执行密度,任务错峰触发等方法来避免这种情况发生。只是个人见解,仅作参考。

你可能感兴趣的:(应用框架)