JVM篇：监控及诊断工具GUI

蔚落 2024-03-17 20:24 55阅读 0赞

### 工具概述 ###

使用上一章命令行工具或组合能帮您获取目标 Java 应用性能相关的基础信息，但它们存在下列局限：

*  无法获取方法级别的分析数据，如方法间的调用关系、各方法的调用次数和调用时间等(这对定位应用性能瓶颈至关重要)
 *  要求用户登录到目标 Java 应用所在的宿主机上，使用起来不是很方便
 *  分析数据通过终端输出，结果展示不够直观

为此，JDK 提供了一些内存泄漏的分析工具，如 jconsole，jvisualvm 等，用于辅助开发人员定位问题，但是这些工具很多时候并不足以满足快速定位的需求。所以这里我们介绍的工具相对多一些、丰富一些。

**JDK 自带的工具**

自带的工具在 JDK 的 Bin 目录下。

*  jconsole：JDK 自带的可视化监控工具。查看 Java 应用程序的运行概况、监控堆信息、永久区(或元空间)使用情况、类加载情况等
 *  Visual VM：Visual VM 是一个工具，它提供了一个可视界面，用于查看 Java 虚拟机上运行的基于 Java 技术的应用程序的详细信息
 *  JMC：Java Mission Control，内置 Java Flight Recorder。能够以极低的性能开销收集 Java 虚拟机的性能数据

**第三方工具**

*  MAT：MAT(Memory Analyzer Tool)是基于 Eclipse 的内存分析工具，是一个快速、功能丰富的 Java heap 分析工具，它可以帮助我们查找内存泄漏和减少内存消耗
 *  JProfiler：商业软件，需要付费，功能强大

### JConsole ###

> 官方地址：`https://docs.oracle.com/javase/7/docs/technotes/guides/management/jconsole.html`

jconsole：从 Java5 开始，在 JDK 中自带的 java 监控和管理控制台。用于对 JVM 中内存、线程和类等的监控，是一个基于 JMX(java management extensions)的 GUI 性能监控工具。

直接在 JDK 的 bin 目录下启动 jconsole.exe 命令即可。

#### 三种连接方式 ####

Local：使用 JConsole 连接一个正在本地系统运行的JVM,并且执行程序的和运行 JConsole 的需要是同一个用户。JConsole 使用文件系统的授权通过 RMIl 连接器连接到平台的 MBean 服务器上。这种从本地连接的监控能力只有 Sun 的 JDK 具有。

Remote：使用下面的 URL 通过 RMI 连接器连接到一个 JMX 代理，`servicejmx.rmi:///jndi/rmi://hostName:portNum/jmxrmi`。JConsole 为建立连接，需要在环境变量中设置 `mx.remote.credentials` 来指定用户名和密码，从而进行授权。

Advanced：使用一个特殊的 URL 连接 JMX 代理。一般情况使用自己定制的连接器而不是 RMI 提供的连接器来连接 JMX 代理，或者是一个使用 JDK1.4 的实现了 JMX 和 JMX Rmote 的应用。

#### 工具图 ####

概述、内存、线程、类、VM 概要、MBean。

![image-20210505141631635][]

![image-20210505141726143][]

![image-20210505141924211][]

![image-20210505141950000][]

![image-20210505142050157][]

### Visual VM ###

> 官方地址：`https://visualvm.github.io/index.html`

Visual VM 是一个功能强大的多合一故障诊断和性能监控的可视化工具。它集成了多个 JDK 命令行工具，使用 Visual VM 可用于显示虚拟机进程及进程的配置和环境信息(jps，jinfo)，监视应用程序的 CPU、GC、堆、方法区及线程的信息(jstat、jstack)等，甚至代替 JConsole。在 JDK 6 Update 7 以后，Visual VM 便作为 JDK 的一部分发布(VisualVM 在 JDK／bin 目录下)即：它完全免费。

#### 插件安装 ####

Visual VM 的一大特点是支持插件扩展，并且插件安装非常方便。我们既可以通过离线下载插件文件 `*.nbm`，然后在 Plugin 对话框的已下载页面下，添加已下载的插件。也可以在可用插件页面下，在线安装插件。(**这里建议安装上 Visual GC**)

> 插件地址: `https://visualvm.github.io/pluginscenters.html`

可以在 Idea 按照 Visual VM：

![image-20220131224447624][]

按照完插件之后，重启 Idea ，然后配置 Visual VM 的启动路径：

![image-20220131224552415][]

#### 连接方式 ####

> 本地连接

监控本地 Java 进程的 CPU、类、线程等。

> 远程连接

*  确定远程服务器的 IP 地址
 *  添加 JMX，通过 JXM 技术具体监控远端服务器的哪个 Java 进程)
 *  修改 JDK 的 `bin/catalina.sh` 文件，连接远程的 Tomcat
 *  在 `../conf` 中添加 `jmxremote.access` 和 `jmxremote.password` 文件
 *  将服务器地址改为公网 IP 地址
 *  设置阿里云安全策略和防火墙策略
 *  启动 Tomcat，查看 Tomcat 启动日志和端口监听
 *  JMX 中输入端口号、用户名、密码登录

#### 主要功能 ####

*  生成/读取堆内存/线程快照
 *  查看 JVM 参数和系统属性
 *  查看运行中的虚拟机进程
 *  程序资源的实时监控
 *  JMX 代理连接、远程环境监控、CPU 分析和内存分析

![image-20220131225514738][]

![image-20220131225731574][]

![image-20220131225659672][]

![image-20220131232928306][]

### Eclipse MAT ###

> 官方地址： `https://www.eclipse.org/mat/downloads.php`

MAT(Memory Analyzer Tool)工具是一款功能强大的 Java 堆内存分析器。可以用于查找内存泄漏以及查看内存消耗情况。MAT 是基于 Eclipse 开发的，不仅可以单独使用，还可以作为插件的形式嵌入在 Eclipse 中使用。是一款免费的性能分析工具，使用起来非常方便。

MAT 可以分析 heap dump 文件。在进行内存分析时，只要获得了反映当前设备内存映像的 hprof 文件，通过 MAT 打开就可以直观地看到当前的内存信息。一般说来，这些内存信息包含：

*  所有的对象信息，包括对象实例、成员变量、存储于栈中的基本类型值和存储于堆中的其他对象的引用值
 *  所有的类信息，包括 classloader、类名称、父类、静态变量等
 *  GCRoot 到所有的这些对象的引用路径
 *  线程信息，包括线程的调用栈及此线程的线程局部变量(TLS)

#### 优缺点 ####

> 缺点

MAT 不是一个万能工具，它并不能处理所有类型的堆存储文件。但是比较主流的厂家和格式，例如 Sun，HP，SAP 所采用的 HPROF 二进制堆存储文件，以及 IBM 的 PHD 堆存储文件等都能被很好的解析。

> 优点

最吸引人的还是能够快速为开发人员生成 **内存泄漏报表**，方便定位问题和分析问题。虽然 MAT 有如此强大的功能，但是内存分析也没有简单到一键完成的程度，很多内存问题还是需要我们从 MAT 展现给我们的信息当中通过经验和直觉来判断才能发现。

#### 获取dump文件 ####

方法一：通过前一章介绍的 jmap工具生成，可以生成任意一个java进程的dump文件。

方法二：通过配置 JVM 参数生成。

*  选项 `-XX:+HeapDumpOnOutOfMemoryError` 或 `-XX:+HeapDumpBeforeFullGC`
 *  选项 `-XX:HeapDumpPath` 所代表的含义就是当程序出现 `OutofMemory` 时，将会在相应的目录下生成一份 dump 文件。如果不指定选项 `XX:HeapDumpPath` 则在当前目录下生成 dump 文件

对比：考虑到生产环境中几乎不可能在线对其进行分析，大都是采用离线分析，因此使用 jmap + MAT 工具是最常见的组合。

方法三：使用 Visual VM 可以导出堆 dump 文件。

方法四：使用 MAT 既可以打开一个已有的堆快照，也可以通过 MAT 直接从活动 Java 程序中导出堆快照。该功能将借助 jps 列出当前正在运行的 Java 进程，以供选择并获取快照。

#### 解析dump文件 ####

打开一个 dump 文件。

![image-20220131232636697][]

打开后的界面：

![image-20220131232737535][]

概述，查看堆大小，类的数量，类加载器等信息。

![image-20220131233225517][]

![image-20220131233533551][]

![image-20220131233645314][]

> Histogram 直方图

![image-20220131233915003][]

thread overview：查看系统中的 Java 线程，查看局部变量表的信息。

![image-20220131234401041][]

> 查看对象互相引用的关系

在 MAT 工具的 thread overview 中，右键目标类找到 `with outgoing references` 或 `with incoming references`。即可查看谁引用了该类，该类引用了谁。

![image-20220131234920860][]

#### 浅堆和深堆 ####

**浅堆(Shallow Heap)**

指一个对象所消耗的内存。在 32 位系统中，一个对象引用会占据 4 个字节，一个 int 类型会占据 4 个字节，long 型变量会占据 8 个字节，每个对象头需要占用 8 个字节。根据堆快照格式不同，对象的大小可能会向8字节进行对齐。

以 String 为例：2 个 int 值共占 8 字节，对象引用占用 4 字节，对象头 8 字节，合计 20 字节，向 8 字节对齐，故占 24 字节。(JDK7 中)

| 数据类型 | 类型 | 目的 | | ---- | ------ | ---------------------- | | int | hash32 | 0 | | int | hash | 0 | | ref | value | C:\\User\\Administration |

这 24 字节为 String 对象的浅堆大小。它与 String 的 value 实际取值无关，无论字符串长度如何，浅堆大小始终是 24 字节。

**保留集(Retained Set)**

对象A的保留集指当对象A被垃圾回收后，可以被释放的所有的对象集合(包括对象 A 本身)，即对象A的保留集可以被认为是 **只能通过** 对象 A 被直接或间接访问到的所有对象的集合。通俗地说，就是指仅被对象 A 所持有的对象的集合。

**深堆(Retained Heap)**

深堆是指对象的保留集中所有的对象的浅堆大小之和。

注意：浅堆指对象本身占用的内存，不包括其内部引用对象的大小。一个对象的深堆指只能通过该对象访问到的(直接或间接)所有对象的浅堆之和，即对象被回收后，可以释放的真实空间。

> 对象实际大小

另外一个常用的概念是对象的实际大小。这里，对象的实际大小定义为一个对象 **所能触及** 的所有对象的浅堆大小之和，也就是通常意义上我们说的对象大小。与深堆相比，似乎这个在日常开发中更为直观利被人接受，**但实际上，这个概念和垃圾回收无关**。

下图显示了一个简单的对象引用关系图，对象 A 引用了 C 和 D，对象 B 引用了 C 和 E。那么对象A的浅堆大小只是 A 本身，不含 C 和 D，而 A 的实际大小为 A、C、D 三者之和。而 A 的深堆大小为 A 与 D 之和，由于对象 C 还可以通过对象 B 访问到，因此不在对象 A 的深堆范围内。

![image-20220201003432711][]

练习：

![image-20220201003650210][]

上图中，GC Roots 直接引用了 A 和 B 两个对象。

A 对象的 Retained Size = A 对象的 Shallow Size。

B 对象的 Retained Size=B 对象的 Shallow Size + C 对象的 Shallow Size。

这里不包括 D 对象，因为 D 对象被 GC Roots 直接引用。

如果 GC Roots 不引用 D 对象呢？则 D 就只属于 B 调用。如下图：

![image-20220201003643235][]

#### 深堆与浅堆案例分析 ####

案例视频：`https://www.bilibili.com/video/BV1PJ411n7xZ?p=333`

代码：

`/** * 有一个学生浏览网页的记录程序，它将记录 每个学生访问过的网站地址。 * 它由三个部分组成：Student、WebPage和StudentTrace三个类 * * -XX:+HeapDumpBeforeFullGC -XX:HeapDumpPath=d:\student.hprof */ public class StudentTrace { static List<WebPage> webpages = new ArrayList<WebPage>(); public static void createWebPages() { for (int i = 0; i < 100; i++) { WebPage wp = new WebPage(); wp.setUrl("http://www." + Integer.toString(i) + ".com"); wp.setContent(Integer.toString(i)); webpages.add(wp); } } public static void main(String[] args) { createWebPages();//创建了100个网页 //创建3个学生对象 Student st3 = new Student(3, "Tom"); Student st5 = new Student(5, "Jerry"); Student st7 = new Student(7, "Lily"); for (int i = 0; i < webpages.size(); i++) { if (i % st3.getId() == 0) st3.visit(webpages.get(i)); if (i % st5.getId() == 0) st5.visit(webpages.get(i)); if (i % st7.getId() == 0) st7.visit(webpages.get(i)); } webpages.clear(); System.gc(); } } class Student { private int id; private String name; private List<WebPage> history = new ArrayList<>(); public Student(int id, String name) { super(); this.id = id; this.name = name; } public int getId() { return id; } public void setId(int id) { this.id = id; } public String getName() { return name; } public void setName(String name) { this.name = name; } public List<WebPage> getHistory() { return history; } public void setHistory(List<WebPage> history) { this.history = history; } public void visit(WebPage wp) { if (wp != null) { history.add(wp); } } } class WebPage { private String url; private String content; public String getUrl() { return url; } public void setUrl(String url) { this.url = url; } public String getContent() { return content; } public void setContent(String content) { this.content = content; } }`

JVM 参数：

`-XX:+HeapDumpBeforeFullGC -XX:HeapDumpPath=d:\student.hprof`

运行后，生成 dump 文件，利用 MAT 打开 dump 文件，找到 thread overview，如图得到其中一个学生的访问数据大小 1288：

![image-20220201005307683][]

**计算 1288 怎么得到的**。

首先有 15 个 WebPage，每个对应 152 个字节：`15 * 152 = 2280` 字节，这是 elementData 的实际大小。

能被 7 整除，且能被 3 整除，以及能被 7 整除，且能被 5 整除的数值有：0、21、42、63、84、35、70 共 7 个数。

`7 * 152 = 1064` 字节。

那么我们得到 `2280 - 1064 - 1288 = 72` 字节，这个 72 字节是什么？

15 个 elementData 的元素 \* 4 字节 = 60 字节。

60 + 8 个对象头的字节 + 数组本身 4 个字节 = 72 字节。

#### 支配树 ####

支配树的概念源自图论。

MAT 提供了一个称为支配树(Dominator Tree)的对象图。支配树体现了对象实例间的支配关系。在对象引用图中，所有指向对象 B 的路径都经过对象 A，则认为 **对象 A 支配对象 B**。如果对象 A 是离对象 B 最近的一个支配对象，则认为对象 A 为对象 B 的 **直接支配者**。支配树是基于对象间的引用图所建立的，它有以下基本性质：

*  对象 A 的子树(所有被对象 A 支配的对象集合)表示对象 A 的 **保留集**(retained set)，即深堆
 *  如果对象 A 支配对象 B，那么对象 A 的直接支配者也支配对象 B
 *  支配树的边与对象引用图的边不直接对应

如下图所示：左图表示对象引用图，右图表示左图所对应的支配树。对象 A 和 B 由根对象直接支配，由于在到对象 C 的路径中，可以经过 A，也可以经过 B，因此对象 C 的直接支配者也是根对象。对象 F 与对象 D 相互引用，因为到对象 F 的所有路径必然经过对象 D，因此，对象 D 是对象 F 的直接支配者。而到对象 D 的所有路径中，必然经过对象 C，即使是从对象 F 到对象 D 的引用，从根节点出发，也是经过对象 C 的，所以，对象 D 的直接支配者为对象 C。

![image-20220201010504721][]

同理，对象 E 支配对象 G。到达对象H的可以通过对象 D，也可以通过对象 E，因此对象 D 和 E 都不能支配对象 H，而经过对象 C 既可以到达 D 也可以到达 E，因此对象 C 为对象 H 的直接支配者。

在 MAT 中，单击工具栏上的对象支配树按钮，可以打开对象支配树视图。

![image-20220201010932876][]

可以看到，有 8 个 WebPage 属于该学生的，上面案例得到的 7 个 WebPage 属于「共有」，`15 - 7 = 8` 个 WebPage 属于该学生的「私有」。

#### Tomcat堆溢出分析案例 ####

> 案例视频：`https://www.bilibili.com/video/BV1PJ411n7xZ?p=334`

Tomcat 是最常用的 Java Servlet 容器之一，同时也可以当做单独的 Web 服务器使用。Tomcat 本身使用 Java 实现，并运行于 Java 虚拟机之上。在大规模请求时，Tomcat 有可能会因为无法承受压力而发生内存溢出错误。这里根据一个被压垮的 Tomcat 的堆快照文件，来分析 Tomcat 在崩溃时的内部情况。

图 1：

![image-20220201012013800][]

图 2：

![image-20220201012135383][]

图 3：sessions 对象，它占用了约 17MB 空间。

![image-20220201011857288][]

图 4：可以看到 sessions 对象为 ConcurrentHashMap，其内部分为 16 个 Segment。从深堆大小看，每个 Segment 都比较平均，大约为 1MB，合计 17MB。

![image-20220201012354238][]

图 5：

![image-20220201012443880][]

图 6：当前堆中含有 9941 个 session，并且每一个 session 的深堆为 1592 字节，合计约 15NB，达到当前堆大小的 50%。

![image-20220201012624399][]

图 7：

![image-20220201012758369][]

图 8：

![image-20220201012222622][]

根据当前的 session 总数，可以计算每秒的平均压力为：`9941 / (1403324677648 - 1403324645728) * 1000 = 311` 次 / 秒。

由此推断，在发生 Tomcat 堆溢出时，Tomcat 在连续 30 秒的时间内，平均每秒接收了约 311 次不同客户端的请求，创建了合计 9941 个 session。

### 再谈内存问题 ###

#### 内存泄漏(memory leak) ####

可达性分析算法来判断对象是否是不再使用的对象，本质都是判断一个对象是否还被引用。那么对于这种情况下，由于代码的实现不同就会出现很多种内存泄漏问题(让 JVM 误以为此对象还在引用中，无法回收，造成内存泄漏)。

是否还被使用？是

是否还被需要？否

![image-20210505152542224][]

严格来说，只有对象不会再被程序用到了，但是 GC 又不能回收他们的情况，才叫内存泄漏。但实际情况很多时候一些不太好的实践(或疏忽)会导致对象的生命周期变得很长甚至导致 00M，也可以叫做宽泛意义上的「内存泄漏」。

如下图，当 Y 生命周期结束的时候，X 依然引用着 Y，这时候，垃圾回收期是不会回收对象 Y 的；如果对象 X 还引用着生命周期比较短的 A、B、C，对象 A 又引用着对象 a、b、c，这样就可能造成大量无用的对象不能被回收，进而占据了内存资源，造成内存泄漏，直到内存溢出。

![image-20210505152704141][]

申请了内存用完了不释放，比如一共有 1024M 的内存，分配了 512M 的内存一直不回收，那么可以用的内存只有 512M 了，仿佛泄露掉了一部分；通俗一点讲的话，内存泄漏就是「占着茅坑不拉 shi」

#### 内存溢出(out of memory) ####

申请内存时，没有足够的内存可以使用；通俗一点儿讲，一个厕所就三个坑，有两个站着茅坑不走的(内存泄漏)，剩下最后一个坑，厕所表示接待压力很大，这时候一下子来了两个人，坑位(内存)就不够了，内存泄漏变成内存溢出了。可见，内存泄漏和内存溢出的关系：内存泄漏的增多，最终会导致内存溢出。

泄漏的分类：

*  经常发生：发生内存泄露的代码会被多次执行，每次执行，泄露一块内存
 *  偶然发生：在某些特定情况下才会发生
 *  一次性：发生内存泄露的方法只会执行一次
 *  隐式泄漏：一直占着内存不释放，直到执行结束；严格的说这个不算内存泄漏，因为最终释放掉了，但是如果执行时间特别长，也可能会导致内存耗尽

#### 内存泄露的8种情况 ####

> 静态集合类

静态集合类，如 HashMap、LinkedList 等等。如果这些容器为静态的，那么它们的生命周期与 JVM 程序一致，则容器中的对象在程序结束之前将不能被释放，从而造成内存泄漏。简单而言，长生命周期的对象持有短生命周期对象的引用，尽管短生命周期的对象不再使用，但是因为长生命周期对象持有它的引用而导致不能被回收。

`public class MemoryLeak { static List list = new ArrayList(); // 静态和类的生命周期一致 public void oomTests(){ Object obj = new Object(); // 局部变量 list.add(obj); } }`

> 单例模式

单例模式，和静态集合导致内存泄露的原因类似，因为单例的静态特性，它的生命周期和 JVM 的生命周期一样长，所以如果单例对象如果持有外部对象的引用，那么这个外部对象也不会被回收，那么就会造成内存泄漏。

> 内部类持有外部类

内部类持有外部类，如果一个外部类的实例对象的方法返回了一个内部类的实例对象。这个内部类对象被长期引用了，即使那个外部类实例对象不再被使用，但由于内部类持有外部类的实例对象，这个外部类对象将不会被垃圾回收，这也会造成内存泄漏。

> 各种连接，如数据库连接、网络连接和 IO 连接等

在对数据库进行操作的过程中，首先需要建立与数据库的连接，当不再使用时，需要调用 close 方法来释放与数据库的连接。只有连接被关闭后，垃圾回收器才会回收对应的对象。否则，如果在访问数据库的过程中，对 Connection、Statement 或 ResultSet 不显性地关闭，将会造成大量的对象无法被回收，从而引起内存泄漏。

`public static void main(String[] args) { try{ Connection conn = null; Class.forName("com.mysql.jdbc.Driver"); conn = DriverManager.getConnection("url", "", ""); Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("...."); } catch(Exception e){ // 异常日志 } finally { // 1．关闭结果集 Statement // 2．关闭声明的对象 ResultSet // 3．关闭连接 Connection } }`

> 变量不合理的作用域

变量不合理的作用域。一般而言，一个变量的定义的作用范围大于其使用范围，很有可能会造成内存泄漏。另一方面，如果没有及时地把对象设置为 null，很有可能导致内存泄漏的发生。

`public class UsingRandom { private String msg; public void receiveMsg(){ readFromNet();//从网络中接受数据保存到msg中 saveDB();//把msg保存到数据库中 } }`

如上面这个伪代码，通过 readFromNet 方法把接受的消息保存在变量 msg 中，然后调用 saveDB 方法把 msg 的内容保存到数据库中，此时 msg 已经就没用了，由于 msg 的生命周期与对象的生命周期相同，此时 msg 还不能回收，因此造成了内存泄漏。

实际上这个 msg 变量可以放在 receiveMsg 方法内部，当方法使用完，那么 msg 的生命周期也就结束，此时就可以回收了。还有一种方法，在使用完 msg 后，把 msg 设置为 null，这样垃圾回收器也会回收 msg 的内存空间。

> 改变哈希值

改变哈希值，当一个对象被存储进 HashSet 集合中以后，就不能修改这个对象中的那些参与计算哈希值的字段了。

否则，对象修改后的哈希值与最初存储进 HashSet 集合中时的哈希值就不同了，在这种情况下，即使在 contains 方法使用该对象的当前引用作为的参数去 HashSet 集合中检索对象，也将返回找不到对象的结果，这也会导致无法从 HashSet 集合中单独删除当前对象，造成内存泄漏。

这也是 String 为什么被设置成了不可变类型，我们可以放心地把 String 存入 HashSet，或者把 String 当做 HashMap 的 key 值。

当我们想把自己定义的类保存到散列表的时候，需要保证对象的 hashCode 不可变。

代码示例 1：

`/** * 例 1 */ public class ChangeHashCode { public static void main(String[] args) { HashSet set = new HashSet(); Person p1 = new Person(1001, "AA"); Person p2 = new Person(1002, "BB"); set.add(p1); set.add(p2); p1.name = "CC"; // 导致了内存的泄漏 set.remove(p1); // 删除失败 System.out.println(set); set.add(new Person(1001, "CC")); System.out.println(set); set.add(new Person(1001, "AA")); System.out.println(set); } } class Person { int id; String name; public Person(int id, String name) { this.id = id; this.name = name; } @Override public boolean equals(Object o) { if (this == o) return true; if (!(o instanceof Person)) return false; Person person = (Person) o; if (id != person.id) return false; return name != null ? name.equals(person.name) : person.name == null; } @Override public int hashCode() { int result = id; result = 31 * result + (name != null ? name.hashCode() : 0); return result; } @Override public String toString() { return "Person{" + "id=" + id + ", name='" + name + ''' + '}'; } }`

输出结果：

`[Person{id=1002, name='BB'}, Person{id=1001, name='CC'}] [Person{id=1002, name='BB'}, Person{id=1001, name='CC'}, Person{id=1001, name='CC'}] [Person{id=1002, name='BB'}, Person{id=1001, name='CC'}, Person{id=1001, name='CC'}, Person{id=1001, name='AA'}]`

代码示例 2：

`/** * 例 2 */ public class ChangeHashCode1 { public static void main(String[] args) { HashSet<Point> hs = new HashSet<Point>(); Point cc = new Point(); cc.setX(10); // hashCode = 41 hs.add(cc); cc.setX(20); // hashCode = 51 此行为导致了内存的泄漏 System.out.println("hs.remove = " + hs.remove(cc)); // false hs.add(cc); System.out.println("hs.size = " + hs.size()); // size = 2 System.out.println(hs); } } class Point { int x; public int getX() { return x; } public void setX(int x) { this.x = x; } @Override public int hashCode() { final int prime = 31; int result = 1; result = prime * result + x; return result; } @Override public boolean equals(Object obj) { if (this == obj) return true; if (obj == null) return false; if (getClass() != obj.getClass()) return false; Point other = (Point) obj; if (x != other.x) return false; return true; } @Override public String toString() { return "Point{" + "x=" + x + '}'; } }`

输出结果：

`hs.remove = false hs.size = 2 [Point{x=20}, Point{x=20}]`

> 缓存泄露

内存泄漏的另一个常见来源是缓存，一旦你把对象引用放入到缓存中，他就很容易遗忘。比如：之前项目在一次上线的时候，应用启动奇慢直到夯死，就是因为代码中会加载一个表中的数据到缓存(内存)中，测试环境只有几百条数据，但是生产环境有几百万的数据。

对于这个问题，可以使用 WeakHashMap 代表缓存，此种 Map 的特点是，当除了自身有对 key 的引用外，此 key 没有其他引用那么此 map 会自动丢弃此值。

`public class MapTest { static Map wMap = new WeakHashMap(); static Map map = new HashMap(); public static void main(String[] args) { init(); testWeakHashMap(); testHashMap(); } public static void init() { String ref1 = new String("obejct1"); String ref2 = new String("obejct2"); String ref3 = new String("obejct3"); String ref4 = new String("obejct4"); wMap.put(ref1, "cacheObject1"); wMap.put(ref2, "cacheObject2"); map.put(ref3, "cacheObject3"); map.put(ref4, "cacheObject4"); System.out.println("String引用ref1，ref2，ref3，ref4 消失"); } public static void testWeakHashMap() { System.out.println("WeakHashMap GC之前"); for (Object o : wMap.entrySet()) { System.out.println(o); } try { System.gc(); TimeUnit.SECONDS.sleep(5); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("WeakHashMap GC之后"); for (Object o : wMap.entrySet()) { System.out.println(o); } } public static void testHashMap() { System.out.println("HashMap GC之前"); for (Object o : map.entrySet()) { System.out.println(o); } try { System.gc(); TimeUnit.SECONDS.sleep(5); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("HashMap GC之后"); for (Object o : map.entrySet()) { System.out.println(o); } } }`

输出结果：

`String引用ref1，ref2，ref3，ref4 消失 WeakHashMap GC之前 obejct2=cacheObject2 obejct1=cacheObject1 WeakHashMap GC之后 HashMap GC之前 obejct4=cacheObject4 obejct3=cacheObject3 HashMap GC之后 obejct4=cacheObject4 obejct3=cacheObject3`

上面代码和图示主演演示 WeakHashMap 如何自动释放缓存对象，当 init 函数执行完成后，局部变量字符串引用 weakd1，weakd2，d1，d2 都会消失，此时只有静态 map 中保存中对字符串对象的引用，可以看到，调用 gc 之后，HashMap 的没有被回收，而 WeakHashMap 里面的缓存被回收了。

> 监听器和其他回调

内存泄漏第三个常见来源是监听器和其他回调，如果客户端在你实现的 API 中注册回调，却没有显示的取消，那么就会积聚。

需要确保回调立即被当作垃圾回收的最佳方法是只保存它的弱引用，例如将他们保存成为 WeakHashMap 中的键。

#### 内存泄露案例分析 ####

`public class Stack { private Object[] elements; private int size = 0; private static final int DEFAULT_INITIAL_CAPACITY = 16; public Stack() { elements = new Object[DEFAULT_INITIAL_CAPACITY]; } public void push(Object e) { // 入栈 ensureCapacity(); elements[size++] = e; } // 错误的做法：存在内存泄漏 // public Object pop() { // 出栈 // if (size == 0) // throw new EmptyStackException(); // return elements[--size]; // } // 正确的做法 public Object pop() { if (size == 0) throw new EmptyStackException(); Object result = elements[--size]; elements[size] = null; return result; } private void ensureCapacity() { if (elements.length == size) elements = Arrays.copyOf(elements, 2 * size + 1); } }`

上述程序并没有明显的错误，但是这段程序有一个内存泄漏，随着 GC 活动的增加，或者内存占用的不断增加，程序性能的降低就会表现出来，严重时可导致内存泄漏，但是这种失败情况相对较少。

代码的主要问题在 pop 函数，下面通过这张图示展现。假设这个栈一直增长，增长后如下图所示

![image-20210505160114618][]

当进行大量的 pop 操作时，由于引用未进行置空，GC 是不会释放的，如下图所示

![image-20220201160456212][]

从上图中看以看出，如果栈先增长，再收缩，那么从栈中弹出的对象将不会被当作垃圾回收，即使程序不再使用栈中的这些队象，他们也不会回收，因为栈中仍然保存这对象的引用，俗称过期引用，这个内存泄露很隐蔽。

将代码中的 pop()方法变成如下方法：

`public Object pop() { if (size == 0) throw new EmptyStackException(); Object result = elements[--size]; elements[size] = null; return result; }`

一旦引用过期，清空这些引用，将引用置空。

![image-20210505160423289][]

### 使用OQL语言查询对象信息 ###

MAT 支持一种类似于 SQL 的查询语言 OQL(Object Query Language)。OQL 使用类 SQL 语法，可以在堆中进行对象的查找和筛选。

#### SELECT子句 ####

在 MAT 中，Select 子句的格式与 SQL 基本一致，用于指定要显示的列。Select 子句中可以使用 `＊`，查看结果对象的引用实例(相当于 outgoing references)。

`SELECT * FROM java.util.Vector v`

使用 `OBJECTS` 关键字，可以将返回结果集中的项以对象的形式显示。

`SELECT objects v.elementData FROM java.util.Vector v SELECT OBJECTS s.value FROM java.lang.String s`

在 Select 子句中，使用 `AS RETAINED SET` 关键字可以得到所得对象的保留集。

`SELECT AS RETAINED SET * FROM cn.kbt.mat.Student`

`DISTINCT` 关键字用于在结果集中去除重复对象。

`SELECT DISTINCT OBJECTS classof(s) FROM java.lang.String s`

#### FROM子句 ####

From 子句用于指定查询范围，它可以指定类名、正则表达式或者对象地址。

`SELECT * FROM java.lang.String s`

使用正则表达式，限定搜索范围，输出所有 cn.kbt 包下所有类的实例。

`SELECT * FROM "cn.kbt..*"`

使用类的地址进行搜索。使用类的地址的好处是可以区分被不同 ClassLoader 加载的同一种类型。

`select * from 0x37a0b4d`

#### WHERE子句 ####

Where 子句用于指定 OQL 的查询条件。OQL 查询将只返回满足 Where 子句指定条件的对象。Where 子句的格式与传统 SQL 极为相似。

返回长度大于 10 的 char 数组。

`SELECT * FROM Ichar[] s WHERE s.@length > 10`

返回包含 `java` 子字符串的所有字符串，使用 `LIKE` 操作符，`LIKE` 操作符的操作参数为正则表达式。

`SELECT * FROM java.lang.String s WHERE toString(s) LIKE ".*java.*"`

返回所有 value 域不为 null 的字符串，使用 `＝` 操作符。

`SELECT * FROM java.lang.String s where s.value != null`

返回数组长度大于 15，并且深堆大于 1000 字节的所有 Vector 对象。

`SELECT * FROM java.util.Vector v WHERE v.elementData.@length > 15 AND v.@retainedHeapSize > 1000`

#### 内置对象与方法 ####

OQL 中可以访问堆内对象的属性，也可以访问堆内代理对象的属性。访问堆内对象的属性时，格式如下，其中 alias 为对象名称：

\[ . \] . .

访问 `java.io.File` 对象的 path 属性，并进一步访问 path 的 value 属性：

`SELECT toString(f.path.value) FROM java.io.File f`

显示 String 对象的内容、objectid 和 objectAddress。

`SELECT s.toString(),s.@objectId, s.@objectAddress FROM java.lang.String s`

显示 `java.util.Vector` 内部数组的长度。

`SELECT v.elementData.@length FROM java.util.Vector v`

显示所有的 `java.util.Vector` 对象及其子类型

`select * from INSTANCEOF java.util.Vector`

### JProfiler ###

> 官网地址：`https://www.ej-technologies.com/products/jprofiler/overview.html`

在运行 Java 的时候有时候想测试运行时占用内存情况，这时候就需要使用测试工具查看了。在 eclipse 里面有 Eclipse Memory Analyzer tool(MAT)插件可以测试，而在 IDEA 中也有这么一个插件，就是 JProfiler。JProfiler 是由 ej-technologies 公司开发的一款 Java 应用性能诊断工具。功能强大，但是收费。

#### 基本概述 ####

**特点：**

*  使用方便、界面操作友好(简单且强大)
 *  对被分析的应用影响小(提供模板)
 *  CPU，Thread，Memory 分析功能尤其强大
 *  支持对 jdbc，noSql，jsp，servlet，socket 等进行分析
 *  支持多种模式(离线，在线)的分析
 *  支持监控本地、远程的 JVM
 *  跨平台，拥有多种操作系统的安装版本

![image-20220201162722104][]

**主要功能：**

*  方法调用：对方法调用的分析可以帮助您了解应用程序正在做什么，并找到提高其性能的方法
 *  内存分配：通过分析堆上对象、引用链和垃圾收集能帮您修复内存泄露问题，优化内存使用
 *  线程和锁：JProfiler 提供多种针对线程和锁的分析视图助您发现多线程问题
 *  高级子系统：许多性能问题都发生在更高的语义级别上。例如，对于 JDBC 调用，您可能希望找出执行最慢的 SQL 语句。JProfiler 支持对这些子系统进行集成分析

**Idea 集成安装：**

视频讲解：`https://www.bilibili.com/video/BV1PJ411n7xZ?p=341`

**数据采集方式：**

JProfier 数据采集方式分为两种：Sampling(样本采集)和 Instrumentation(重构模式)。

**Instrumentation**：这是 JProfiler 全功能模式。在 class 加载之前，JProfier 把相关功能代码写入到需要分析的 class 的 bytecode 中，对正在运行的 jvm 有一定影响。

*  优点：功能强大。在此设置中，调用堆栈信息是准确的
 *  缺点：若要分析的 Class 较多，则对应用的性能影响较大，CPU 开销可能很高(取决于 Filter 的控制)。因此使用此模式一般配合 Filter 使用，只对特定的类或包进行分析

**Sampling**：类似于样本统计，每隔一定时间(5ms)将每个线程栈中方法栈中的信息统计出来。

*  优点：对 CPU 的开销非常低，对应用影响小(即使你不配置任何 Filter)
 *  缺点：一些数据／特性不能提供(例如：方法的调用次数、执行时间)

注：JProfiler 本身没有指出数据的采集类型，这里的采集类型是针对方法调用的采集类型。因为 JProfiler 的绝大多数核心功能都依赖方法调用采集的数据，所以可以直接认为是 JProfiler 的数据采集类型。

#### 遥感监测 Telemetries ####

![image-20210505164521410][]

![image-20220201163821835][]

![image-20210505164815324][]

![image-20210505164945192][]

![image-20210505165010529][]

![image-20210505165128212][]

![image-20210505165249919][]

#### 内存视图 Live Memory ####

Live memory 内存剖析：class／class instance 的相关信息。例如对象的个数，大小，对象创建的方法执行栈，对象创建的热点。

*  **所有对象 All Objects**：显示所有加载的类的列表和在堆上分配的实例数。只有 Java 1.5(JVMTI)才会显示此视图。

![image-20220201164328735][]

*  **记录对象 Record Objects**：查看特定时间段对象的分配，并记录分配的调用堆栈。
 *  **分配访问树 Allocation Call Tree**：显示一棵请求树或者方法、类、包或对已选择类有带注释的分配信息的 J2EE 组件。
 *  **分配热点 Allocation Hot Spots**：显示一个列表，包括方法、类、包或分配已选类的 J2EE 组件。你可以标注当前值并且显示差异值。对于每个热点都可以显示它的跟踪记录树。
 *  **类追踪器 Class Tracker**：类跟踪视图可以包含任意数量的图表，显示选定的类和包的实例与时间。

![image-20210505164554298][]

![image-20210505165519790][]

#### [\#][Link 1]堆遍历 heap walker ####

![image-20210505165710620][]

![image-20210505165823201][]

#### cpu 视图(cpu views) ####

JProfiler 提供不同的方法来记录访问树以优化性能和细节。线程或者线程组以及线程状况可以被所有的视图选择。所有的视图都可以聚集到方法、类、包或 J2EE 组件等不同层上。

*  **访问树 Call Tree**：显示一个积累的自顶向下的树，树中包含所有在 JVM 中已记录的访问队列。JDBC，JMS 和 JNDI 服务请求都被注释在请求树中。请求树可以根据 Servlet 和 JSP 对 URL 的不同需要进行拆分。
 *  **热点 Hot Spots**：显示消耗时间最多的方法的列表。对每个热点都能够显示回溯树。该热点可以按照方法请求，JDBC，JMS 和 JNDI 服务请求以及按照 URL 请求来进行计算。
 *  **访问图 Call Graph**：显示一个从已选方法、类、包或 J2EE 组件开始的访问队列的图。
 *  **方法统计 Method Statistis**：显示一段时间内记录的方法的调用时间细节。

![image-20210505170055722][]

![image-20210505170141278][]

#### 线程视图 threads ####

JProfiler 通过对线程历史的监控判断其运行状态，并监控是否有线程阻塞产生，还能将一个线程所管理的方法以树状形式呈现。对线程剖析。

*  **线程历史 Thread History**：显示一个与线程活动和线程状态在一起的活动时间表
 *  **线程监控 Thread Monitor**：显示一个列表，包括所有的活动线程以及它们目前的活动状况
 *  **线程转储 Thread Dumps**：显示所有线程的堆栈跟踪

线程分析主要关心三个方面：

*  Web 容器的线程最大数。比如：Tomcat 的线程容量应该略大于最大并发数
 *  线程阻塞
 *  线程死锁

![image-20220201165337435][]

![image-20210505170739972][]

#### 监控和锁 Monitors＆Locks ####

所有线程持有锁的情况以及锁的信息。观察 JVM 的内部线程并查看状态：

*  **死锁探测图表 Current Locking Graph**：显示 JVM 中的当前死锁图表
 *  **目前使用的监测器 Current Monitors**：显示目前使用的监测器并且包括它们的关联线程
 *  **锁定历史图表 Locking History Graph**：显示记录在 JVM 中的锁定历史
 *  **历史检测记录 Monitor History**：显示重大的等待事件和阻塞事件的历史记录
 *  **监控器使用统计 Monitor Usage Statistics**：显示分组监测，线程和监测类的统计监测数据

#### 简单案例 ####

> 案例 1

`public class JProfilerTest { public static void main(String[] args) { while (true){ ArrayList list = new ArrayList(); for (int i = 0; i < 500; i++) { Data data = new Data(); list.add(data); } try { TimeUnit.MILLISECONDS.sleep(500); } catch (InterruptedException e) { e.printStackTrace(); } } } } class Data{ private int size = 10; private byte[] buffer = new byte[1024 * 1024];//1mb private String info = "hello,kele"; }`

利用 Jprofiler 监控代码的执行，查看内存和 GC 的活动。

![image-20220201170051789][]

![image-20220201170106558][]

> 案例 2

`public class MemoryLeak { public static void main(String[] args) { while (true) { ArrayList beanList = new ArrayList(); for (int i = 0; i < 500; i++) { Bean data = new Bean(); data.list.add(new byte[1024 * 10]);//10kb beanList.add(data); } try { TimeUnit.MILLISECONDS.sleep(500); } catch (InterruptedException e) { e.printStackTrace(); } } } } class Bean { int size = 10; String info = "hello,kele"; static ArrayList list = new ArrayList(); // 错误的写法：静态与类的声明周期一致，所以上面的变量不会被回收 // ArrayList list = new ArrayList(); // 正确的写法 }`

利用 Jprofiler 监控代码的执行，查看内存和 GC 的活动。

![image-20220201170352569][]

![image-20220201170506350][]

### Arthas ###

> 官方地址：`https://arthas.aliyun.com/doc/quick-start.html`

上述工具都必须在服务端项目进程中配置相关的监控参数，然后工具通过远程连接到项目进程，获取相关的数据。这样就会带来一些不便，比如线上环境的网络是隔离的，本地的监控工具根本连不上线上环境。并且类似于 Jprofiler 这样的商业工具，是需要付费的。

那么有没有一款工具不需要远程连接，也不需要配置监控参数，同时也提供了丰富的性能监控数据呢？

阿里巴巴开源的性能分析神器 Arthas 应运而生。

Arthas 是 Alibaba 开源的 Java 诊断工具，深受开发者喜爱。在线排查问题，无需重启；动态跟踪 Java 代码；实时监控 JVM 状态。Arthas 支持 JDK 6 ＋，支持 Linux／Mac／Windows，采用命令行交互模式，同时提供丰富的 Tab 自动补全功能，进一步方便进行问题的定位和诊断。当你遇到以下类似问题而束手无策时，Arthas 可以帮助你解决：

*  这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception
 *  我改的代码为什么没有执行到？难道是我没 commit？分支搞错了
 *  遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗
 *  线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现
 *  是否有一个全局视角来查看系统的运行状况
 *  有什么办法可以监控到 JVM 的实时运行状态
 *  怎么快速定位应用的热点，生成火焰图

#### 安装与使用 ####

在 Linux 的安装方式：如果速度较慢，可以尝试国内的码云 Gitee 下载。

`wget https://io/arthas/arthas-boot.jar wget https://arthas/gitee/io/arthas-boot.jar`

Arthas 只是一个 java 程序，所以可以直接用 `java -jar` 运行。

执行成功后，arthas 提供了一种命令行方式的交互方式，arthas 会检测当前服务器上的 Java 进程，并将进程列表展示出来，用户输入对应的编号(1、2、3、4 ...)进行选择，然后回车。

比如：

*  方式一：`java -jar arthas-boot.jar`
 *  方式二：运行时选择 Java 进程 PID(先使用 `jps` 指令)，再 `java -jar arthas-boot.jar [PID]`

![image-20220201172653188][]

最后一行 \[arthas@5826\]$，说明打开进入了监控客户端，在这里就可以执行相关命令进行查看了。

除了在命令行查看外，Arthas 目前还支持 Web Console。在成功启动连接进程之后就已经自动启动,可以直接访问 `http://127.0.0.1:8563/` 访问，页面上的操作模式和控制台完全一样。

两个实用指令：

*  查看日志：`cat -/logs/arthas/arthas.log`
 *  查看帮助：`java -jar arthas-boot.jar -h`

**工程目录**

| 目录名 | 作用 | | --------------------- | ---------------------- | | arthas-agent | 基于 JavaAgent 技术的代理 | | bin | 一些启动脚本 | | arthas-boot | Java 版本的一键安装启动脚本 | | arthas-client | telnet client 代码 | | arthas-common | 一些共用的工具类和枚举类 | | arthas-core | 核心库，各种 arthas 命令的交互和实现 | | arthas-demo | 示例代码 | | arthas-memorycompiler | 内存编译器代码 | | arthas-packaging | Maven 打包相关 | | arthas-site | arthas 站点 | | arthas-spy | 编织到目标类的各个切面 | | static | 静态资源 | | arthas-testcase | 测试 |

#### 相关指令 ####

指令源于官网，建议看官网，有更详细的介绍和 Demo。

> 基础指令

| 指令 | 作用 | | ------------- | ------------------------------------------------- | | quit/exit | 退出当前 Arthas客户端，其他 Arthas 客户端不受影响 | | stop/shutdown | 关闭 Arthas 服务端，所有 Arthas 客户端全部退出 | | help | 查看命令帮助信息 | | cat | 打印文件内容，和 linux 里的 cat 命令类似 | | echo | 打印参数，和 linux 里的 echo 命令类似 | | grep | 匹配查找，和 linux 里的 gep 命令类似 | | tee | 复制标隹输入到标准输出和指定的文件，和 linux 里的 tee 命令类似 | | pwd | 复制标隹输入到标准输出和指定的文件，和 linux 里的 tee 命令类似 | | cls | 清空当前屏幕区域 | | session | 查看当前会话的信息 | | reset | 重置增强类，将被 Arthas 增强过的类全部还原，Arthas 服务端关闭时会重置所有增强过的类 | | version | 输出当前目标 Java 进程所加载的 Arthas 版本号 | | history | 打印命令历史 | | keymap | Arthas 快捷键列表及自定义快捷键 |

> jvm 相关

| 指令 | 选项 | 作用 | | ----------- | ------ | -------------------------- | | dashboard | | 当前系统的实时数据面板 | | | -i | 每间隔多少毫秒输出一次最新的数据面板 | | | -n | 一共打印多少次数据面板 | | thread | | 查看当前 JVM 的线程堆栈信息 | | | -b | 查看出现死锁的线程堆栈信息 | | jvm | | 查看当前 JVM 的信息 | | sysprop | | 查看和修改 JVM 的系统属性 | | sysem | | 查看 JVM 的环境变量 | | vmoption | | 查看和修改 JVM 里诊断相关的 option | | perfcounter | | 查看当前 JVM 的 Perf Counter 信息 | | logger | | 查看和修改 logger | | getstatic | | 查看类的静态属性 | | ognl | | 执行 ognl 表达式 | | mbean | | 查看 Mbean 的信息 | | heapdump | | 类似 jmap 命令的 heap dump 功能 | | | --live | 生成存活的堆 dump 文件 |

> class/classloader 相关

| 指令 | 选项 | 作用 | | ----------- | -- | ------------------------------------------------------------------------------------- | | sc | | 查看 JVM 已加载的类信息 | | | -d | 输出当前类的详细信息，包括这个类所加载的原始文件来源、类的声明、加载的 Classloader 等详细信息。如果一个类被多个 Classloader 所加载，则会出现多次 | | | -E | 开启正则表达式匹配，默认为通配符匹配 | | | -f | 输出当前类的成员变量信息(需要配合参数 `-d` 一起使用) | | | -X | 指定输出静态变量时属性的遍历深度，默认为 0，即直接使用 toString 输出 | | sm | | 查看已加载类的方法信息 | | | -d | 展示每个方法的详细信息 | | | -E | 开启正则表达式匹配,默认为通配符匹配 | | jad | | 反编译指定已加载类的源码 | | mc | | 内存编译器，内存编译 .java 文件为 .class 文件 | | retransform | | 加载外部的 .class 文件，retransform 到 JVM 里 | | redefine | | 加载外部的 .class 文件，redefine 到 JVM 里 | | dump | | dump 已加载类的 byte code 到特定目录 | | classloader | | 查看 classloader 的继承树、urts、类加载信息，使用 classloader 去调 getResource | | | -t | 查看 classloader 的继承树 | | | -l | 按类加载实例查看统计信息 | | | -c | 用 classloader 对应的 hashcode 来查看对应的 Jar urls |

如：

`sc -d cn.kele.jprofiler # 查看 jprofiler 的类信息 sm -d java.lang.String # 查看 String 的方法信息 jad java.lang.String # 查看 String 的源码(反编译) mc /opt/HelloWorld.java # 编译成 HelloWorld.class 文件 retransform /opt/HelloWorld.class # 将 Class 文件放到 JVM 里 classloader # 查看 classloader 的继承树、urts、类加载信息`

> monitor/watch/trace 相关

| 指令 | 选项 | 作用 | | ------- | -- | ---------------------------------------------------- | | monitor | | 方法执行监控，调用次数、执行时间、失败率 | | | -c | 统计周期，默认值为 120 秒 | | watch | | 方法执行观测，能观察到的范围为：返回值、抛出异常、入参，通过编写 groovy 表达式进行对应变量的查看 | | | -b | 在方法调用之前观察(默认关闭) | | | -e | 在方法异常之后观察(默认关闭) | | | -s | 在方法返回之后观察(默认关闭) | | | -f | 在方法结束之后(正常返回和异常返回)观察(默认开启) | | | -x | 指定输岀结果的属性遍历深度，默认为 0 | | trace | | 方法内部调用路径，并输出方法路径上的每个节点上耗时 | | | | 执行次数限制 | | stack | | 输出当前方法被调用的调用路径 | | tt | | 方法执行数据的时空隧道，记录下指定方法每次调用的入参和返回信息，并能对这些不同的时间下调用进行观测 |

如：

`monitor -c 5 cn.kbt.java.Picture <init> # 监控 init 构造器，每隔 5 秒输出一次信息 watch cn.kbt.java.Picture <init>`

> 其他

| 指令 | 作用 | | --------- | ------------------------------ | | jobs | 列出所有 job | | kill | 强制终止任务 | | fg | 将暂停的任务拉到前台执行 | | bg | 将暂停的任务放到后台执行 | | grep | 搜索满足条件的结果 | | plaintext | 将命令的结果去除 ANSI 颜色 | | wc | 按行统计输出结果 | | options | 查看或设置 Arthas 全局开关 | | profiler | 使用 async -profiler 对应用采样，生成火焰图 |

### Java Misssion Control ###

> 官方地址：`https://github.com/JDKMissionControl/jmc`

在 Oracle 收购 Sun 之前，Oracle 的 JRockit 虚拟机提供了一款叫做 JRockit Mission Control 的虚拟机诊断工具。

在 Oracle 收购 sun 之后，Oracle 公司同时拥有了 Hotspot 和 JRockit 两款虚拟机。根据 Oracle 对于 Java 的战略，在今后的发展中，会将 JRokit 的优秀特性移植到 Hotspot 上。其中一个重要的改进就是在 Sun 的 JDK 中加入了 JRockit 的支持。

在 Oracle JDK 7u40 之后，Mission Control 这款工具己经绑定在 Oracle JDK 中发布。

自 Java11 开始，本节介绍的 JFR 己经开源。但在之前的 Java 版本，JFR 属于 Commercial Feature 通过 Java 虚拟机参数 `-XX:+UnlockCommercialFeatures` 开启。

Java Mission Control(简称 JMC) ，Java 官方提供的性能强劲的工具，是一个用于对 Java 应用程序进行管理、监视、概要分析和故障排除的工具套件。它包含一个 GUI 客户端以及众多用来收集 Java 虚拟机性能数据的插件如 JMX Console(能够访问用来存放虚拟机齐个于系统运行数据的 MXBeans)以及虚拟机内置的高效 profiling 工具 Java Flight Recorder(JFR)。

JMC 的另一个优点就是：采用取样，而不是传统的代码植入技术，对应用性能的影响非常非常小，完全可以开着 JMC 来做压测(唯一影响可能是 Full GC 多了)。

![image-20210505184358041][]

**Java Flight Recorder**

Java Flight Recorder 是 JMC 的其中一个组件，能够以极低的性能开销收集 Java 虚拟机的性能数据。与其他工具相比，JFR 的性能开销很小，在默认配置下平均低于 1%。JFR 能够直接访问虚拟机内的敌据并且不会影响虚拟机的优化。因此它非常适用于生产环境下满负荷运行的 Java 程序。

Java Flight Recorder 和 JDK Mission Control 共同创建了一个完整的工具链。JDK Mission Control 可对 Java Flight Recorder 连续收集低水平和详细的运行时信息进行高效、详细的分析。

当启用时 JFR 将记录运行过程中发生的一系列事件。其中包括 Java 层面的事件如线程事件、锁事件，以及 Java 虚拟机内部的事件，如新建对象，垃圾回收和即时编译事件。按照发生时机以及持续时间来划分，JFR 的事件共有四种类型，它们分别为以下四种：

*  瞬时事件(Instant Event) ，用户关心的是它们发生与否，例如异常、线程启动事件。
 *  持续事件(Duration Event) ，用户关心的是它们的持续时间，例如垃圾回收事件。
 *  计时事件(Timed Event) ，是时长超出指定阈值的持续事件。
 *  取样事件(Sample Event)，是周期性取样的事件。

取样事件的其中一个常见例子便是方法抽样(Method Sampling)，即每隔一段时问统计各个线程的栈轨迹。如果在这些抽样取得的栈轨迹中存在一个反复出现的方法，那么我们可以推测该方法是热点方法

![image-20210505185941373][]

![image-20210505185954567][]

![image-20210505190009274][]

![image-20210505190023099][]

![image-20210505190037354][]

![image-20210505190052561][]

![image-20210505190106004][]

### 其他工具 ###

#### Flame Graphs(火焰图) ####

在追求极致性能的场景下，了解你的程序运行过程中 CPU 在干什么很重要，火焰图就是一种非常直观的展示 CPU 在程序整个生命周期过程中时间分配的工具。火焰图对于现代的程序员不应该陌生，这个工具可以非常直观的显示出调用找中的 CPU 消耗瓶颈。

网上的关于 Java 火焰图的讲解大部分来自于 Brenden Gregg 的博客：`http://new.brendangregg.com/flamegraphs.html`。

![image-20210505190823214][]

火焰图，简单通过 x 轴横条宽度来度量时间指标，y 轴代表线程栈的层次。

#### Tprofiler ####

> 官方地址：`http://github.com/alibaba/Tprofiler`

案例： 使用 JDK 自身提供的工具进行 JVM 调优可以将下 TPS 由 2.5 提升到 20(提升了 7 倍)，并准确 定位系统瓶颈。

系统瓶颈有：应用里释态对象不是太多、有大量的业务线程在频繁创建一些生命周期很长的临时对象，代码里有问题。

那么，如何在海量业务代码里边准确定位这些性能代码？这里使用阿里开源工具 Tprofiler 来定位 这些性能代码，成功解决掉了 GC 过于频繁的性能瓶预，并最终在上次优化的基础上将 TPS 再提升了 4 倍，即提升到 100。

*  Tprofiler 配置部署、远程操作、 日志阅谈都不太复杂，操作还是很简单的。但是其却是能够 起到一针见血、立竿见影的效果，帮我们解决了 GC 过于频繁的性能瓶预。
 *  Tprofiler 最重要的特性就是能够统汁出你指定时间段内 JVM 的 top method 这些 top method 极有可能就是造成你 JVM 性能瓶颈的元凶。这是其他大多数 JVM 调优工具所不具备的，包括 JRockit Mission Control。JRokit 首席开发者 Marcus Hirt 在其私人博客《 Lom Overhead Method Profiling cith Java Mission Control》下的评论中曾明确指出 JRMC 井不支持 TOP 方法的统计。

#### Btrace ####

常见的动态追踪工具有 BTrace、HouseHD(该项目己经停止开发)、Greys-Anatomy(国人开发 个人开发者)、Byteman(JBoss 出品)，注意 Java 运行时追踪工具井不限干这几种，但是这几个是相对比较常用的。

BTrace 是 SUN Kenai 云计算开发平台下的一个开源项目，旨在为 java 提供安全可靠的动态跟踪分析工具。先看一卜日 Trace 的官方定义：

![image-20210505192042974][]

大概意思是一个 Java 平台的安全的动态追踪工具，可以用来动态地追踪一个运行的 Java 程序。BTrace 动态调整目标应用程序的类以注入跟踪代码(“字节码跟踪“)。

> 其他工具

**YourKit**

**JProbe**

**Spring Insight**

[image-20210505141631635]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/df33e8a798d548ac94986b50dc0c5fd9.png
[image-20210505141726143]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/63a8c0a81eb7481da294b4f75adb5b01.png
[image-20210505141924211]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/0d2206e73dd64bdeb378efaad4f0e41c.png
[image-20210505141950000]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/e28c60a170e64b8982a31220b1ffad08.png
[image-20210505142050157]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/7b241fc86a1f4d2e9312cde1aa238425.png
[image-20220131224447624]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/04076e3668ca48c3bacb3be79f0b3672.png
[image-20220131224552415]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/103ffe0d83ec409ea3e25ef948ae7a2c.png
[image-20220131225514738]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/b916f003f92f45a787396a3e329d1da3.png
[image-20220131225731574]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/bcb7f9e3162448b681dd1ada0cc42c8d.png
[image-20220131225659672]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/bc0f46e24b0a48ea8e307f1a54adb607.png
[image-20220131232928306]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/90746b99502b455b924587818ff74b0e.png
[image-20220131232636697]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/cc38af7270244f4383195438a3d77814.png
[image-20220131232737535]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/7b0b95ce706045749558a7b2547aa75c.png
[image-20220131233225517]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/5ac0e7d33bda47888eb9d9686388423e.png
[image-20220131233533551]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/b1f497becadd4215991409ace4a2315e.png
[image-20220131233645314]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/0934b96a636a4e0e8c2cd020117ff10e.png
[image-20220131233915003]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/c54eacd66b094bbcbdcdbde039728212.png
[image-20220131234401041]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/82929e82f4c34175aab7a1612be5f573.png
[image-20220131234920860]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/ebf47812ebe04fac8be070c8bf2a997a.png
[image-20220201003432711]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/bbf2bfe53b8b46f9b37fbb29ff58d0f7.png
[image-20220201003650210]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/7a8184a810264548b22fcebf94cf428f.png
[image-20220201003643235]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/a3af2b668bbf4173a61a0a57e8a447fc.png
[image-20220201005307683]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/29db67c8cc49406091c4a70dcd7ea22a.png
[image-20220201010504721]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/1c7da1b61ded498d951f92621ca2e041.png
[image-20220201010932876]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/990f00a94a244b948cbded2636f39810.png
[image-20220201012013800]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/95e99e217beb47219d52a59d077e5311.png
[image-20220201012135383]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/c5a7964374834df8adfaa71db8e94d9d.png
[image-20220201011857288]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/e59f771cc0b34c8cb1103867076fb6d5.png
[image-20220201012354238]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/acdd37b8152342b39a42c7cb475ca779.png
[image-20220201012443880]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/61ff7e0a0f36455eb866b3262c75bce9.png
[image-20220201012624399]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/de97b16649be43bc8a6c0eb06a954afb.png
[image-20220201012758369]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/f6d0743680b6443e969e59cc9fefda3e.png
[image-20220201012222622]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/0b6be76eb1c948cfbaf12a8e152830e2.png
[image-20210505152542224]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/8d218fc668c54f47ade3b19d3b490cba.png
[image-20210505152704141]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/a97517e540b944b595ed83cbe84990b3.png
[image-20210505160114618]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/985d71ec27b4483593755f59537b6566.png
[image-20220201160456212]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/261655503a464d3985f9de729f16e65e.png
[image-20210505160423289]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/b67a3e4c6c16418db3f092153057fe62.png
[image-20220201162722104]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/7f222acea1b642cd92062193d813f73d.png
[image-20210505164521410]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/baeeb69223de4d04aedc043db856cf8b.png
[image-20220201163821835]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/4aa84bb326ab4f348ddf62b7fde8d99a.png
[image-20210505164815324]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/ff2192eff0174b9f83bfc6ad671278f5.png
[image-20210505164945192]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/e55860d458ea4c528d3ff53d0d095b92.png
[image-20210505165010529]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/3d9eefba4dc4431eb409ed401f24d5dc.png
[image-20210505165128212]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/12e03810c5ac462d9a92c29b804bbe02.png
[image-20210505165249919]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/6b6ce8f533ab41e08abd968ae15cb117.png
[image-20220201164328735]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/db91d4bb9ea34f0685563267e35403fa.png
[image-20210505164554298]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/52052f5d999d445b9fd6dd386edd2507.png
[image-20210505165519790]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/8a5c1a8e68574d75830489ba7cdc2e70.png
[Link 1]: https://notes.youngkbt.cn/java/jvm/monitoring-diagnostic-tools/#%E5%A0%86%E9%81%8D%E5%8E%86-heap-walker
[image-20210505165710620]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/62232be504da4dc2aaec564f3c9356f2.png
[image-20210505165823201]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/e8a76142520345529ae07b4f7e378c05.png
[image-20210505170055722]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/02bfc06149d7437cb7996d3a30908bff.png
[image-20210505170141278]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/cd6497d003c942d4933d654631eea55f.png
[image-20220201165337435]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/b32bbfefd8674757a0a8d8b09bfbe1b2.png
[image-20210505170739972]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/f9f87a0a3a5345efa8f9ca4ba8515ace.png
[image-20220201170051789]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/3ef73e2d313c463d95304d10cc1ded59.png
[image-20220201170106558]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/b1641924b53f486cb025c7391d52103d.png
[image-20220201170352569]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/22145a988e43415e93a63b8baefa663e.png
[image-20220201170506350]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/dc06ddcc88f94eb38c5e4204ce7dbe7b.png
[image-20220201172653188]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/7d0264e6c3cd44229a8cf7a8017a0f29.png
[image-20210505184358041]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/b257eacf91e849c5a017255f65e47667.png
[image-20210505185941373]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/335f2342737b4866ae08d56f4ae5798d.png
[image-20210505185954567]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/4165642f163f4ee8971a340c7667584f.png
[image-20210505190009274]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/91306ea2d01f4a5482dcd367f7d6796e.png
[image-20210505190023099]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/223f7afae3d04e838acaf77f9c29a4d3.png
[image-20210505190037354]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/a94ca7d295c647889dd06e994a043d66.png
[image-20210505190052561]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/bbbc8bfbd1e6401e9db6b435e63d76cc.png
[image-20210505190106004]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/eedd52a3be344996bec8bf86025cfd88.png
[image-20210505190823214]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/ed0558331982482b956d75f43b41a88c.png
[image-20210505192042974]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/4063da3e597142578001f45018f7370e.png