cron表达式解析死循环

[Jerryzhengtao]

Please answer some questions before submitting your issue. Thanks!

Which version of XXL-JOB do you using?

2.4.1

Expected behavior

Actual behavior

cron表达式 0/1 * * * * ? 解析会死循环

循环代码：

    public Date getNextInvalidTimeAfter(Date date) {
        long difference = 1000;
        
        // 省略部分代码

        while (difference == 1000) { 
            newDate = getTimeAfter(lastDate);
            if(newDate == null)
                break;
            
            difference = newDate.getTime() - lastDate.getTime(); // 该表达式difference一直是1000，导致while不退出
            
            if (difference == 1000) {
                lastDate = newDate;
            }
        }
        
        return new Date(lastDate.getTime() + 1000);
    }

Steps to reproduce the behavior

Other information

[Jerryzhengtao]

另外 压测的时候发现自带的cron解析比较耗时。可以替换为spring的cron解析类 + cron LRU 缓存。
经过测试：

1. 只替换为spring解析。
   • 解析次数 >= 2000时，xxlCron耗时略高于springCron。
   • 解析次数 <= 2000时，xxlCron低于springCron约1倍，springCron反而慢，总耗时均在几十毫秒，不到一百。（这里推断springCron对象创建过程耗时比xxlCron高，但解析更快）
2. 只增加cron缓存时，效率提升明显。
   • 解析次数 = 600时，不加缓存耗时30ms左右，加缓存的xxlCron耗时在10ms左右。
   • 解析次数 = 6000时，不加缓存耗时80ms左右，加缓存的xxlCron耗时在40ms左右。 效率均有提升。
3. 替换为springCron并加缓存，缓存数量为500，效率极高。
   • 解析次数 = 300时，springCron+缓存耗时3ms，而只用xxlCron的耗时在20ms，左右，相差7倍
   • 解析次数 = 3000时，springCron+缓存耗时仍然在10ms以下，而只用xxlCron的耗时在70ms左右，相差8倍
   • 解析次数 = 6000时，springCron+缓存耗时仍然在15ms左右，而只用xxlCron的耗时在85ms左右，相差6倍
     综上看来，使用springCron+缓存能极大提高cron解析效率，降低任务触发延时，大部分情况下，cron解析延迟均能控制在个位数。

ps：LRU使用jdk自带LinkedHashMap，纯本地环境测试。

[Jerryzhengtao]

上面说错了，应该是xxlCron创建更耗时，所以数据量大的时候效率更差，加缓存提升更明显。我尝试修改缓存大小，发现缓存大小对xxlCron影响更大。