内存泄露排查

http://www.javashuo.com/article/p-nthaviyi-mu.html

• jps -l
  • 查看虚拟机属于哪一个进程
• jstat -gcutil 20954 1000
  • 每1000毫秒查询一次，一直查。
  • gcutil的意思是已使用空间站总空间的百分比。
  • 查询结果代表：这台服务器的
    • 新生代Eden区（E，表示Eden）使用了28.30%（最后）的空间，
    • 两个Survivor区（S0、S1，表示Survivor0、Survivor1）分别是0和8.93%，
    • 老年代（O，表示Old）使用了87.33%。
      • 程序运行以来共发生Minor GC（YGC，表示Young GC）101次，总耗时1.961秒，
      • 发生Full GC（FGC，表示Full GC）7次，Full GC总耗时3.022秒，
      • 总的耗时（GCT，表示GC Time）为4.983秒。
• jmap -histo:live 20954
  • live 是可选参数，表明存活的对象
  • 红线部分：
    • 能够看出HashTable中的元素有5000多万，占用内存大约1.5G的样子。这确定不正常。

• MAT 分析工具

  • 补充jmap在线分析

    • jmap比较笼统，明显的问题能检查出来

  • 修改MAT配置

    • MemoryAnalyzer.ini文件
    • Xmx参数，该参数表示最大内存占用量，默认为1024m
  • 从jmap获取 .hprof 文件
    • jmap -dump:format=b,file=<dumpfile.hprof> <pid>
  • 选择Leak Suspects Report, Finish就能够进入MAT分析页面的首页
  • 在首页上比较有用的是Histogram和Leak Suspects
  • 点击Leak Suspects会在堆转储文件同目录内生成一个Leak Suspects.zip文件，
    • 同时也会从首页跳转到Leak Suspects页面
  • 解压该文件后能够经过浏览器打开分析结果
  • Leak Suspects页面
    • 从中找你熟悉的代码
  • 点击Details进入详情页面
    • Shortest Paths To the Accumulation Point表示GC root到内存消耗汇集点的最短路径
    • All Accumulated Objects by Class列举了该对象所存储的全部内容
    • 为了找到内存泄露，我获取了两个堆转储文件，两个文件获取时间间隔是一天
      • 对比两个文件的对象，经过对比后的结果能够很方便定位内存泄露。
      • MAT同时打开两个堆转储文件，分别打开Histogram
      • 在下图中方框1按钮用于对比两个Histogram，对比后在方框2处选择Group By package，而后对比各对象的变化
      • -64的意思是，俩文件中该对象比对，前者比后者少了64个
      • 我内存泄露位置是一个list，这个list只在这里一直不停的往里添加eventInfo对象，却没有释放过。