【无标题】

JDK自带工具分析内存

• 前言
• • JDK版本
  • 问题背景
  • 问题定位
• 后语

前言

本来就是一个很懒的人，JDK自带工具分析的文章也很多，不讲工具使用，记载一下分析过程。

JDK版本

Sun公司诞生以来，估计就有这些工具，后来BEA的weblogic集成过jconsole,后来被Oracle收购以后，可视化的工具就变成了原始的命令行或者exe,本文仅仅针对RHL+Oracle JDK,其他的JDK因为技术能力有限没有用过这些命令（十分可怜，要不是混工资生存，谁搞IT？）。
还有重要提醒，本文无图，在云中工作就是没办法的事情，没法截图给大家！如果是新手可以早点走开，别浪费您宝贵时间，本人也是不严谨的技术员+罗嗦鬼。

问题背景

使用LoadRunner工具对某微服务接口压测，TPS提升不上去，而且并发用户增加到40以后就不能继续增加，报Fail错误且没有Error信息，微服务网关，应用服务器CPU使用100%,内存使用正常不超过40%，磁盘空间足够，磁盘IO和网络IO也不是很忙。按照经验来看，这样肯定不正常，需要定位问题。

问题定位

既然系统资源都还可以，按照经验盲猜JVM可能有问题，趁他病要他命，再来电压力继续加压，看能不能爆出OutOfMemery日志？LoadRunner继续工作两小时，吃完午饭休息一下再来看。结果让人失望，啥报错日志也没有，不能坐以待毙，拿出我们的各种工具看看咯！

1. TOP工具

首先使用TOP -H -p工具看看应用服务器最耗资源的PID以及User,毫无疑问就是那个JAVA程序。

2. JPS工具

然后使用JPS -lvp看下是不是我们微服务的JAVA干的？比对了一下身份z，PID相同，看样子没有抓错人（Java程序）。

3. Jinfo工具

使用jinfo -flags PID查看了一下JVM设置是min 2G到max 4G的，目前已经扩展到4G了，非常接近。要说内存泄漏吧，又不报OOM?继续往下追查吧！

4. Jstat工具

使用Jstat -gcutil pid 1000查看一下GC,为什么不给力？结果FGC疯狂回收，FGCT时间也越来越长，什么东西会导致GC次数这么多，而且GCT变长？一般是得不到的永远在冲动，估计有什么心仪的大对象（large project），想回收而回收不了？

5. Jstack工具
   既然有怀疑，当然还得求证，看看这些JAVA线程到底在干什么？所以需要使用jstack pid >aaa.dump,多打印几遍看看他们到底在干啥？使用TOP -H得到的线程号，printf “%xn” 十进制线程ID得到16进制的线程ID,然后查找这些线程在内存里面的状态。一查看全在GC,系统CPU资源难怪这么高，都在干这个。JVM没有OOM,但是又在疯狂GC。大对象回收不回去，年轻人又要吃饭，急死了CPU这个当家的。

6. Jmap工具
   继续猜测是大对象的方向，使用jmap -histo |grep alibaba|sort -k 3 -g -r|less，排序一下内存对象，发现是个char[]，这就让我很为难，怎么定位是那个char[]？推荐使用MAT工具分析dump,使用tree view查看大对象，然后查看具体程序信息，然后把bug扔给开发去解决吧！MAT工具使用链接：https://blog.csdn.net/frwcode/article/details/106197713,很详细的。

后语

其实很早就想写一个这样的blog,不知道为什么，现在的工具居然越来越原始了，以前我们都是使用jprofiler,这种性能问题分分钟搞定，效果很明显，有界面很亲切。但是原始工具，可以让我们更接近原理而已，人老了都喜欢怀念青春。