应用程序内存泄漏问题排查--运维排查技巧

                                                                        应用程序内存泄漏问题排查        

1.文章的由来;

 在日常运维过程中,会遇到服务器资源居高不下,或者CPU内存暴涨问题而引发的oom导致服务不可用 (大多数程序都是java应用),由此编写了该文章,为工作排查问题参考依据和快速定位问题方法;

2.基础知识储备；

   (1).jvm 配置常见参数:

 堆参数参数

回收器参数

如上表所示，目前主要有串行、并行和并发三种，对于大内存的应用而言，串行的性能太低，因此使用到的主要是并行和并发两种。并行和并发 GC 的策略通过 UseParallelGC 和 UseConcMarkSweepGC 来指定，还有一些细节的配置参数用来配置策略的执行方式。例如：XX:ParallelGCThreads， XX:CMSInitiatingOccupancyFraction 等。 通常：Young 区对象回收只可选择并行（耗时间），Old 区选择并发（耗 CPU）。

项目中可参考常用配置

生产环境服务配置参数

常见组合

GC 调优原则

在调优之前，我们需要记住下面的原则：

多数的 Java 应用不需要在服务器上进行 GC 优化；

多数导致 GC 问题的 Java 应用，都不是因为我们参数设置错误，而是代码问题；

在应用上线之前，先考虑将机器的 JVM 参数设置到最优（最适合）；

减少创建对象的数量；

减少使用全局变量和大对象；

GC 优化是到最后不得已才采用的手段；

在实际使用中，分析 GC 情况优化代码比优化 GC 参数要多得多。

GC 调优目的

将转移到老年代的对象数量降低到最小；

减少 GC 的执行时间。

策略 1：将新对象预留在新生代，由于 Full GC 的成本远高于 Minor GC，因此尽可能将对象分配在新生代是明智的做法，实际项目中根据 GC 日志分析新生代空间大小分配是否合理，适当通过“-Xmn”命令调节新生代大小，最大限度降低新对象直接进入老年代的情况。

策略 2：大对象进入老年代，虽然大部分情况下，将对象分配在新生代是合理的。但是对于大对象这种做法却值得商榷，大对象如果首次在新生代分配可能会出现空间不足导致很多年龄不够的小对象被分配的老年代，破坏新生代的对象结构，可能会出现频繁的 full gc。因此，对于大对象，可以设置直接进入老年代（当然短命的大对象对于垃圾回收老说简直就是噩梦）。-XX:PretenureSizeThreshold 可以设置直接进入老年代的对象大小。

策略 3：合理设置进入老年代对象的年龄，-XX:MaxTenuringThreshold 设置对象进入老年代的年龄大小，减少老年代的内存占用，降低 full gc 发生的频率。

策略 4：设置稳定的堆大小，堆大小设置有两个参数：-Xms 初始化堆大小，-Xmx 最大堆大小。

策略5：注意： 如果满足下面的指标，则一般不需要进行 GC 优化：

MinorGC 执行时间不到50ms；

Minor GC 执行不频繁，约10秒一次；

Full GC 执行时间不到1s；

Full GC 执行频率不算频繁，不低于10分钟1次。

3.排查技巧战

1.内存泄漏排查技巧

系统命令

1.登陆探测服务器，首先是 top free df 三连;

jstat

jstat 是一个非常强大的 JVM 监控工具，一般用法是：jstat [-options] pid interval

它支持的查看项有：

• -class 查看类加载信息

• -compile 编译统计信息

• -gc 垃圾回收信息

• -gcXXX 各区域 GC 的详细信息 如 -gcold

3. jstat -gc pid [interval] 查看  java 进程的 GC 状态;

关注指标: FULL GC 。

4. jstack pid > jstack.log 查询线程栈 并保存现场;

分析栈

栈的分析很简单，看一下线程数是不是过多，多数栈都在干嘛。

> grep 'java.lang.Thread.State' jstack.log  | wc -l
> 464

过滤进程

grep -A 1 'java.lang.Thread.State' jstack.log  | grep -v 'java.lang.Thread.State' | sort | uniq -c |sort -n

    10     at java.lang.Class.forName0(Native Method)
    10     at java.lang.Object.wait(Native Method)
    16     at java.lang.ClassLoader.loadClass(ClassLoader.java:404)
    44     at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
   344     at sun.misc.Unsafe.park(Native Method)

线程状态好像也无异常，接下来分析堆文件。

内存堆dump  

5.使用 jmap -dump:format=b,file=heap.log pid 保存了堆现场，然后重启了应用服务

堆文件都是一些二进制数据，在命令行查看非常麻烦，Java 为我们提供的工具都是可视化的，Linux 服务器上又没法查看，那么首先要把文件下载到本地。

由于我们设置的堆内存为 4G，所以 dump 出来的堆文件也很大，下载它确实非常费事，不过我们可以先对它进行一次压缩。=

gzip 是个功能很强大的压缩命令，特别是我们可以设置 -1 ~ -9 来指定它的压缩级别，数据越大压缩比率越大，耗时也就越长，推荐使用 -6~7， -9 实在是太慢了，且收益不大，有这个压缩的时间，多出来的文件也下载好了。

使用 MAT 分析 jvm heap

MAT 是分析 Java 堆内存的利器，使用它打开我们的堆文件（将文件后缀改为 .hprof）, 它会提示我们要分析的种类，果断选择 memory leak suspect。

windows 系统安装包如下:

https://www.eclipse.org/downloads/download.php?file=/mat/1.9.1/rcp/MemoryAnalyzer-1.9.1.20190826-win32.win32.x86_64.zip