性能文章>一次“诡异”的JVM缓存加载问题排查>

一次“诡异”的JVM缓存加载问题排查原创

2年前
7025416

项目中使用@Scheduled注解(Spring注解)来定时(每隔五分钟)刷新JVM缓存。

但测试环境和线上环境出现不一样的效果(如下图),测试环境每隔5分钟刷新一次,而线上环境刷新的时间间隔远远超过5分钟。测试环境的时间间隔均正常,而线上环境的时间间隔均不正常。

测试环境

image.png

线上环境

image.png

项目中有若干加载缓存的类,加载缓存的代码如下。

@Component
public class XXXCache {
    // 5分钟
    private final long PERIOD = 5L * 60L * 1000L;

    @Scheduled(fixedRate = PERIOD, initialDelay = PERIOD)
    public void loadCache() {
       //TODO
    }
}

分析:测试环境与线上环境代码一致,但测试环境加载的缓存数据量偏少。

猜测:由于数据量不同,导致测试环境和线上环境的执行时间间隔出现差异的现象。

进一步猜测:某些类加载缓存的时间偏长,导致其他类加载缓存的动作长时间处于等待状态。

那么问题来了,被@Scheduled注解的方法是并发执行的呢?还是串行执行的呢?

通过断点调试,发现在org.springframework.scheduling.config.ScheduledTaskRegistrar#scheduleTasks中,创建了单个线程的线程池,而这个线程池是用来执行整个项目中所有被@Scheduled注解的方法。当某个方法执行时间过久,那么其他方法的任务只能等待,从而导致其他缓存的加载时间间隔被拉长。

image.png

解决问题的思路:

  1. 找出加载数据量较多的方法,提高其执行间隔,降低单位时间内的加载次数。

  2. 修改上述线程池的大小,提高并发。

思路1比较好处理,如何处理思路2呢?


通过分析代码org.springframework.scheduling.annotation.ScheduledAnnotationBeanPostProcessor#finishRegistration,发现可以使用org.springframework.scheduling.annotation.SchedulingConfigurer来定制org.springframework.scheduling.TaskScheduler

见上文截图中创建单线程线程池代码所在的if语句,只要我们提前创建TaskScheduler,那么代码就不会再去创建单线程线程池的TaskScheduler。在我们自己创建TaskScheduler时,提高线程池的大小,从而达到并发的效果。

上代码

@Configuration
public class ScheduleConfig implements SchedulingConfigurer {

    @Override
    public void configureTasks(ScheduledTaskRegistrar taskRegistrar) {
        //初始化线程池
        ScheduledThreadPoolExecutor localExecutor = new ScheduledThreadPoolExecutor(3);

        ConcurrentTaskScheduler taskScheduler = new ConcurrentTaskScheduler(localExecutor);
        taskRegistrar.setScheduler(taskScheduler);
    }
}

本来来自公众号:线程池

请先登录,再评论

不错的文章

2年前

学习了666

2年前

我也遇到过使用Spring注解实现定时器在并发情况下无法正常触发的问题,当时花了很长时间排查为什么定时器无法按时执行,最后发现另一个定时器大约执行了6个小时左右,导致期间其他定时器都不触发
使用@Scheduled注解 可以使用pool-size参数控制线程数量。重要项目最好用quartz中间件吧 ,spring定时器不太靠谱

22年前

精炼👍

2年前

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得