java内存泄露排查总结

java1234

共 14803字,需浏览 30分钟

 ·

2021-05-11 18:00

点击上方蓝色字体,选择“标星公众号”

优质文章,第一时间送达

  作者 |  那个少年~

来源 |  urlify.cn/FvQVzi

76套java从入门到精通实战课程分享

1.内存溢出和内存泄露

一种通俗的说法:

  • 内存溢出:你申请了10个字节的空间,但是你在这个空间写入了11个或者以上字节的数据,则出现溢出

  • 内存泄露:你用new申请了一块内存,后来很长时间都不使用了,但是因为一直被某个或者某些实例所持有导致GC不能回收掉,也就是该释放的对象没有释放,则出现泄露。

1.1 内存溢出

java.lang.OutOfMemoryError:是指程序在申请内存时,没有足够的内存空间供其使用,出现OutOfMemoryError。

产生的原因

  • JVM内存过小

  • 程序不严密,产生了过多的垃圾

程序提现

  • 内存中加载的数据量过大,如一次性从数据库取出过多数据

  • 集合类中有对对象的引用,使用完后没有清空,是jvm不能回收

  • 代码中存在死循环或循环中产生过多重复的对象实体

  • 使用第三方软件中的bug

  • 启动参数内存值设定过小

常见错误提示

  • tomcat:java.lang.OutOfMemoryError: PermGen space

  • tomcat:java.lang.OutOfMemoryError: Java heap space

  • weblogic:Root cause of ServletException java.lang.OutOfMemoryError

  • resin:java.lang.OutOfMemoryError

  • java:java.lang.OutOfMemoryError

解决方法

  • 增加JVM的内存大小:对于tomcat容器,找到tomcat在电脑中的安装目录,进入这个目录,然后进入bin目录中,在window环境下找到bin目录中的catalina.bat,在linux环境下找到catalina.sh。编辑catalina.bat文件,找到JAVA_OPTS(具体来说是 set "JAVA_OPTS=%JAVA_OPTS% %LOGGING_MANAGER%")这个选项的位置,这个参数是Java启动的时候,需要的启动参数。也可以在操作系统的环境变量中对JAVA_OPTS进行设置,因为tomcat在启动的时候,也会读取操作系统中的环境变量的值,进行加载。如果是修改了操作系统的环境变量,需要重启机器,再重启tomcat,如果修改的是tomcat配置文件,需要将配置文件保存,然后重启tomcat,设置就能生效了。

  • 优化程序,释放垃圾:主要思路就是避免程序体现上出现的情况。避免死循环,防止一次载入太多的数据,提高程序健壮型及时释放。因此,从根本上解决Java内存溢出的唯一方法就是修改程序,及时地释放没用的对象,释放内存空间。

1.2 内存泄露

Memory Leak,是指程序在申请内存后,无法释放已申请的内存空间,一次内存泄露危害可以忽略,但内存泄露堆积后果很严重,无论多少内存,迟早会被占光。

在Java中,内存泄漏就是存在一些被分配的对象,这些对象有下面两个特点:

  • 首先,这些对象是可达的,即在有向图中,存在通路可以与其相连;

  • 其次,这些对象是无用的,即程序以后不会再使用这些对象。

如果对象满足这两个条件,这些对象就可以判定为Java中的内存泄漏,这些对象不会被GC所回收,然而它却占用内存。

关于内存泄露的处理页就是提高程序的健壮型,因为内存泄露是纯代码层面的问题。

1.3 内存溢出和内存泄露的联系

内存泄露会最终会导致内存溢出。
相同点:都会导致应用程序运行出现问题,性能下降或挂起。
不同点:1) 内存泄露是导致内存溢出的原因之一,内存泄露积累起来将导致内存溢出。2) 内存泄露可以通过完善代码来避免,内存溢出可以通过调整配置来减少发生频率,但无法彻底避免。

2、一个Java内存泄漏的排查案例

2.1 确定频繁的Full GC现象

首先通过“虚拟机进程状况工具:jps”找出正在运行的虚拟机进程,最主要是找出这个进程在本地虚拟机的唯一ID(LVMID,Local Virtual Machine Identifier),因为在后面的排查过程中都是需要这个LVMID来确定要监控的是哪一个虚拟机进程。
同时,对于本地虚拟机进程来说,LVMID与操作系统的进程ID(PID,Process Identifier)是一致的,使用Windows的任务管理器或Unix的ps命令也可以查询到虚拟机进程的LVMID。
jps命令格式为:
jps [ options ] [ hostid ]
使用命令如下:
使用jps:
jps -l
使用ps:ps aux | grep tomat

找到你需要监控的ID(假设为20954),再利用“虚拟机统计信息监视工具:jstat”监视虚拟机各种运行状态信息。
jstat命令格式为:
jstat [ option vmid [interval[s|ms] [count]] ]
使用命令如下:
jstat -gcutil 20954 1000
意思是每1000毫秒查询一次,一直查。gcutil的意思是已使用空间站总空间的百分比。
结果如下图:

查询结果表明:这台服务器的新生代Eden区(E,表示Eden)使用了28.30%(最后)的空间,两个Survivor区(S0、S1,表示Survivor0、Survivor1)分别是0和8.93%,老年代(O,表示Old)使用了87.33%。程序运行以来共发生Minor GC(YGC,表示Young GC)101次,总耗时1.961秒,发生Full GC(FGC,表示Full GC)7次,Full GC总耗时3.022秒,总的耗时(GCT,表示GC Time)为4.983秒。

2.2 找出频繁Full GC的原因

分析方法通常有两种:

  • 把堆dump下来在用MAT等工具进行分析,但是dump堆要花较长时间,并且文件巨大,再从服务器上拖回本地导入工具,这个过程有些折腾,不到万不得已最好别这么干。

  • 更轻量级的在线分析,使用jmap(java内存影响工具)生成堆转存快照(一般称为headdump或者dump文件)

jmap命令格式:
jmap [ option ] vmid
使用命令如下:
jmap -histo:live 20954
查看存活的对象情况,如下图所示:

按照一位IT友的说法,数据不正常,十有八九就是泄露的。在我这个图上对象还是挺正常的。

我在网上找了一位博友的不正常数据,如下:

可以看出HashTable中的元素有5000多万,占用内存大约1.5G的样子。这肯定不正常。

2.3 定位到代码

定位带代码,有很多种方法,比如前面提到的通过MAT查看Histogram即可找出是哪块代码。——我以前是使用这个方法。也可以使用BTrace,我没有使用过。

举例

一台生产环境机器每次运行几天之后就会莫名其妙的宕机,分析日志之后发现在tomcat刚启动的时候内存占用比较少,但是运行个几天之后内存占用越来越大,通过jmap命令可以查询到一些大对象引用没有被及时GC,这里就要求解决内存泄露的问题。

Java的内存泄露多半是因为对象存在无效的引用,对象得不到释放,如果发现Java应用程序占用的内存出现了泄露的迹象,那么我们一般采用下面的步骤分析:

  1.  用工具生成java应用程序的heap dump(如jmap)

  2. 使用Java heap分析工具(如MAT),找出内存占用超出预期的嫌疑对象

  3. 根据情况,分析嫌疑对象和其他对象的引用关系。

  4. 分析程序的源代码,找出嫌疑对象数量过多的原因。

以下一步步的按照项目实例来操作,去解决内存泄露的问题。

1. 登录linux服务器,获取tomcat的pid,命令:

ps -ef|grep java

2.利用jmap初步分析内存映射,命令:

jmap -histo:live 进程号 | head -7  

3. 如果上面一步还无法定位到关键信息,那么需要拿到heap dump,生成离线文件,做进一步分析,命令:

jmap -dump:live,format=b,file=heap.hprof 3514 

4.拿到heap dump文件,利用eclipse插件MAT来分析heap profile。

  1. 安装MAT插件

  2. 在eclipse里切换到Memory Analysis视图

  3. 用MAT打开heap profile文件。

Memory Analyzer插件下载

直接看到下面Action窗口,有4种Action来分析heap profile,介绍其中最常用的2种:

Histogram:这个使用的最多,跟上面的jmap -histo 命令类似,只是在MAT里面可以用GUI来展示应用系统各个类产生的实例。

Shllow Heap排序后发现 Cms_Organization 这个类占用的内存比较多(没有得到及时GC),查看引用:

分析引用栈,找到无效引用,打开源码:

有问题的源码如下:

public class RefreshCmsOrganizationStruts implements Runnable{  
  
    private final static Logger logger = Logger.getLogger(RefreshCmsOrganizationStruts.class);  
      
    private List<Cms_Organization> organizations;  
  
    private OrganizationDao organizationDao = (OrganizationDao) WebContentBean  
            .getInstance().getBean("organizationDao");  
    public RefreshCmsOrganizationStruts(List<Cms_Organization> organizations) {  
        this.organizations = organizations;  
    }  
  
    public void run() {  
        Iterator<Cms_Organization> iter = organizations.iterator();  
        Cms_Organization organization = null;  
        while (iter.hasNext()) {  
            organization = iter.next();  
            synchronized (organization) {  
                try {  
                    organizationDao.refreshCmsOrganizationStrutsInfo(organization.getOrgaId());  
                    organizationDao.refreshCmsOrganizationResourceInfo(organization.getOrgaId());  
                    organizationDao.sleep();  
                } catch (Exception e) {  
                    logger.debug("RefreshCmsOrganizationStruts organization = " + organization.getOrgaId(), e);  
                }  
            }  
        }  
    }  
  
}  

分析源码,定时任务定时调用,每次调用生成10个线程处理,而它又使用了非线程安全的List对象,导致List对象无法被GC收集,所以这里将List替换为CopyOnWriteArrayList 。

Dominator Tree:这个使用的也比较多,显示大对象的占用率。

同样的打开源码:

public class CategoryCacheJob extends QuartzJobBean implements StatefulJob {  
      
    private static final Logger LOGGER = Logger.getLogger(CategoryCacheJob.class);  
      
    public static Map<String,List<Cms_Category>> cacheMap = new java.util.HashMap<String,List<Cms_Category>>();  
  
    @Override  
    protected void executeInternal(JobExecutionContext ctx) throws JobExecutionException {  
        try {  
            //LOGGER.info("======= 缓存编目树开始 =======");  
            MongoBaseDao mongoBaseDao = (MongoBaseDao) BeanLocator.getInstance().getBean("mongoBaseDao");  
            MongoOperations mongoOperations = mongoBaseDao.getMongoOperations();  
              
            /* 
            LOGGER.info("1.缓存基础教育编目树"); 
            Query query = Query.query(Criteria.where("isDel").is("0").and("categoryType").is("F")); 
            query.sort().on("orderNo", Order.ASCENDING); 
            List<Cms_Category> list = mongoOperations.find(query, Cms_Category.class); 
            String key = query.toString().replaceAll("\\{|\\}|\\p{Cntrl}|\\p{Space}"""); 
            key += "_CategoryCacheJob"
            cacheMap.put(key, list); 
            */  
              
            //LOGGER.info("2.缓存职业教育编目树");  
            Query query2 = Query.query(Criteria.where("isDel").is("0").and("categoryType").in("JMP","JHP"));  
            query2.sort().on("orderNo", Order.ASCENDING);  
            List<Cms_Category> list2 = mongoOperations.find(query2, Cms_Category.class);  
            String key2 = query2.toString().replaceAll("\\{|\\}|\\p{Cntrl}|\\p{Space}""");  
            key2 += "_CategoryCacheJob";  
            cacheMap.put(key2, list2);  
              
            //LOGGER.info("3.缓存专题教育编目树");  
            Query query3 = Query.query(Criteria.where("isDel").is("0").and("categoryType").is("JS"));  
            query3.sort().on("orderNo", Order.ASCENDING);  
            List<Cms_Category> list3 = mongoOperations.find(query3, Cms_Category.class);  
            String key3 = query3.toString().replaceAll("\\{|\\}|\\p{Cntrl}|\\p{Space}""");  
            key3 += "_CategoryCacheJob";  
            cacheMap.put(key3, list3);  
              
            //LOGGER.info("======= 缓存编目树结束 =======");  
        } catch(Exception ex) {  
            LOGGER.error(ex.getMessage(), ex);  
            LOGGER.info("======= 缓存编目树出错 =======");  
        }  
    }  
  
}  

这里的HashMap也有问题:居然使用定时任务,在容器启动之后定时将数据放到Map里面做缓存?这里修改这部分代码,替换为使用memcached缓存即可。

内存泄漏的原因分析,总结出来只有一条:存在无效的引用!良好的编码规范以及合理使用设计模式有助于解决此类问题。

线程安全的CopyOnWriteArrayList介绍

CopyOnWriteArrayList使用了一种叫写时复制的方法,当有新元素添加到CopyOnWriteArrayList时,先从原有的数组中拷贝一份出来,然后在新的数组做写操作,写完之后,再将原来的数组引用指向到新数组。

当有新元素加入的时候,如下图,创建新数组,并往新数组中加入一个新元素,这个时候,array这个引用仍然是指向原数组的。

当元素在新数组添加成功后,将array这个引用指向新数组。

CopyOnWriteArrayList的整个add操作都是在锁的保护下进行的。 
这样做是为了避免在多线程并发add的时候,复制出多个副本出来,把数据搞乱了,导致最终的数组数据不是我们期望的。

CopyOnWriteArrayListadd操作的源代码如下:

 public boolean add(E e) {
    //1、先加锁
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        Object[] elements = getArray();
        int len = elements.length;
        //2、拷贝数组
        Object[] newElements = Arrays.copyOf(elements, len + 1);
        //3、将元素加入到新数组中
        newElements[len] = e;
        //4、将array引用指向到新数组
        setArray(newElements);
        return true;
    } finally {
       //5、解锁
        lock.unlock();
    }
}

由于所有的写操作都是在新数组进行的,这个时候如果有线程并发的写,则通过锁来控制,如果有线程并发的读,则分几种情况: 
1、如果写操作未完成,那么直接读取原数组的数据; 
2、如果写操作完成,但是引用还未指向新数组,那么也是读取原数组数据; 
3、如果写操作完成,并且引用已经指向了新的数组,那么直接从新数组中读取数据。

可见,CopyOnWriteArrayList的读操作是可以不用加锁的。

CopyOnWriteArrayList的使用场景

通过上面的分析,CopyOnWriteArrayList有几个缺点:

  1. 由于写操作的时候,需要拷贝数组,会消耗内存,如果原数组的内容比较多的情况下,可能导致yong gc或者full gc

  2. 不能用于实时读的场景,像拷贝数组,新增元素都需要时间,所以调用一个set操作后,读取到的数据可能还是旧的,虽然CopyOnWriteArrayList 能做到最终一致性,但是还无法满足实时性的要求

 

CopyOnWriteArrayList 合适读多写少的场景,不过这类慎用 ,因为谁也没法保证CopyOnWriteArrayList 到底要放置多少数据,万一数据稍微有点多,每次add/set都要重新复制数组,这个代价实在太高昂了。在高性能的互联网应用中,这种操作分分钟引起故障。





锋哥最新SpringCloud分布式电商秒杀课程发布

👇👇👇

👆长按上方微信二维码 2 秒





感谢点赞支持下哈 

浏览 52
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报