头图

慧销平台ThreadPoolExecutor内存泄漏分析

作者:京东零售 冯晓涛

问题背景

京东生旅平台慧销系统,作为平台系统对接了多条业务线,主要进行各个业务线广告,召回等活动相关内容与能力管理。

最近根据告警发现内存持续升高,每隔2-3天会收到内存超过阈值告警,猜测可能存在内存泄漏的情况,然后进行排查。根据24小时时间段内存监控可以发现,容器的内存在持续上升:



问题排查

初步估计内存泄漏,查看24小时时间段jvm内存监控,排查jvm内存回收情况:

YoungGC和FullGC情况:



通过jvm内存分析和YoungGC与FullGC执行情况,可以判断可能原因如下:

1、 存在YoungGC但是没有出现FullGC,可能是对象进入老年代但是没有到达FullGC阈值,所以没有触发FullGC,对象一直存在老年代无法回收

2、 存在内存泄漏,虽然执行了YoungGC,但是这部分内存无法被回收

通过线程数监控,观察当前线程情况,发现当前线程数7427个,并且还在不断上升,基本判断存在内存泄漏,并且和线程池的不当使用有关:

通过JStack,获取线程堆栈文件并进行分析,排查为什么会有这么多线程:



发现通过线程池创建的线程数达7000+:

代码分析

分析代码中ThreadPoolExecutor的使用场景,发现在一个worker公共类中定义了一个线程池,worker执行时会使用线程池进行异步执行。

 public class BackgroundWorker {
 
     private static ThreadPoolExecutor threadPoolExecutor;
 
     static {
         init(15);
     }
 
     public static void init() {
         init(15);
     }
 
     public static void init(int poolSize) {
         threadPoolExecutor =
                 new ThreadPoolExecutor(3, poolSize, 1000, TimeUnit.MINUTES, new LinkedBlockingDeque<>(1000), new ThreadPoolExecutor.CallerRunsPolicy());
     }
 
     public static void shutdown() {
         if (threadPoolExecutor != null && !threadPoolExecutor.isShutdown()) {
             threadPoolExecutor.shutdownNow();
         }
     }
 
     public static void submit(final Runnable task) {
         if (task == null) {
             return;
         }
         threadPoolExecutor.execute(() -> {
             try {
                 task.run();
             } catch (Exception e) {
                 e.printStackTrace();
             }
         });
     }
 
 }

广告缓存刷新worker使用线程池的代码:

 public class AdActivitySyncJob {

    @Scheduled(cron = "0 0/5 * * * ?")
    public void execute() {
        log.info("AdActivitySyncJob start");
        List<DicDTO> locationList = locationService.selectLocation();
        if (CollectionUtils.isEmpty(locationList)) {
            return;
        }

        //中间省略部分无关代码

        BackgroundWorker.init(40);
        locationCodes.forEach(locationCode -> {
            showChannelMap.forEach((key,value)->{
                BackgroundWorker.submit(new Runnable() {
                    @Override
                    public void run() {
                        log.info("AdActivitySyncJob,locationCode:{},showChannel:{}",locationCode,value);
                        Result<AdActivityDTO> result = notLoginAdActivityOuterService.getAdActivityByLocationInner(locationCode, ImmutableMap.of("showChannel", value));
                        LocalCache.AD_ACTIVITY_CACHE.put(locationCode.concat("_").concat(value), result);
                    }
                });
            });
        });
        log.info("AdActivitySyncJob end");
    }

    @PostConstruct
    public void init() {
        execute();
    }
}

原因分析:猜测是worker每次执行,都会执行init方法,创建新的线程池,但是局部创建的线程池并没有被关闭,导致内存中的线程池越来越多,ThreadPoolExecutor在使用完成后,如果不手动关闭,无法被GC回收。

分析验证

验证局部线程池ThreadPoolExecutor创建后,如果不手动关闭,是否会被GC回收:

public class Test {
    private static ThreadPoolExecutor threadPoolExecutor;

    public static void main(String[] args) {
        for (int i=1;i<100;i++){
            //每次均初始化线程池
            threadPoolExecutor =
                    new ThreadPoolExecutor(3, 15, 1000, TimeUnit.MINUTES, new LinkedBlockingDeque<>(1000), new ThreadPoolExecutor.CallerRunsPolicy());

            //使用线程池执行任务
            for(int j=0;j<10;j++){
                submit(new Runnable() {
                    @Override
                    public void run() {
                    }
                });
            }

        }
        //获取当前所有线程
        ThreadGroup group = Thread.currentThread().getThreadGroup();
        ThreadGroup topGroup = group;
        // 遍历线程组树,获取根线程组
        while (group != null) {
            topGroup = group;
            group = group.getParent();
        }
        int slackSize = topGroup.activeCount() * 2;
        Thread[] slackThreads = new Thread[slackSize];
        // 获取根线程组下的所有线程,返回的actualSize便是最终的线程数
        int actualSize = topGroup.enumerate(slackThreads);
        Thread[] atualThreads = new Thread[actualSize];
        System.arraycopy(slackThreads, 0, atualThreads, 0, actualSize);
        System.out.println("Threads size is " + atualThreads.length);
        for (Thread thread : atualThreads) {
            System.out.println("Thread name : " + thread.getName());
        }
    }

    public static void submit(final Runnable task) {
        if (task == null) {
            return;
        }
        threadPoolExecutor.execute(() -> {
            try {
                task.run();
            } catch (Exception e) {
                e.printStackTrace();
            }
        });
    }
}

输出:

Threads size is 302

Thread name : Reference Handler

Thread name : Finalizer

Thread name : Signal Dispatcher

Thread name : main

Thread name : Monitor Ctrl-Break

Thread name : pool-1-thread-1

Thread name : pool-1-thread-2

Thread name : pool-1-thread-3

Thread name : pool-2-thread-1

Thread name : pool-2-thread-2

Thread name : pool-2-thread-3

Thread name : pool-3-thread-1

Thread name : pool-3-thread-2

Thread name : pool-3-thread-3

Thread name : pool-4-thread-1

Thread name : pool-4-thread-2

Thread name : pool-4-thread-3

Thread name : pool-5-thread-1

Thread name : pool-5-thread-2

Thread name : pool-5-thread-3

Thread name : pool-6-thread-1

Thread name : pool-6-thread-2

Thread name : pool-6-thread-3

…………

执行结果分析,线程数量302个,局部线程池创建的核心线程没有被回收。

修改初始化线程池部分:

//初始化一次线程池
threadPoolExecutor =
        new ThreadPoolExecutor(3, 15, 1000, TimeUnit.MINUTES, new LinkedBlockingDeque<>(1000), new ThreadPoolExecutor.CallerRunsPolicy());

for (int i=1;i<100;i++){
    //使用线程池执行任务
    for(int j=0;j<10;j++){
        submit(new Runnable() {
            @Override
            public void run() {
            }
        });
    }

}

输出:

Threads size is 8

Thread name : Reference Handler

Thread name : Finalizer

Thread name : Signal Dispatcher

Thread name : main

Thread name : Monitor Ctrl-Break

Thread name : pool-1-thread-1

Thread name : pool-1-thread-2

Thread name : pool-1-thread-3

解决方案

1、只初始化一次,每次执行worker复用线程池

2、每次执行完成后,关闭线程池

BackgroundWorker的定位是后台执行worker均进行线程池的复用,所以采用方案1,每次在static静态代码块中初始化,使用时无需重新初始化。

解决后监控:

jvm内存监控,内存不再持续上升:





线程池恢复正常且平稳:





Jstack文件,观察线程池数量恢复正常:





Dump文件分析线程池对象数量:





拓展

1、 如何关闭线程池

线程池提供了两个关闭方法,shutdownNow 和 shutdown 方法。

shutdownNow方法的解释是:线程池拒接收新提交的任务,同时立马关闭线程池,线程池里的任务不再执行。

shutdown方法的解释是:线程池拒接收新提交的任务,同时等待线程池里的任务执行完毕后关闭线程池。

2、 为什么threadPoolExecutor不会被GC回收

threadPoolExecutor =
         new ThreadPoolExecutor(3, 15, 1000, TimeUnit.MINUTES, new LinkedBlockingDeque<>(1000), new ThreadPoolExecutor.CallerRunsPolicy());

局部使用后未手动关闭的线程池对象,会被GC回收吗?获取线上jump文件进行分析:





发现线程池对象没有被回收,为什么不会被回收?查看ThreadPoolExecutor.execute()方法:

如果当前线程数小于核心线程数,就会进入addWorker方法创建线程:



分析runWorker方法,如果存在任务则执行,否则调用getTask()获取任务:

发现workQueue.take()会一直阻塞,等待队列中的任务,因为Thread线程一直没有结束, 存在引用关系:ThreadPoolExecutor->Worker->Thread,因为存在GC ROOT的引用,所以无法被回收 。


京东云技术新知
京东云最新产品信息、技术干货以及最新活动发布,拥抱技术,与开发者携手创造未来!

京东云开发者(Developer of JD Technology)是京东云旗下为AI、云计算、IoT等相关领域开发者提供技术分...

2.5k 声望
5.2k 粉丝
0 条评论
推荐阅读
玩转服务器之网站篇:新手使用WordPress搭建博客和静态网站部署
静态网站部署和WordPress搭建博客都是网站运营中常见的工作。静态网站是一种不需要服务器端脚本的网站形式,通常使用HTML、CSS和JavaScript等静态资源进行构建和显示。而WordPress是一款流行的博客系统,可以帮助...

京东云开发者

封面图
在Linux上查看活跃线程数与连接数
现如今,有两种常见的软件资源几乎成了Java后端程序的标配,即线程池与连接池,但这些池化资源非常的重要,一旦不够用了,就会导致程序阻塞、性能低下,所以有时我们需要看看它们的使用情况,以判断这里是否是瓶颈。

扣钉日记3阅读 1.4k

封面图
jvm堆内存和GC简介
年轻代分为生成区(Eden)和幸存区(Survivor),幸存区由FromSpace和Tospace两部分组成,默认情况下,内存大小比例:Eden:FromSpace:ToSpace 为 8:1:1。

蓝色瞳仁2阅读 3.5k

jmap执行失败了,怎么获取heapdump?
但当我反复模拟OOM场景测试时,发现jmap有时可以dump成功,有时会报错,如下: 经过网上一顿搜索,发现两种原因可能导致这个问题,一是执行jmap用户与jvm进程用户不一致,二是/tmp/.java_pidXXX文件被删除,但经...

扣钉日记2阅读 436

封面图
从原理聊JVM(一):染色标记和垃圾回收算法
属于共享内存区域,存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。运行时常量池,属于方法区的一部分,用于存放编译期生成的各种字面量和符号引用。

京东云开发者3阅读 389

封面图
java获取到heapdump文件后,如何快速分析?
在之前的OOM问题复盘之后,本周,又一Java服务出现了内存问题,这次问题不严重,只会触发堆内存占用高报警,没有触发OOM,但好在之前的复盘中总结了dump脚本,会在堆占用高时自动执行jstack与jmap,使得我们成功...

扣钉日记2阅读 718

封面图
线上FullGC问题排查实践——手把手教你排查线上问题 | 京东云技术团队
观察该机器日志发现,此时有很多线程在执行跑批任务。正常来说,跑批任务是低CPU高内存型,所以此时考虑是FullGC引起的大量CPU占用(之前有类似情况,告知用户后重启应用后解决问题)。

京东云开发者2阅读 325

封面图

京东云开发者(Developer of JD Technology)是京东云旗下为AI、云计算、IoT等相关领域开发者提供技术分...

2.5k 声望
5.2k 粉丝
宣传栏