15 如何基于 JVM 分析内存使用对象？ 上一讲我带你学习了基于 JVM 的线程分析，相信你已经可以通过热点线程分析出哪些方法在消耗 CPU，拿到这些方法之后你就可以和研发人员讨论后续的优化方案了。那这一讲我们就来重点学习 JVM 内存是如何管理的，有哪些手段可以分析内存对象，并帮助你定位内存的瓶颈。

提到分析 JVM 的内存对象，可能你会问我，之前讲过如何判断服务器内存瓶颈，那 JVM 内存和服务器内存有什么联系呢。我们先来看下这两者的关系，如下图所示：

图片3.png

图 1：内存关系示意图

其实二者的关系很简单，对于服务器系统而言，JVM 只是其中的一部分。当操作系统内存出现瓶颈时，我们便会重点排查哪些应用会占用内存。不过对于更深一步分析内存的使用，并不仅仅是统计使用、空闲等这些数值，我们需要进一步去了解内存结构，以及内存如何分配、如何回收，这样你才能更好地确定内存的问题。

JVM 内存分配

通过第 14 讲的学习你可以知道，Java 文件一般是先编译成 class 结尾的文件，然后通过类加载器到 JVM 内存中。接着我们来看看 JVM 内存结构图，这样能够对它有个全局的了解。

图片1.png

图 2：JVM 内存分配示意图

1.本地方法栈

本地方法栈保存的是 native 方法的信息，native 方法就是 Java 调用非 Java 代码的接口，为什么会有这样的设置呢？简单来说，sun 的解释器是由 C 语言实现的，而 jre 又是基于 Java 语言，所以需要 native 方法来进行跨语言的调用。

2.Java 栈

Java 栈是常用的内存区域之一，它里面存放着基本数据类型和对象的引用，可能你不太清楚什么是对象的引用，拿上一讲中 HelloTester helloTester=new HelloTester() 为例，在 Java 栈中 HelloTester 是个引用，指向在堆空间中开辟的该对象的空间。

3.方法区（JDK 1.8+已经移除）

也叫作永久区，用来存储类信息，如上文描述的 HelloTester。值得注意的是方法区在 JDK 1.8 以上已经被元空间取代，并且元空间不在 JVM 中了，而是在本地内存中独立开辟存储空间。

4.程序计数器

可以认为是线程的信号指示器，它的作用是保存线程当前程序的执行位置，以保证多线程的切换。因为在多线程的情况下，CPU 并不是完成一个线程执行再去执行另外一个线程，而是不停地切换线程执行，这时程序计数器就可以发挥作用了。

5.堆

堆区域是 JVM 调优最重要的区域，堆中存放的数据很多是对象实例，如 HelloTester 的对象存储。堆空间占据着 JVM 中最大的存储区域，存放了很多对象，所以大多数基于 JVM 的内存调优也是对堆空间的调优。

堆空间并非取之不尽，如果一直存放总有用完的时候，所以对于有用的对象应当保存起来，无用的对象应当回收，为了更好地实现这一机制，JVM 将堆空间分成了新生代和老生代，如下图所示：

4.png

图 3：GC 示意对比图

通过图 3 可以看到新生代和老年代的对比，Minor GC 发生在新生代，而 Full GC 发生在老年代。新生代分为三个区，一个 Eden 区和两个 Survivor 区。

先来看下 Eden 区的作用，大部分新生成的对象都是在 Eden 区，Eden 区满了之后便没有内存给新对象使用，Eden 区便会 Minor GC 回收无用内存，剩下的存活对象便会转移到 Survivor 区。

那两个 Survivor 区的作用分别是什么呢？两者其实是对称分布的，一个是 From 区，一个是 To 区。从 Eden 区存活下来的对象首先会被复制到 From 区，当 From 区满时，此时还存活的对象会被转移到 To 区，经历了多次的 Minor GC 后，还存活的对象就会被复制到老年代，老年代的 GC 一般叫作 FullGC 或者 MajorGC。

我们对比下新生代垃圾回收和老年代垃圾回收的区别，如下表所示：

图片2.png

如何定位内存占用问题

回到我们实际工作当中，当你发现 JVM 中使用的内存越来越多或者增长很快的时候，频繁 GC 的时候，应当如何去定位哪些对象导致的这些问题呢？

这其实涉及两个问题：

  • 如何去观察 GC 的频次；
  • 定位占用内存的对象。

1.如何观察 GC 的频次？

本部分我以 JDK 自带的工具来讲解，我一般使用 jstat 来查看 GC 的频次。首先我们来看下基本用法，如下所示： [root@JD ~]/# jstat -gc 26607 1000 3 S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 512.0 512.0 320.0 0.0 86016.0 27828.5 175104.0 157974.6 122840.0 116934.9 16128.0 15060.4 5328 37.311 4 1.042 38.353 512.0 512.0 320.0 0.0 86016.0 27981.9 175104.0 157974.6 122840.0 116934.9 16128.0 15060.4 5328 37.311 4 1.042 38.353 512.0 512.0 320.0 0.0 86016.0 28885.4 175104.0 157974.6 122840.0 116934.9 16128.0 15060.4 5328 37.311 4 1.042 38.353

我们来解析下终端输入的命令：

jstat -gc 26607 1000 3

  • 26607 代表查看的 PID 的 Java 进程号；
  • 1000 代表每隔 1000ms 也就是 1s 显示一次；
  • 3 代表一共显示三次。

接着我们再来看输出选项代表的含义有哪些？这个输出的信息含量比较大，不过信息是有对应关系的，比如 S0C 和 S0U：

  • 一般 C 结尾的代表总的容量大小或者计数的次数；
  • U 结尾代表已使用的容量大小。

这是通用的，你可以看到输出项中有很多以 C 或者 U 结尾。S0 则代表第一个 Survivor 区，也就是我上文说的 From 区。通过以上的讲解，我相信很多名词你不用死记硬背也能理解了，比如 S1C 和 S1U 则表示第二个 Survivor 区也就是 To 区的总容量和使用容量。

接下来我罗列下其他的输出选项含义。

  • EC / EU：Eden 区的总容量/已使用空间的大小。
  • OC / OU：老年代总容量/老年代已使用空间大小。
  • MC / MU：方法区总容量/方法区已使用容量大小。
  • CCSC / CCSU：压缩类总容量/压缩类空间使用大小。
  • YGC / YGCT：年轻代垃圾回收的次数/年轻代垃圾回收消耗时间。
  • FGC / FGCT： 老年代垃圾回收次数/老年代垃圾回收消耗时间。
  • GCT：垃圾回收消耗总时间。

这样对比着看会更直观一点，对于上述输出选项的含义我们都需要有一定的印象，从而通过垃圾回收频率和消耗时间初步判断 GC 是否存在可疑问题。

有同学问过这样的问题，堆内存区域划分了这么多代，感觉很复杂，为什么要这么做呢？

我想不分代，内存垃圾肯定也是可以回收的。而让内存区域分代，主要就是优化垃圾回收的性能，也就是 GC 的性能。有点类似于我们日常生活中的垃圾分类，你把干湿垃圾分离，一方面有利于下一步的再利用，再者对于我们后续垃圾的处理效率也会有较大的提升。对于内存回收其实也是这样的，如果不分代那么所有的对象可能都在同一个大的区间里，GC 依次判断则效率必然是很低，如果是分代处理，对不同的区域分以不同的回收策略，这样效率会高很多。

2.如何定位占用内存的对象？

这里我将推荐一个工具 jmap，通过 jmap 可以指定 Java 进程的 PID，查看该进程的对象、数量等等，接下来我做一个演示。

首先我们来查看进程号为 18658 的应用包，如下所示： [root@JD ~]/# ps -ef|grep demo root 18658 1 0 Dec09 ?后续省略

其中上述输出的第二列 18658 为进程号，然后将进程号通过命令组合可以查看以下信息：

[root@JD ~]/# jmap -histo 18658 head -n 20 num /#instances /#bytes class name ———————————————- 1: 157619 18840672 [C 2: 8326 8324360 [B 3: 146319 3511656 java.lang.String 4: 9224 2825584 [I 5: 65733 2103456 com.example.demo.entity.User 6: 62508 2000256 java.util.HashMap$Node 7: 21868 1618832 [Ljava.lang.Object;
  • num 是编号；
  • instances 是生成的实例个数；
  • bytes 是实例占用的大小；
  • classs name 对象的类名。

其中 [C、[S、[I、[B 对应的类型如下所示： [C is a char[] [S is a short[] [I is a int[] [B is a byte[]

你注意下第五行，这是能够最直接看到的业务类，如果是业务对象尤其需要关注，看是否一直上升。

可视化的 JVM 监控工具

在第三模块中，你可以知道，对于监控定位我一般会采用命令行结合可视化的方案一并讲解，接下来我介绍一个 JDK 自带的 JVM 监控工具：jvisual。

jvisual 能做的事情很多，监控内存泄漏、跟踪垃圾回收、执行时内存分析、CPU 线程分析等，而且通过图形化的界面指引就可以完成，接下来我主要讲述 jvisual 如何使用以及如何看内存对象的占用。

先来看下 jvisual 是如何使用的，一般我们会在启动被测的 jar 服务里进行如下配置： nohup java -Djava.rmi.server.hostname=实际ip -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -jar demo-0.0.1-SNAPSHOT.jar &

通过这样的方式可以启动暴露 1099 端口，且连接时不需要认证。

然后在本机电脑 jdk 路径 bin 目录下找到 jvisualvm，双击打开，如下图所示：

Drawing 3.png

我们再配置相应的 jmx 连接，如下图所示：

Drawing 4.png

如果出现如下图所示的界面，就证明连接成功了。

image

这样我们就能够概览 JVM 的 CPU 和内存的使用情况，如下图所示，通过点击抽样器，你可以分别获得对象在 CPU 和内存的占用。值得注意的是很多初学者把这部分 CPU 监控或者内存监控认为是服务器硬件级别的，这是不对的，这些都是基于 JVM 的监控。

Drawing 6.png

按照内存占用进行排序是非常清晰的，你可以看到随着性能测试的进行，User 类字节占用比例越来越高，如下图所示：

Drawing 7.png

总结

通过本讲的学习，你了解了 JVM 的内存结构，知道了 Java 内存对象经常活动的区域，同时列举了常见的排查手段诊断内存问题。

参考资料

https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e8%af%b4%e9%80%8f%e6%80%a7%e8%83%bd%e6%b5%8b%e8%af%95/15%20%20%e5%a6%82%e4%bd%95%e5%9f%ba%e4%ba%8e%20JVM%20%e5%88%86%e6%9e%90%e5%86%85%e5%ad%98%e4%bd%bf%e7%94%a8%e5%af%b9%e8%b1%a1%ef%bc%9f.md