三万字长文：JVM内存问题排查Cookbook
一、Heap快照
# jmap命令保存整个Java堆（在你dump的时间不是事故发生点的时候尤其推荐）
jmap -dump:format=b,file=heap.bin <pid>
# jmap命令只保存Java堆中的存活对象, 包含live选项，会在堆转储前执行一次Full GC
jmap -dump:live,format=b,file=heap.bin <pid>
# jcmd命令保存整个Java堆,Jdk1.7后有效
jcmd <pid> GC.heap_dump filename=heap.bin
# 在出现OutOfMemoryError的时候JVM自动生成（推荐）节点剩余内存不足heapdump会生成失败
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.bin
# 编程的方式生成
使用HotSpotDiagnosticMXBean.dumpHeap()方法
# 在出现Full GC前后JVM自动生成，本地快速调试可用
-XX:+HeapDumpBeforeFullGC或 -XX:+HeapDumpAfterFullGC二、GC日志
# Java8及以下
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:<path>
# Java9及以上
-Xlog:gc*:<path>:time三、内存栈生成
# jstack生成，推荐
jstack <pid> > jstack.log
# jcmd生成
jcmd <pid> Thread.print > jstack.log 四、系统日志
sudo dmesg|grep -i kill|less
或者
grep /var/log/kern.log* -ie kill
五、类加载相关
# 显示指定进程的类加载器相关的统计信息
jmap -clstats <pid> :
# 监视类加载器的行为，包括加载、卸载的类的数量以及相关的内存消耗。
jstat -class <pid>
# 统计在JVM的类加载中，每一个类的实例数量，并按照数量降序排列。
jcmd <pid> GC.class_stats|awk '{print$13}'|sed 's/\(.*\)\.\(.*\)/\1/g'|sort |uniq -c|sort -nrk1
# arthas的classloader命令玩法比较多，有一定学习成本
arthas的classloader命令在调试环境中添加VM参数(在生产环境请谨慎！！！)
# 用于同时跟踪类的加载和卸载
-verbose:class
# 单独跟踪类的加载
-XX:+TraceClassLoading
# 单独跟踪类的卸载
-XX:+TraceClassUnloading六、堆外内存排查
top发现JAVA实际占用的RES 甚至超过了 -Xmx 的大小，内存使用率不断上升，甚至开始使用 SWAP 内存，同时可能出现 GC 时间飙升，线程被 Block 等现象
# 在项目中添加 JVM参数后重启项目（需要注意的是，打开 NMT 会带来 5%~10% 的性能损耗）
-XX:NativeMemoryTracking=detail
# 查看内存分布
jcmd pid VM.native_memory detail
重点观察 total 中的 committed，因为 jcmd 命令显示的内存包含堆内内存、Code 区域，
通过 Unsafe.allocateMemory 和 DirectByteBuffer 申请的内存，
但是不包含其他 Native Code（C 代码）申请的堆外内存。
如果 total 中的 committed 和 top 中的 RES 相差不大，
则应为主动申请的Direct Memory未释放造成的。
