java线上问题排查之内存分析（三）

java线上问题排查之内存分析

1. 使用top命令
   top命令显示的结果列表中，会看到%MEM这一列，这里可以看到你的进程可能对内存的使用率特别高。以查看正在运行的进程和系统负载信息，包括cpu负载、内存使用、各个进程所占系统资源等。
   
   2.用jstat命令
   jstat -gcutil 30 1000 10命令，就是用jstat工具，对指定java进程（30就是进程id，通过ps -aux | grep java命令就能找到），按照指定间隔，看一下统计信息，这里会每隔一段时间显示一下，包括新生代的两个S0、s1区、Eden区，以及老年代的内存使用率，还有young gc以及full gc的次数。
   使用 jstat -gcutil 30 500 5 表示每500毫秒打印一次Java堆状况（各个区的容量、使用容量、gc时间等信息），打印5次
   

S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
0.00 0.00 100.00 99.94 90.56 87.86 875 9.307 3223 5313.139 5322.446

S0：幸存1区当前使用比例
S1：幸存2区当前使用比例
E：Eden Space（伊甸园）区使用比例
O：Old Gen（老年代）使用比例
M：元数据区使用比例
CCS：压缩使用比例
YGC：年轻代垃圾回收次数
YGCT：年轻代垃圾回收消耗时间
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间

看到的东西类似下面那样：

  S0   S1    E    O     YGC FGC
26.80 0.00 10.50 89.90  86  954

老年代Full GC回收次数大于年轻代GC次数，就肯定是有问题的。
所以jstat先看一下基本情况，马上就能看出来，其实就是大量对象没法回收，一直在内存里占据着，然后就差不多内存快爆了。

3. 使用jmap命令查看
   执行jmap -histo pid可以打印出当前堆中所有每个类的实例数量和内存占用，如下，class name是每个类的类名（[B是byte类型，[C是char类型，[I是int类型），bytes是这个类的所有示例占用内存大小，instances是这个类的实例数量。

jmap -histo 1 | head -20 #查看占用内存最大的前20个对象

4. 把当前堆内存的快照转储到dumpfile_jmap.hprof文件中，然后可以对内存快照进行分析
   使用jmap -dump:format=b,file=文件名 [pid]，就可以把指定java进程的堆内存快照搞到一个指定的文件里去，但是jmap -dump:format其实一般会比较慢一些，也可以用gcore 或者是 arthas工具来导出内存快照
   示例：

jmap -dump:format=b,file=D:/log/jvm/dumpfile_jmap.hprof 30

接着就是可以用MAT工具，或者是Eclipse MAT的内存分析插件，来对hprof文件进行分析。
注意：使用jdk自带的jvisualvm分析，效果不理想，建议使用MAT 或者是 Jprofiler。这里我们使用MAT分析

5. 总结：

• 一般常见的OOM，要么是短时间内涌入大量的对象，导致你的系统根本支持不住，此时你可以考虑优化代码，或者是加机器；要么是长时间来看，你的很多对象不用了但是还被引用，就是内存泄露了，你也是优化代码就好了；这就会导致大量的对象不断进入老年代，然后频繁full gc之后始终没法回收，就撑爆了
• 要么是加载的类过多，导致class在永久代理保存的过多，始终无法释放，就会撑爆
• 线上jvm必须配置-XX:+HeapDumpOnOutOfMemoryError，-XX:HeapDumpPath=/path/heap/dump。因为这样就是说OOM的时候自动导出一份内存快照，你就可以分析发生OOM时的内存快照了，到底是哪里出现的问题。

如果有人问你有没有处理过线上的问题，你就说有，最简单的，你说有个小伙子用了本地缓存，就放map里，结果没控制map大小，可以无限扩容，最终导致内存爆了，后来解决方案就是用了一个ehcache框架，自动LRU清理掉旧数据，控制内存占用就好了。