起因:最近在跟踪产品的性能问题,期间主要问题体现在JVM的内存回收问题,使用MAT工具进行JVM内存分析(也可对android 的应用内存分析)
问题描述:
1、部分后端服务在运行一段时间后会突然年老代会变为100%
2、部分后端服务定期出现年轻代GC情况,耗时超过2S
问题1解决步骤:
利用jmap指令(jmap -dump:format=b,file=文件名 PID)生成内存快照文件。文件名支持相对路径和绝对路径,PID指Java应用的进程ID,可通过JPS指令获取,在有些时候该指令无法直接生成内存快照,需要额外补充-f,原因会在稍后的文章中说明。
在官网下载MAT独立包(推荐64位,并修改MemoryAnalyzer.ini文件中的-Xmx,确保其值大于你的内存快照文件大小,否则MAT打开内存文件会报内存溢出),打开之前保存的内存快照文件
打开后,直接选择leak suspects选项(该选项表示MAT会自动帮我们分析内存泄漏最可能的类),分析完后类比下图(图片来自网络)
一般来说,该报告会告诉我们最可能泄露的类和相关实例,我们点进打开后,对Retained Heap最大的实例再点击选择outGoing references(当前对象,引用的外部对象),即可查看该实例中引用了哪些对象,一直没释放,从而导致该实例占了不少内存
根据步骤4基本就可以确认,究竟是哪些对象实例强引用未能释放,从而导致内存持续上涨直至频繁FGC,这时候就可以拉上开发的童鞋根据代码进行分析
回到问题的原点,这次的问题发生的原因是:多例模式下,大量的对象被加载到OSGI的核心容器中,从而导致大并发情况下,导致内存出现泄漏,最后内存溢出
问题2解决步骤:
分析步骤与问题1并无偏差,但奇怪的现象是生成的报告中任何对象的实例的大小都很小,且总和与实际的内存文件相差甚远
MAT默认是只分析reachable对象实例,所以在"Preferences=>Memory Analyzer"中勾选"Keep Unreachable Objects",删除索引文件Dump同路径下的所有".index",即可看到所有的对象,再根据上述步骤4进行分析
此时发现某个对象实例,其某个属性List无比庞大(size>10000)
后经与研发同事分析得知,某些查询动作会入库,从而导致日积月累的情况下,查询时就会创建一个额外的对象,引发频繁的young gc,甚至full gc
问题反思:
版本测试时,除了常规的功能测试外,还要对核心业务进行性能测试,根据时间进度可适当切割,但不能缺失
场景测试时,除了常规的场景测试外,还需考虑当前的数据库量级,若当前表量级较大,业务模块中的sql语句是否有做limit等限制
生产环境上应对应用做相关监控,除了日常的服务器本身性能监控外,还需要对应用本身的各项指标监控,例如:GC次数、GC耗时甚至young、s0、s1、pem、old等不同年代的监控。根据日常的监控图表来判断当前服务是否正常
一般来说,young gc的次数要大于old gc和full gc,且耗时是毫秒级。不然,则有可能:young年代设置过小,应用创建了过大的对象,存在大量强应用的对象实例等
参考资料:
https://my.oschina.net/flashsword/blog/265442
http://www.blogjava.net/rosen/archive/2010/06/13/323522.html