关于内存:慧销平台ThreadPoolExecutor内存泄漏分析

46次阅读

共计 5903 个字符,预计需要花费 15 分钟才能阅读完成。

作者:京东批发 冯晓涛

问题背景

京东生旅平台慧销零碎,作为平台零碎对接了多条业务线,次要进行各个业务线广告,召回等流动相干内容与能力治理。

最近依据告警发现内存继续升高,每隔 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 的援用,所以无奈被回收。

正文完
 0