4核的服务器突然很卡，急忙跑上去看看发生了什么事。
top命令查看
占用率最高的进程pid为12033，top -Hp 12033查看进程下面线程的使用情况
这俩罪魁祸首用的最多
jstack 12033 > check.txt查看进程的堆栈信息，输出到文件后，通过线程的16进制看看在干啥
printf "%x\n" 12035打印16进制，然后在check.txt里面进行搜索0x2f03
GC task
可以执行jstat -gcutil 进程号 统计间隔毫秒 统计次数（缺省代表一致统计），查看某进程GC持续变化情况，如果发现返回中FGC很大且一直增大-》确认Full GC!
也可以执行jmap -heap 12033查看进程的堆内存信息
这个Old Gen老年代已经满了，就会进行Full GC，需对整个堆进行扫描和回收，十分耗时，估计就问题就在这，一直在Full GC
jmap -dump:format=b,file=filename 12033导出进程下内存heap输出到文件中，搞了个1000多兆的文件。。。二进制文件，less 命令查看不了，得用分析工具分析，比如jhat、MAT
这个命令执行，JVM会将整个heap的信息dump写入到一个文件，heap如果比较大的话，就会导致这个过程比较耗时，并且执行的过程中为了保证dump的信息是可靠的，所以会暂停应用， 线上系统慎用。
下载MAT需要选择一个合适的版本，和本地jdk版本有关。下了个最新的需要jdk11以上。。只能下个旧点的。
解压 -> 启动 -> 打开二进制文件
参考：https://blog.csdn.net/pengjunlee/article/details/107150785
https://lihuimintu.github.io/2019/10/24/jmap/
https://blog.csdn.net/Jin_Kwok/article/details/80326088
