【性能分析】分析JVM出现的内存泄漏的性能故障

分析JVM出现的内存持续增加的性能故障手册

前言

本文通过常见的性能文件为例，提供简单清晰的思路去快速定位问题根源，从而可以快速解决性能故障。

性能问题介绍

在性能测试工作中针对Java程序最重要的是要关注JVM的内存消耗情况，JVM的内存消耗情况源于gc情况。YGC的不稳定以及YGC的太频繁都会增加CPU等资源的使用。以典型的订购业务的性能问题为例介绍如何分析这类问题：

订购业务在大多数现场性能测试阶段都会发现性能问题，目前V81版本在基于去掉流程实例后，在进行长时间的稳定性测试发现随着稳定的压力，业务响应时间是越来越长。

性能问题分析

上面的问题是一种常见的性能问题，导致JVM内存增加的根本原因就是由于某个大的对象存活时间比较长，占用Yang区和Old区空间比较大，从而引发YGC很频繁同时也伴随着FGC。

分析问题步骤：

1. 监控JVM的内存消耗

很明显JVM消耗会超过3g这个是不正常的

1. 分析gc情况

使用jstat指令：jstat -gcutil pid

可以发现YGC是不断增加

详细分析YGC的情况将打印的gc.log使用GCViewer分析工具分析：YGC太频繁

1. 分析具体哪些对象导致

定位JVM的gc回收不正常后，需要进一步分析是哪些对象占用比较大。此时会有很多方式，但是强烈不建议你抓dump（如果是现网需要禁止抓dump会造成业务长时间的中断），建议使用：jmap – histo pid

从上图可以发现：

com.ztesoft.zsmart.bss.cc.abe.profile.SubsUppInst 这个对象实例大概占了0.5g。

然后进一步定位：jmap -histo:live pid

所以问题基本定位：

业务侧先分析下为什么很低的TPS会有这么多的SubsUppInst 对象。 主要是这个引起的GC波动，问题其实已经明确了。

1. 性能问题分析

目前V81版本在基于去掉流程实例后，在进行长时间的稳定性测试发现随着subs_upp_inst个性化实例表单个subs_id对应的记录不断增加后，程序对于JVM内存的消耗是越来越多，会引起YGC次数是越来越频繁，同时也会出现FGC。为了保证系统长时间的稳定运行是一定要避免FGC，同时YGC的回收要趋于稳定。因为YGC的越频繁，也就会对于CPU消耗会明显增加，同时影响业务响应时间。

1. 性能问题优化点

性能问题分析如下：

A. 如果不会有同订户下，订购几百次的场景，那么这个性能问题就不会出现
B. WsModUserIPP接口，如果wom需求没有针对IPP进行修改，删除操作，这个性能也不会出现 （需要简单优化下代码）
C. 不使用公共提供的subs_upp_inst捞取逻辑，原有的逻辑是将subs_id下所有生效的ipp都会捞出来给定制，然后定制开发考虑是否需要过滤。修改需要新开发接口在捞取的时候就过滤掉捞取的数据量（取第一条匹配subsId，offerId和state的记录）。除此之外在下订单和订购完成后多出代码都是全捞的记录，所以全量走查后全部改掉。

问题总结：

1. 需要你对JVM有一定的了解，需要知道引起YGC和FGC的原理
2. 需要掌握常规的gc日志抓取手段
3. 需要掌握分析gc.log的分析工具GCViewer
4. 需要掌握jstat和jmap的常规命令，需要知道指令对业务性能影响程度
5. 需要掌握订购业务逻辑

以上以案例介绍针对这类问题如何去分析。