导航菜单
路很长,又很短
博主信息
昵   称:Cocodroid ->关于我
Q     Q:2531075716
博文数:311
阅读量:875768
访问量:86607
至今:
×
云标签 标签球>>
云标签 - Su的技术博客
博文->>首页 博主的更多博文>>
实战解决:一次疑似内存泄漏的问题排查
Tags : 内存泄漏,实战,Hibernate发表时间: 2019-02-13 00:04:14
原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。
比如: 转自:Su的技术博客  原文地址:
1、问题背景
我的博客网站https://blog.verysu.com,有兴趣的可以访问下。
最近服务器到期等因素,进行了迁移。租了其它的外国厂商,但是由于资费问题,购买了1.5G 内存的服务器(现)。因为原本用惯了4G内存的服务器(原),现在压缩成这样,似乎不太能支持我的使用,囧!
现在就来说下blog服务分配的内存情况:
原:4G 内存,分配给blog,1.5G。
现:1.5G内存,分配给blog,500M。
由于此次调整,原本以为资源需求压力会更大。实际上应该不会,仔细想想,blog也没多少内容的。那么根据此次调整之后,已经出现了2次OutOfMemoryError了。
由于JVM参数配置有加上-XX:+HeapDumpOnOutOfMemoryError,所以出现OutOfMemoryError时会将堆栈输出到指定的文件,这样可以方便以后排查问题。
OS:CentOS7
Web容器:Tomcat 8
ORM:Hibernate3

数据库:MySQL5


2、问题解决过程
2.1 诊断排查出现内存泄漏对象

这个文件占用了差不多535M,说明里面的对象占用空间很大。这里我使用了MAT工具来排查。

1)Histogram (可以查看每个类的实例(即对象)的数量和大小)

通过Histogram图,我们初步看出,实际上跟我们自己的代码好像是没有关系,因为这里没找到我们对应的包名和类名。不过可以看到一些疑惑就是Tomcat和mysql相关的类占用了很大内存。

2)Dominator Tree(列出Heap Dump中处于活跃状态中的最大的几个对象,默认按 retained size进行排序)

从这里可以更加明确是哪些对象占用了大部分资源了,似乎也是跟Tomcat和mysql有关。


3)Top Consumer(按类、类加载器和包分别进行查询,并以饼图的方式列出最大的几个对象)

通过上面这个饼图,我们更加明确的是哪些对象占用了大部分资源。其它一些视图这里就不展开了。

小结:上面MAT的各种视图表明,并不是说占用资源大的对象是就是内存泄漏的罪魁祸首,它这里只是做了个统计,方便你观察和发现问题,只是提示你可能这些对象存在泄漏的可能性。

2.2 诊断排查占用大资源内因
由上面的图中,我从TaskThread这个类入手:

发现主要占用的资源在StatefulPersistenceContext这个类,很明显这个是Hibernate持久化相关的。

查看下类的注释,大致意思是:
PersistenceContext表示Hibernate正在跟踪的持久化“内容”的状态。这包括持久实体、集合以及生成的代理。
SessionImpl和PersistentContext之间应该是一对一的对应关系。SessionImpl使用PersistentContext来跟踪其上下文的当前状态。事件监听器使用PersistentContext来执行处理。
因为Hibernate的一级缓存就是在Session层面上,所以StatefulPersistenceContext跟一级缓存有关系,网上有些资料也有说StatefulPersistenceContext存在问题可能造成内存泄漏等原因。
可以在使用完Session时进行clear清除。这样就能防止占用过大资源,但是,使用一级缓存是能够大大的增强性能,如果这么做的话,似乎有违背Hibernate的设计初衷,因此,这里我们不能采取这种做法。

继续往下挖,看这里面存放的是具体什么对象吧!

从这里可以看出,持久化的主要对象实体是ShareArticle,并且有1706个实体之多!~,这里只是TaskThread这个线程所持有这么多的实体,要知道下面还有几个大对象TaskThread,里面也是有包含这些的,所以不仅仅1千个多实体。

2.3 找出问题根源(“真凶”)

看到这个实体的每个字段,才知道问题出现在哪!这张表有一个content字段,类型是mediumtext,存放文章内容。所以一旦加载到内存里,自然的需要占用大部分资源了。
找到问题的点在哪了,接下来就得看怎么优化,毕竟在资源急缺的我,需要优化下当前的服务了。

2.4 解决问题,优化!优化!
2.4.1 优化之一:查询不返回content字段
特别是哪些查询列表相关的。这能大大的减少占用内存。因为有些查询List结果实际上是没有使用到content字段,再次查询出来也是一种浪费。
说下这个过程吧,由于使用的是Hibernate,虽说有其优点,但是使用起来极其不灵活!在公司用惯了Mybatis,才知道Mybatis的好,哈哈!

2.4.2 优化之二:只查询需要的字段
在查询当前文章的上下文时,基本上也是不用用到content字段,这里只需要返回id和title,即可。其实跟上面2.4.1的类似。

2.4.3 优化之三:延迟加载指定字段
我们知道,Hibernate在一对多、多对多等关系中,是支持延迟加载的。查资料发现Hibernate3也能支持指定字段进行延迟加载,在需要的时候再次去查询数据库指定的字段再返回。
所以就动手干!但是也遇到使用时出现不生效,资料表明需要再次使用字节码进行增强才能正常使用。具体操作可以看下下面这篇文字:https://blog.verysu.com/article/414

小结:经过上面的优化,服务再也不会出现OutOfMemeryError了,而且资源占用也大幅度降低。

3、总结(经验与优化)
1)针对占用资源多的,是否能够不存在数据库,比如生成静态HTML文件,访问的时候直接包含在页面直接返回,这样能快速返回,占用内存少,提升性能。
2)针对大字段(占用资源大),没用到时不返回。
3)只返回需要的字段,在SQL优化的上必有,这样也能提升mysql的吞吐量,也不会浪费资源。
4)如果追求灵活性,ORM建议使用mybatis,毕竟互联网公司基本用它。Hibernate更适合在企业系统里面使用。
5)如果已经使用了Hibernate了,可以增加字段延迟加载机制,进而在需要的时候再去查询。
好了,为了写这篇文章,花了两个多小时,觉得不错的话,点个赞呗^_^!

推荐工具1:MAT:Eclipse Memory Analyzer

下载地址:http://www.eclipse.org/mat/

推荐工具2:IBM HeapAnalyzer

下载地址:https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=4544bafe-c7a2-455f-9d43-eb866ea60091


参考资料:

Java程序内存分析:使用mat工具分析内存占用

https://www.cnblogs.com/AloneSword/p/3821569.html

Shallow Heap 和 Retained Heap的区别

https://blog.csdn.net/a740169405/article/details/53610689

Shallow heap & Retained heap

https://www.jianshu.com/p/0deac3af0f45

Java堆:Shallow Size和Retained Size

https://blog.csdn.net/iteye_18480/article/details/82514130

Hibernate 一级缓存导致某保险公司核心系统Weblogic中间件内存溢出的故障诊断

https://blog.csdn.net/zhouleiblog/article/details/82834331

Hibernate 一级缓存的陷阱

https://www.cnblogs.com/hyl8218/p/5076338.html


打赏
打赏
关注公众号
公众号
类别:Java| 阅读(353)| 赞 (0)
评论
暂无评论!
发表评论
昵  称:

验证码:

内  容:

    同时赞一个 赞