内存溢出分析定位

内存溢出：

• 堆内存溢出

堆内存中存在大量对象，这些对象都有被引用，当所有对象占用空间达到堆内存的最大值，
就会出现内存溢出OutOfMemory:Java heap space

• 永久代溢出 -- (解决方案：加大永久代内存)

类的一些信息，如类名、访问修饰符、字段描述、方法描述等，所占空间大于永久代最大
值，就会出现OutOfMemoryError:PermGen space

内存溢出的检测方法

1、Jdk/bin目录下有很多检测工具

• 图形界面：
  – Jconsole
  – Jvisualvm（也可以监控线程）

• 命令行工具
  –Jstat –gcutil pid 1000 100 查看GC情况
  -Jmap –histo pid | head -20 查看当前jvm中占用内存最大的20个类
  -Jmap –heap pid

FullGC频率：建议单次FullGC时间<200ms，超出则存在优化空间

2、现象

2.1 垃圾回收和CPU使用率

1、两条曲线的走势完美吻合，每一次GC，CPU使用率都会升高，请求响应时间变长
2、有时候CPU使用率波动特别大，有可能正在进行 GC
3、响应时间波动特别大、TPS波动也特别大，系统有可能在进行 GC，需要排查

2.2 内存泄漏和TPS

1、TPS开始有波动，然后波动越来越大，最后陡降至0

内存溢出实战

怎么排查：

• 1、观察现象：tps先是出现大幅波动，后慢慢降低。甚至将为0，响应时间随之波动，慢慢升高
• 2、通过 jstat -gcutil pid 1000 100命令可以观察到 Jvm中的Old区不断增加，FGC（FullGC）非常频繁，对应FGCT（FullGC需要的时间）消耗的时间也不短增加
• 3、通过 jconsole/jvisualvm 可以看到，堆内存曲线不断上升，接近上线时，变成一条直线，就算压测结束很久后，内存仍然降不下来
• 3、日志报错 java.lang.OutOfMemoryError:Java heap space
• 4、通过 Jmap –histo pid | head -20 查看当前jvm堆内存中实例数和占用内存最多的前20个对象或类
• 5、也可以通过jvisualvm，进行远程堆dump，然后把dump文件下载下来，用jvisualvm打开进行分析，可以看到更直观的jvm中对象的信息

查看Jvm运行状态的命令

监控jvm的GC情况
jstat -gcutil pid 1000 100

查看jvm配置信息
jmap -heap pid：可以看到java进程的堆的配置信息，各区的空间大小和配置信息

查看jvm中类和对象的占用情况
jmap -histo 5279 | head -20：查看jvm中各个类的实例数、占用内存数量以及类的全名

堆文件dump
jmap -dump:format=b,file=m.hdump 17777：对堆内存进行dump，以文件的形式进行保存下来，可以用jvisualvm等工具对文件进行分析

内存泄露应用场景

在什么样的场景下监控内存泄露问题？

• 1、在试压阶段，或任意场景都可以考虑通过jvisualvm和jstat监控jvm的情况
• 2、在稳定性场景中，一定要关注Jvm内存使用的情况，在长时间的压测下，最容易看出内存泄露的问题

JVM常见参数

-Xms2048m：初始堆大小，建议<物理内存的1/4，默认值为物理内存的1/64
-Xmx2048m：最大堆大小，建议与-Xms保持一致，默认值为物理内存的1/4
-Xmn512m：新生代大小，建议不超过堆内存的1/2
-Xss256k,线程堆栈大小，建议512-1024k
-XX:PermSize=256m：永久代初始值，默认值为物理内存的1/64
-XX:MaxPermSize=256m：永久代最大值，默认值为物理内存的1/4
-XX:SurvivorRatio=8：年轻带中Eden区和Survivor区的比例，默认为8:1，即Eden（8），From
Space（1），ToSpace（1）
-XX:MaxTenuringThreshold=15：晋升到老年代的对象年龄，每个对象坚持过一次MinorGC后对象年龄+1，默认值是15，年龄超过15进入到老年代，该参数在串行GC时有效-
XX:PretenureSizeThreshold=3145728：单位字节，只对Serial和ParNew两款收集器有效，新生代采用Parallel Scavenge GC时无效，大于这个值的对象直接在老年代进行分配

CMS相关参数

-XX:+UseConcMarkSweepGC：默认关闭，ParNew+CMS+Serial Old，当CMS收集器出现
ConcurrentModeFailure错误（Jvm预留空间不足以容纳程序使用），采用后备收集器Serial Old
-XX:CMSInitiatingOccupancyFraction=80：CMS收集器在老年代空间被使用多少时触发FullGC，默认为92
-XX:+UseCMSCompactAtFullCollection：CMS收集器在FullGC时开启内存碎片的压缩，默认关闭
-XX:CMSFullGCsBeforeCompaction=8：执行多少次不压缩FullGC后，进行一次压缩，默认是0（代表每次FullGC都进行压缩）
-XX:+UseCMSInitiatingOccupancyOnly：使用手动定义初始化定义开始，禁止hostspot自行触发CMS GC
-XX:ParallelGCThreads=8：并行收集器的线程数，此值最好配置与处理器数目相等 同样适用于CMS

日志参数：

-XX:+HeapDumpOnOutOfMemoryError：当发生内存溢出时，进行堆内存dump
-XX:+PrintGCDetails：打印GC的详细信息

企业实际测试环境配置

-server -Xms1028m -Xmx1028m -XX:PermSize=256m -XX:MaxPermSize=256m -Xmn512m
-XX:MaxDirectMemorySize=1g -XX:SurvivorRatio=10 -XX:+UseConcMarkSweepGC
-XX:+UseCMSCompactAtFullCollection -XX:CMSMaxAbortablePrecleanTime=5000
-XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80
-XX:+UseCMSInitiatingOccupancyOnly -XX:ParallelGCThreads=8
-Xloggc:/home/admin/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/admin/logs/java.hprof