Java服务假死后续之内存溢出的原因分析

更新时间：2022年07月05日 10:25:02 作者：kbkb

这篇文章主要介绍了Java服务假死后续之内存溢出,本文给大家分享原因排查和故障解决方法，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下

一、现象分析

上篇博客说到，Java服务假死的原因是使用了Guava缓存，30分钟的有效期导致Full GC无法回收内存。经过优化后，已经不再使用Guava缓存，实时查询数据。从短期效果来看，确实解决了无法回收内存的问题，但是服务运行几天后，发现内存又逐渐被占满，Full GC后只能回收一小部分。

从上图可以看出，一次Full GC后，老年代基本上没有回收多少内存，占比从99.86%降到99.70%。

二、原因排查

到底是什么对象占据这么大的内存，并且无法被JVM垃圾回收呢。在上一篇博客中已经移除了Guava缓存，按理说不应该有无法回收的对象了。那么，很明显这应该是代码问题导致了内存泄露，现在需要知道哪些对象无法被回收，从而定位出代码哪里有BUG。这里采用jmap -histo:live 201349|head -10命令打印出GC后存活的对象。

从上图可以看出，还是之前存在Guava缓存里面的对象占据着大部分内存，代码修改为实时查询后，每次用完数据都会从Map中剔除，按理不应该有强引用去引用这些对象。光看代码无法排查出哪里导致了内存泄露，只能将GC后的内存文件导出来进行分析。这里采用jmap -dump:format=b,file=/data/heap.hprof命令将内存文件导出来，用JDK自带的visualVM打开。

这里拿ECBug对象进行分析，从引用关系可以看出，ECBug对象被DataSetCenter引用，DataSetCenter就是实时查询数据进行存储的一个ConcurrentHashMap，但每次用完数据后都会进行remove操作，具体代码如下所示。

private List<BusinessBean> realTimeQueryBusinessModelData(IDataSetKey accessCacheDataSetKey,Set<IMapper> mappers, Set<IFilter> filters, Set<ISorter> sorters) throws DataNotFoundException, IllegalAccessException, CloneNotSupportedException, InstantiationException {
        List<BusinessBean> resultBeans = null;
        try {
            lock.lock();
            if (!dataSetCenter.containsKey(accessCacheDataSetKey)) {
                log.info("put DataSetKey into DataSetCenter,dataSetKey is {}",accessCacheDataSetKey);
                int count = businessModelQuery.count(accessCacheDataSetKey);
                if (count == 0) throw new DataNotFoundException();
                Class modelClass = businessModelCenter.getDataModelClass(accessCacheDataSetKey.getModelId());
                if (modelClass == null) {
                    throw new DataNotFoundException();
                }
                dataSetCenter.put(accessCacheDataSetKey, new DataSet(count, modelClass));
            }
            List<BusinessBean> cachedBeans = dataSetCenter.get(accessCacheDataSetKey).getData();
            resultBeans =  getModelDataInternal(accessCacheDataSetKey, businessModelQuery, mappers, filters, sorters, cachedBeans);
        }finally {
            lock.unlock();
            if(!lock.isLocked()){
                dataSetCenter.remove(accessCacheDataSetKey);
            }
        }
        return resultBeans;
    }

从代码来看，每次dataSetCenter.put(accessCacheDataSetKey, new DataSet(count, modelClass))后，都会在finally里面调用dataSetCenter.remove(accessCacheDataSetKey)把key删除掉，这样在GC时会自动回收Value值。但是忽略了一个方法getModelDataInternal，该方法可能会递归调用realTimeQueryBusinessModelData方法，如果存在递归调用的话，那么由于可重入锁lock还没有完成解锁，所以无法进入if(!lock.isLocked())条件语句中进行删除key的操作，这样就造成了一部分数据无法被删除，随着时间的推移，内存中的数据会越来越多。

三、故障解决

基于上述的代码分析，改造如下所示。

private List<BusinessBean> realTimeQueryBusinessModelData(IDataSetKey accessCacheDataSetKey,Set<IMapper> mappers, Set<IFilter> filters, Set<ISorter> sorters) throws DataNotFoundException, IllegalAccessException, CloneNotSupportedException, InstantiationException {
        List<BusinessBean> resultBeans = null;
        try {
            queryLock.lock();
            modelQueryLock.lock();
            if (!dataSetCenter.containsKey(accessCacheDataSetKey)) {
                log.info("put DataSetKey into DataSetCenter,dataSetKey is {}",accessCacheDataSetKey);
                int count = businessModelQuery.count(accessCacheDataSetKey);
                if (count == 0) throw new DataNotFoundException();
                Class modelClass = businessModelCenter.getDataModelClass(accessCacheDataSetKey.getModelId());
                if (modelClass == null) {
                    throw new DataNotFoundException();
                }
                dataSetCenter.put(accessCacheDataSetKey, new DataSet(count, modelClass));
            }
            List<BusinessBean> cachedBeans = dataSetCenter.get(accessCacheDataSetKey).getData();
            resultBeans =  getModelDataInternal(accessCacheDataSetKey, businessModelQuery, mappers, filters, sorters, cachedBeans);
        }finally {
            modelQueryLock.unlock();
            if(!modelQueryLock.isLocked()){
                removeDataSetKeys();
            }
            queryLock.unlock();
        }
        return resultBeans;
    }

这里当modelQueryLock可重入锁完全解锁后，调用removeDataSetKeys方法，该方法会将dataSetCenter里面的key全部删除，这样在GC时就会回收不用的数据对象。这里采用两个可重入锁的目的是，如果只用一个modelQueryLock可重入锁，那么当modelQueryLock完全解锁后，正在执行removeDataSetKeys方法时，其他线程就可以进入该方法区，发现dataSetCenter里面还没有删除完全，从而获取里面的数据，即if (!dataSetCenter.containsKey(accessCacheDataSetKey))为false，从而通过List<BusinessBean> cachedBeans = dataSetCenter.get(accessCacheDataSetKey).getData()直接获取dataSetCenter里面的数据，但是下一刻dataSetCenter里面可能已经为空。因此，采用两个可重入锁，防止出现异常。

到此这篇关于Java服务假死后续之内存溢出的文章就介绍到这了,更多相关Java 内存溢出内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:

Kafka之kafka-topics.sh的使用解读
这篇文章主要介绍了Kafka之kafka-topics.sh的使用解读，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教
2023-03-03
老生常谈java中的fail-fast机制
下面小编就为大家带来一篇老生常谈java中的fail-fast机制。小编觉得挺不错的，现在就分享给大家，也给大家做个参考。一起跟随小编过来看看吧
2017-08-08
java常见事件响应方法实例汇总
这篇文章主要介绍了java常见事件响应方法,对于初学者有很好的参考借鉴价值,分享给大家,需要的朋友可以参考下
2014-08-08
举例讲解JDK注解的使用和自定义注解的方法
今天小编就为大家分享一篇关于举例讲解JDK注解的使用和自定义注解的方法，小编觉得内容挺不错的，现在分享给大家，具有很好的参考价值，需要的朋友一起跟随小编来看看吧
2019-03-03
jar包加密方案分享
如何对jar包进行加密呢？其实没有想象中的那么困难，有一款开源工具已经提供了较为完善的加密方案，这款开源工具的名字叫做xjar。接下来我们就看一下使用xjar工具给jar包加密有多么的容易。
2021-06-06
简述springboot及springboot cloud环境搭建
这篇文章主要介绍了简述springboot及springboot cloud环境搭建的方法，包括spring boot 基础应用环境搭建，需要的朋友可以参考下
2017-07-07
详解JDBC对Mysql utf8mb4字符集的处理
这篇文章主要介绍了详解JDBC对Mysql utf8mb4字符集的处理，小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧
2018-11-11
Shiro + JWT + SpringBoot应用示例代码详解
这篇文章主要介绍了Shiro （Shiro + JWT + SpringBoot应用），本文通过实例代码给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
2020-06-06
SpringBoot整合Redis将对象写入redis的实现
本文主要介绍了SpringBoot整合Redis将对象写入redis的实现，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
2022-06-06
Spring依赖注入的三种方式详解
这篇文章主要给大家介绍了三种Spring依赖注入的方式, settter方法注入,构造器注入以及变量(filed) 注入这三种方式,文章通过代码示例给大家介绍的非常详细,需要的朋友可以参考下
2023-11-11