没有监控过JVM内存的职场生涯，是不完美的

缺乏、安全感 2023-01-13 09:54 140阅读 0赞

### 前言 ###

如果你从事Java开发多年，还没用过JVM分析工具，还没尝试着通过对JVM的dump日志来进行故障定位和性能调优，那么可以说是你职场生涯中的一大遗憾，也是一种能力的缺失。

这篇文章就基于一款JDK自带的工具（VisualVM），然后编写内存溢出的案例，带大家体验一下JVM分析的入门。文中涉及到多个知识点的融合与实战经验分享，读者可留意一下。

### VisualVM简介 ###

VisualVM是Netbeans的profile子项目，在JDK6.0 update 7 中自带，能够监控线程，内存情况，查看方法的CPU时间和内存中的对象，已被GC的对象，反向查看分配的堆栈(如100个String对象分别由哪几个对象分配出来的)。

如果已经正确配置classpath路径，VisualVM的启动非常简单，只需在命令行输入jvisualvm即可启动图形化界面。VisualVM不仅支持本机监控，还支持远程监控。

远程监控配置稍微复杂一些，这里以本地监控为示例进行演示。至于生产环境，可选择远程监控，也可配合jmap先生成dump文件，然后下载dump文件进行分析。

### VisualVM功能界面 ###

启动VisualVM之后，先来看一下有助于JVM分析的几项功能。这里先以本地启动的Idea为例来进行展示。

#### 概述 ####

进入VisualVM之后，点击左边的对应进程，首先展示的是【概述】内容：  
![在这里插入图片描述][5840207df0db7e078251ce05ceb49d25.png_pic_center]

概述中显示了JVM、Java版本、dump批次等信息，在实战中这里的信息可用来进行信息核对。特别是JVM从参数和系统属性项的核对。

曾遇到一个场景，就是通过启动Java程序时JVM参数的位置写错了，导致JVM参数并不生效。

比如如下指令，由于JVM的参数写在了最后，会导致参数设置无效。

java -jar app.jar -Xms256m -Xmx512m

而正确的写法应该是如下：

java -Xms256m -Xmx512m  -jar app.jar

上面这种情况，通过该工具可以轻易的看出JVM参数项里面并没有指定的参数值。

#### 监视 ####

监视界面是用的比较多的一个界面，通过该界面可以查看CPU使用情况、堆和Metaspace的使用情况、线程的使用情况、类的加载情况等。

通过对堆和Metaspace的使用情况分析，可以看到对应内存空间的使用和增长情况，可进行合理调整和规划。  
![在这里插入图片描述][f74e297ad6a96d37e983818fa6bb7ff2.png_pic_center]

点击右上角的“堆 dump”，会基于点击的时间节点生成dump文件。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center]

概要部分会显示生成dump文件的时间节点和存储路径。我们用来分析内存主要是在此页面中的“类”菜单内。

![在这里插入图片描述][44f69af99849c38d268a38efb3879c5a.png_pic_center]

进入可查看在堆中不同实例占用的内存大小。双击类名，即可进入查看“实例数”，也就是具体类的实例详情。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 1]

而我们在内存分析时最重要的其实就是“类”的数量。在了解了上述的基本操作之后，我们就用一个实例来模拟分析一下内存溢出的场景吧。

### 内存溢出场景构建 ###

先写一段代码，用来模拟内存溢出，也就是创建一个Map，然后向其中不断的新增对象。同时在程序处理的过程中让线程睡眠或死循环来方便通过VisualVM进行查看。

测试代码如下：

public class MemoryLeakTest {
    
        /**
         * 声明缓存对象
         */
        private static final Map<String, TestMemory> CACHE_MAP = new HashMap<>();
    
        public static void main(String[] args) {
            try {
                //给打开visualVm时间
                Thread.sleep(10000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            //循环添加对象到缓存
            for (int i = 0; i < 1000000; i++) {
                TestMemory t = new TestMemory();
                CACHE_MAP.put("key" + i, t);
            }
            System.out.println("-------1------");
            //为dump出堆提供时间
            try {
                //给打开visualVm时间
                Thread.sleep(10000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
    
            for(int i=0; i<1000000;i++){
                TestMemory t = new TestMemory();
                CACHE_MAP.put("key"+i,t);
            }
        }
    }

TestMemory类代表生成中的业务类。

public class TestMemory {
    }

为了让程序更快的达到内存的阈值，我们启动时可限制JVM的大小，这里设置为：

-Xms128m -Xmx128m

另外，为了分析堆的内存结构中每个区域（新生代、老年代）的内存使用情况，可在VisualVM的“工具”、“插件”中安装Visual GC插件。该插件的使用后续会看到效果。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 2]

一切准备妥当，下面来进行验证。

### 内存溢出分析 ###

下面我们就来启动程序，启动VisualVM来进行内存溢出的分析。

当程序执行的过程中，我们会发现“堆”内存会出现一个快速增加的曲线。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 3]

这个过程中Metaspace也在随之增长。

打开Visual GC界面，我们会看到面试中被问过很多遍的堆内存结构：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 4]

通过这张图，可以直观的看到堆内存中的老年代、新生代、Metaspace空间（JDK8），还有新生代中的Eden、S0(Survivor From)、S1(Survivor To)，而且它们的分配比例也有一个比较直观的展示。通过这种形式，是不是可以更直观的学习堆内存结构呢？

这里Eden已经被填满、S0和S1为空，老年代也几乎被填满（因为垃圾收集无法清除持有引用的对象）。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 5]

最重要的是你会发现针对老年代在20分钟内进行了3850次垃圾回收。也就是说已经触发了频繁的Full GC操作，而且内存并没有被释放掉。在生产系统中，当你看到系统在频繁的进行Full GC操作，那是JVM在释放一个很恐怖的信号了。

上面说了一些表象的内容，现在真正开进行内存分析了。回到上面提到的“监视”、“堆dump”、“类”中，可以看到下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 6]

可以看到，堆中存在着100万个TestMemory对象。当你看到堆中有类似的大量的对象存在，你应该意识到此处可能有内存泄露。也就是大量的对象被创建，而没有被“顺利”回收。我们这里没被回收的原因是对象被放在了静态变量里面了。

上面已经提到，你还可以进一步双击对象名称，去查看对象的详细信息。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 7]

通过上面步骤，基本上可以定位到哪些对象的处理出现了问题，此时再回到代码中针对相应的代码进行排查，便可快速定位内存溢出的问题所在。其中我们需要特别留意上述过程中VisualVM为我们提供的那些报警信号和数据呈现。

### 小结 ###

本文我们是在讲VisualVM的使用，也是在讲线上JVM的排查，也是在讲JVM的内存结构，还是在讲如何去构造一个内存溢出（bug）的场景。但讲什么并不重要，关键是看，通过这篇文章，你重温了什么，学到了什么，又收获了什么。

### JVM系列 ###

最近还写了一系列JVM相关的文章，值得学习一下。

《[GC复制存活对象，它内存地址变了么？][GC]》

《[GC时对象地址变了，hashCode如何保持不变？][GC_hashCode]》

--------------------

**程序新视界**  
公众号“ **程序新视界**”，一个让你软实力、硬技术同步提升的平台，提供海量资料

![微信公众号：程序新视界][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 8]

[5840207df0db7e078251ce05ceb49d25.png_pic_center]: /images/20221022/08cc8508f32f4298a46a436c07f3779e.png
[f74e297ad6a96d37e983818fa6bb7ff2.png_pic_center]: /images/20221022/88ba3a13a7ba44e98788d38aa150ab19.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center]: /images/20221022/349a4b2da80a46afa5dd0ac6f224f1a0.png
[44f69af99849c38d268a38efb3879c5a.png_pic_center]: /images/20221022/346cbf7efc8840f18276e73b902b6aa5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221022/ead61105bfac4d5e8048ec3b28e37d1b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221022/5f7375b5e28243a7be5e9ee9f3744ec5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221022/6dcfa52bb65d463e964b2f892cdaba4d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221022/23f361fd09cb40d384f39f25f73fea6f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221022/14c27912737a48998d4fdace1621d4c5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221022/a99347c2c6804953810f2c34f5b0cbc5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221022/69532353b1a84392b9e1d92f628b566b.png
[GC]: https://mp.weixin.qq.com/s/rKEdTxXIc8F8ZwGW-hTakg
[GC_hashCode]: https://mp.weixin.qq.com/s/30X-PBHHQtAlqEmopR7U5w
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center 8]: /images/20221022/80007292c1f744f7b52679b57dea049e.png