金融福尔摩斯修炼册 -FULL GC 篇

报警

上周四微信上收到智能告警，某应用出现 full gc 频繁问题，初步观察了下 sgm 和线上机器情况，定位问题。每次告警都是对我们每个金融消防员的考验：如履薄冰，胆战心惊。

立案调查

• 分析依据：发生 fullGC 的最常见情况是老年代或者永久代空间不足时。

• 现场分析：通过 SGM 查看老年代和永久代的空间占比剩余空间还有一定比例，不至于发生 fullGC，发生原因最后分析。

另外 sgm 上看了下 jvm 监控，发现堆内存从 14 号上午窜上去后再没下来过，下面这个图很容易定位是发生了内存泄漏，以下的思路就顺着定位内存泄漏的程序进行

• 排查：看了下 mapi 代码提交记录，近期无上线，初步排除新上线代码问题。

在 sure 上使用 jmap 命令，发现 char 占据大量内存，怀疑存在大字符串。

周五找运维下了一份详细的 dump 文件，使用亮哥之前分享过的 IBMHeapAnalyzer 工具，分析发现问题可能出在 EnterRealNameApplyUploadImgReqModel 类里，这个类是用于实名申请时图片上传接口的入参实体类，里面包含了图片的 base64 的 string 串，占用较大空间。

排查 mapi 底层 biz 系统，查看 EnterRealNameApplyUploadImgReqModel 对应的实现类，发现 biz 中有对图片大小进行限制，最大为 2M，但是 mapi 无限制，怀疑可能为此接口中上传图片过大。

经磊哥点拨，发现 sdk 中对 base 串做了加密，并在 mapi 中做了解密处理，加解密工具为静态（static）工具方法，可能导致内存泄漏。

定位到问题后，再使用亮哥推荐的 visualVM 插件，在本地启了 mapi 应用，在 sdk 写了个死循环去调图片上传接口，并故意将照片设置为 3M，同时在 idea 的 VM Option 中 JVM 内存调至 300M，此时效果如下：

可以很清楚的发现，old 区增长速度特别快，同时 gc 次数频繁，并且无法有效的降低 old 区占用，old 区整体呈现递增趋势，很容易发生内存溢出，经过之前的定位流程，猜测为图片本身较大，在亚当区无法容纳该对象时，直接塞到 old 区，同时加解密方法为静态方法，被持续引用，导致无法进行垃圾回收，导致 old 区持续递增。

定案

处理方案：

• 生产服务器的内存为 8G，将堆内存从 2G 扩到 4G

• 图片上传接口不在走通用加解密流程，在 sdk、mapi 单独为其封装了一套特殊的加解密流程，base64 串不进行加密，直接做拼接处理，其余参数做加解密。处理后效果如下：

处理后可以很明显的发现无论是 Old Gen 区的递增速度还是 gc 次数相较于之前发生了很大的变化，趋于正常。

案中案-CPU 分析

以上过程其实问题已经得到解决，但发现频繁报 fullgc 的机器，cpu 一直占用在 10%以上，怀着打破砂锅问到底的态度对 cup 的问题也进行了下分析：

1、通过 top 命令查看占用 cpu 过高的进程

可以看到占用 cpu 的进程 PID 为 7975

2、通过命令查找到占用 cpu 最高的线程

命令：top -H -p [进程id] top –H –p 7975

3、将线程号转化为 16 进制（jstack 线程堆栈中使用的 16 进制）

printf "%x\n" [线程id]

4、 查找线程号对应的线程

执行： jstack [进程id] |grep -A 10 [线程id的16进制]

由上图可以看到，一直在占用 CPU 的线程是 CMS 垃圾回收线程，由于堆内存占用过高程序又不释放，垃圾回收线程一直在尝试回收内存导致 cpu 过高。

并案分析-垃圾回收原因

上面再分析触发垃圾回收的时候留了一个小尾巴，为什么老年代和永久代占用不高的时候频繁的发生了 full gc 呢。由于此应用使用的是 jdk1.6，垃圾回收器使用的是 CMS，它是基于“标记–清除”算法实现的，特点是在收集结束的时候会有大量的空间碎片产生。空间碎片太多的时候，将会给大对象的分配带来很大的麻烦，往往会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象的，只能提前触发 full gc。如果 jdk 调整为 1.7u4 及以上即可使用 G1 垃圾回收算法不会产生大量的空间碎片。

结案总结

JVM 问题一般不是很容易遇到，程序有 bug 或者并发量大的时候均可能导致 jvm 异常，通过以上问题的分析过程及以往的经验简单总结下排查 jvm 问题的一般思路：

• 查看 jvm 内存和机器 CPU 情况

• 内存占用过高，可能是发生内存泄漏，需要导出 dump 文件借助 mat 或者是 IBM HeapAnalyze 来分析内存中哪些对象占比比较高，那些实例较多的对象需要重点分析

• cpu 占用过高时可以通过步骤 4 的分析定位到具体的线程，程序编码中用到多线程的地方一定要给线程起个有意义的名字不要用默认的名字，这样出问题时方便定位。

上面只是个大概的流程，具体问题还需具体分析，重点还是需要 掌握 jvm 原理并灵活应用。