jvm程序执行慢诊断手册，kafka面试题零拷贝

内存使用率过高或者没有系统资源占用过高

jmap -dump:format=b,file=heapdump.bin pid

这里必须打dump的原因是res过高，可能出发系统的oom killer，进程可能被系统杀死，此时不获取，可能进程就会被杀死了。如果不是系统资源问题，堆dump以后也是要用的。

堆占用查看

jstat -gc -h 10 pid 1000

jstat -gcutil -h 10 pid 1000

jstat -gccause -h 10 pid 1000

这里一般是开三个窗口对比看数据的。-gc主要是关注堆的分区总大小。-gcutil主要是关注已使用的百分比。-gccause主要是关注fgc次数，时间以及gc原因。

内存问题的分类就比较多了，造成问题的卡顿的根本其实是gc问题。stw的时候虚拟机停顿了，导致反应不过来了。

问题：堆内存占用空间接近满

这种情况就利用mat去查看dump分析吧，可能出现内存使用不合理或者内存泄漏，这里需要根据代码来分析。

问题：perm,metaspace占用接近满

jps -lvm

查看一下jvm参数设置，很可能是参数设置不合理，-XX:MetaspaceSize是发生gc的最小空间，这里是不是设置太小。MaxMetaspaceSize，MaxPermSize的值是否设置太小。java6如果设置都不小而且还占满了，那就得检测代码里是不是在运行时常量池加了字符串。1.7，1.8就考虑是不是业务用了什么字节码生成技术，动态做了一些字节码操作。

问题：system.gc()

gccause查看gc的原因是system.gc()。需要检测是否用了rmi,使用了直接内存，或者业务代码调用了system.gc()。直接内存查看现在没有现成的工具。可以使用我在github上放着的小工具查看。地址如下https://github.com/xpbob/jstatassist

问题：gc频繁但不是system.gc()

空间都不是特别紧张，但是gc次数频繁，并且不是system.gc()。那可能就是gc参数设置不对了，例如cms，老年代回收是一个2秒一次的轮训操作，很有可能是现在的空间占用每次都是满足gc的条件的，于是出现了这种情况。

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）
[外链图片转存中…(img-AKN8n1rD-1710829728523)]