|
|
|
|
公众号矩阵

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

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

作者: 丑胖侠二师兄 来源: 程序新视界|2021-04-16 20:40

本文转载自微信公众号「程序新视界」,作者丑胖侠二师兄。转载本文请联系程序新视界公众号。

前言

如果你从事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之后,点击左边的对应进程,首先展示的是【概述】内容:

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

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

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

  1. java -jar app.jar -Xms256m -Xmx512m 

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

  1. java -Xms256m -Xmx512m  -jar app.jar 

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

监视

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

通过对堆和Metaspace的使用情况分析,可以看到对应内存空间的使用和增长情况,可进行合理调整和规划。

点击右上角的“堆 dump”,会基于点击的时间节点生成dump文件。

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

进入可查看在堆中不同实例占用的内存大小。双击类名,即可进入查看“实例数”,也就是具体类的实例详情。

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

内存溢出场景构建

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

测试代码如下:

  1. public class MemoryLeakTest { 
  2.  
  3.     /** 
  4.      * 声明缓存对象 
  5.      */ 
  6.     private static final Map<String, TestMemory> CACHE_MAP = new HashMap<>(); 
  7.  
  8.     public static void main(String[] args) { 
  9.         try { 
  10.             //给打开visualVm时间 
  11.             Thread.sleep(10000); 
  12.         } catch (InterruptedException e) { 
  13.             e.printStackTrace(); 
  14.         } 
  15.         //循环添加对象到缓存 
  16.         for (int i = 0; i < 1000000; i++) { 
  17.             TestMemory t = new TestMemory(); 
  18.             CACHE_MAP.put("key" + i, t); 
  19.         } 
  20.         System.out.println("-------1------"); 
  21.         //为dump出堆提供时间 
  22.         try { 
  23.             //给打开visualVm时间 
  24.             Thread.sleep(10000); 
  25.         } catch (InterruptedException e) { 
  26.             e.printStackTrace(); 
  27.         } 
  28.  
  29.         for(int i=0; i<1000000;i++){ 
  30.             TestMemory t = new TestMemory(); 
  31.             CACHE_MAP.put("key"+i,t); 
  32.         } 
  33.     } 

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

  1. public class TestMemory { 

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

  1. -Xms128m -Xmx128m 

另外,为了分析堆的内存结构中每个区域(新生代、老年代)的内存使用情况,可在VisualVM的“工具”、“插件”中安装Visual GC插件。该插件的使用后续会看到效果。

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

内存溢出分析

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

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

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

打开Visual GC界面,我们会看到面试中被问过很多遍的堆内存结构:

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

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

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

上面说了一些表象的内容,现在真正开进行内存分析了。回到上面提到的“监视”、“堆dump”、“类”中,可以看到下图:

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

上面已经提到,你还可以进一步双击对象名称,去查看对象的详细信息。

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

小结

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

【编辑推荐】

  1. 北航硕士呕心沥血讲授JVM核心技术教程(字节码与类的加载篇)
  2. 203集北航硕士呕心沥血讲授JVM核心技术教程(内存与垃圾回收篇)
  3. JVM FULL GC 生产问题笔记
  4. JVM新生代、老年代的默认比值真的是1:2吗?
  5. JVM FULL GC 生产问题 II-如何定位内存泄露?
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微