JAVA应用生产问题排查步骤( 五 )


JAVA应用生产问题排查步骤

文章插图
 
注意:执行该命令的时候会将整个JVM上面的所有线程都暂停,如果你的java堆比较大,比如有10个G左右,那暂停的时间可能比较长 , 有可能长达10分钟,所以在生产环境慎用这个命令 。或者在生产环境 , 先让运维把请求都先负载到别的机器上面 , 再执行这个命令 。
执行完成后在当前目录就会产生一个9739_jvm_heap.hprof 的文件
JAVA应用生产问题排查步骤

文章插图
 
jmap -dump: live ,format=b,file=heapLive.hprof 9739 如果带上live会先触发一次GC,GC完则只转存储活着的对象 。
然后 , 这个文件是二进制的文件,人肯定是看不懂的 。所以 , 需要借助分析dump文件的工具 , 可以使用工具来分析:
  • 国内PerfMa社区的XElephant在线工具网站为 https://console.perfma.com/  ,  https://memory.console.perfma.com/

JAVA应用生产问题排查步骤

文章插图
 

JAVA应用生产问题排查步骤

文章插图
 
  • GCeasy
网站为 https://gceasy.io/
JAVA应用生产问题排查步骤

文章插图
 
  • Memory Analyzer (MAT)
网站为
https://www.eclipse.org/mat/
JAVA应用生产问题排查步骤

文章插图
 
MAT这个工具有一个MemoryAnalyzer.ini配置文件:找到MemoryAnalyzer.ini文件 , 该文件里面有个Xmx参数 , 该参数表示最大内存占用量 , 默认为1024m , 根据堆转储文件大小修改该参数即可 。MAT工具要求dump文件的后缀名以.hprof结尾 。B站 PerfMa up主 JVM字节码的探索与实践应用(第一期)直播回放 在第56秒说:如果dump文件太大,MAT也会打不开 。
JAVA应用生产问题排查步骤

文章插图
 
至于这些分析JAVA dump文件的工具怎么用 , 你们可以自己去Google一下 , 我后面也会再写一篇关于这些工具的教程 。不过有一点需要注意,如果你dump出来的文件很大,那么上面的工具就都不管用了,比如说你dump出来的文件大小为10G,这么大的文件上面的工具想打开一个10G的文件也非常困难了 。要知道分析dump文件的工具本身也是一个APP,这个APP要分析这个10G的dump文件也需要把这个10个G的文件加载到自己的内存中去,10G他肯定是不好加载的 。这个时候你只能使用 jmap -histo 32924 | head -n 60 这个命令手动来查看堆内存上面什么对象最多了,这个命令的截图如下:
JAVA应用生产问题排查步骤

文章插图
 
如果你发现这个命令的结果里面有你熟悉的类,那很大可能就是你项目中这个类的对象生成的太多了,并且使用完之后没有释放造成了内存泄漏,是有可能并不是绝对的,这个只能当线索去分析,不能当证据去使用 。
如果你要看jmap -histo 32924这个命令的全部结果,可以使用jmap -histo 32924 > /tmp/java_heap_32924.txt这个命令,将命令的结果保存到文件中,然后将文件下载到本地查看 。
这块知识来自 网络上的大神:Hollis Java命令学习系列(三)——Jmap
博客园上面的大神:星朝 JVM性能调优实践——JVM篇
HeapDump社区上面的大神Coder的技术之路 高并发服务优化篇:详解一次由读写锁引起的内存泄漏
HeapDump社区上面的大神:Java小能手 记一次线上服务CPU 100%的处理过程
6. JAVA自带命令–jstack,查看JVM内所有的线程运行情况jstack这个命令在JDK的安装目录bin/下面
JAVA应用生产问题排查步骤

文章插图
 
这个命令也比较简单 , 没啥好讲的 ,  但是非常重要 , 分析问题时超级有用 。 命令就是jstack -l JVMPID就行了 。这个命令配合我们前面讲的 top -Hp 19235 命令和 printf将线程ID转换成16进制 printf “0x%xn” 19235 ,能非常快速定位JAVA程序中运行卡顿和缓慢的性能问题 。
jstack -l 9739
JAVA应用生产问题排查步骤

文章插图
 
jstack -l 9739 > /tmp/9739_jvm_thread.dump将jstack -l 9739的命令的全部输出结果都保存到文件里面去 , 然后再下载的本地或者网上去分析 。


推荐阅读