使用JMC或VisualVM进行CPU和内存分析

淩亂°似流年 2022-01-26 19:19 252阅读 0赞

我们可以通过 VisualVM 的监视标签和 Profiler 标签对应用程序进行 CPU 性能分析。

**一. 先看监视标签**

在监视标签内，我们可以查看 CPU 的使用率以及垃圾回收活动对性能的影响。在程序刚启动时，CPU usage达到了最高的50.5%。在其他时候，过高的 CPU 使用率可能是由于我们的轨道系统构建中中存在低效的代码，整体上看，垃圾回收活动并不频繁，没有占用了较高的 CPU 资源。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyMTg3NA_size_16_color_FFFFFF_t_70][]

**二. 再看CPU profiler标签**

在CPU 性能分析profiler标签 ,VisualVM 会检测应用程序所有的被调用的方法。当进入一个方法时，线程会发出一个“method entry”的事件，当退出方法时同样会发出一个“method exit”的事件，这些事件都包含了时间戳。然后 VisualVM 会把每个被调用方法的总的执行时间和调用的次数按照运行时长展示出来。

Self time：我们按照Total Time进行排序之后，发现排在第一的是Self time，这个其实对于我们不重要，解释起来，Self time是在方法本身花费的挂钟时间（包括等待/休眠的时间），它是时间处理器时间，因此它不包括等待，睡眠等所花费的时间。

circularorbit.StellarSystem.readFile (String)：对于方法执行的时间，不出所料，耗时最长的是readFile，它主要运行的时间不是在读入一篇txt文件，这个只需要几百ms，而是在将物体添加到轨道上并且根据半径进行排序。简单地说就是通过读入的文件搭建轨道是个漫长的过程。

circularorbit.ConcreteCircularOrbit.removeTrack (track.Track)：移除一条轨道也需要花费不少的时间，因为我们需要先移除轨道上的物体，然后再删除轨道

fileoutput.StellarSystemBufferWriter.writeFile (String, circularorbit.CircularOrbit)：写文件运行所需要的时间也在考虑之中，毕竟有几十万行的数据。

其他方法：主要花费的时间在于没有优化彻底的查找方案，比如获得一个物体的某个属性，需要去set中遍历，造成了不少的时间消耗；另外在控制台的打印，写入日志文件也是需要一定时间的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyMTg3NA_size_16_color_FFFFFF_t_70 1][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyMTg3NA_size_16_color_FFFFFF_t_70 2][]

1.  1.  1.  使用VisualVM进行Memory profiling

**一. 监视标签**

在监视标签内，我们可以看到实时的应用程序内存堆以及Metaspace区域的使用情况。

我们可以看出，由于构建的对象较多，内存的heap的使用率也是比较高的

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyMTg3NA_size_16_color_FFFFFF_t_70 3][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyMTg3NA_size_16_color_FFFFFF_t_70 4][]

**二. memory profiler**

本以为memory profiler运行起来和CPU profiler一样，可是同样的操作却一直报错，或者就是已经在运行，却一直不显示活动的分配对象。

后来的处理方式是以管理员身份运行cmd，此时打开java visualvm，问题才得以解决。

![2019052917423972.png][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyMTg3NA_size_16_color_FFFFFF_t_70 5][]

分析：

通常考虑，字符串对象中就有一个 char\[\]数组，其他对象中也可能封装char\[\]数组，先检查一下String对象有多少个，算上其他可能封装char\[\]数组的对象，也差不多这个数值了。

同理int\[\]和byte\[\]也是这个原因占用了很多内存。

但是事实上我们更应关注自己所创建的实例，因为我们解析的时候不断创建字符串，因此String对象毫无疑问有很多。从源码上来看,HashSet实际上为(key,null)类型的HashMap,因此我们使用hashset后会存在很多java.util.HashMap$Node\[\]。

其余的内存占用居前的类型就很好理解了，因为Planet、track等正是我们构建轨道一直在使用的类型。

总体分析，这些耗费内存最多类型的执行正常。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyMTg3NA_size_16_color_FFFFFF_t_70]: /images/20220126/b9fadf0b1b2e4fb6aca388d0a38fe367.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyMTg3NA_size_16_color_FFFFFF_t_70 1]: /images/20220126/3d9f0728d43f42b5a340ffae4089ccc9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyMTg3NA_size_16_color_FFFFFF_t_70 2]: /images/20220126/177372771a6c48638c5e772aba23bf18.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyMTg3NA_size_16_color_FFFFFF_t_70 3]: /images/20220126/c10fb192a34448ed99ad204c1f48acdf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyMTg3NA_size_16_color_FFFFFF_t_70 4]: /images/20220126/76a782ec51dd47fa8ae685df15d2ae4e.png
[2019052917423972.png]: /images/20220126/c22ad85cf3ce48d19479d9b950baa399.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyMTg3NA_size_16_color_FFFFFF_t_70 5]: /images/20220126/b9a2c3fc43d84262bb55411fd2af5681.png