JVM监控及诊断工具-GUI篇

Mr-X～

已于 2023-10-11 09:48:45 修改

阅读量517

点赞数

分类专栏： JVM 文章标签： jvm

于 2023-10-09 17:37:54 首次发布

本文链接：https://blog.csdn.net/qq_45950109/article/details/133700086

版权

JVM 专栏收录该内容

18 篇文章 0 订阅

订阅专栏

文章目录

JVM监控及诊断工具-GUI篇

JVM监控及诊断工具-GUI篇

工具概述

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

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

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

图形化综合诊断工具
1）JDK自带工具

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

2）第三方工具

MAT：MAT(Memory Analyzer Tool) 是基于Eclipse的内存分析工具，是一个快速、功能丰富的Java heap分析工具，它可以帮助我们查找内存泄漏和减少内存消耗。
JProfiler：商业软件，需要付费。功能强大。
Arthas：Alibaba开源的Java诊断空间。深受开发者喜爱。
Btrace：Java运行时追踪工具。可以在不停机的情况下，跟踪指定的方法调用、构造函数调用和系统内存等信息。

JConsole

基本概述
从Java5开始，在JDK中自带的Java监控和管理控制台。用于对JVM中内存、线程和类等的监控，是一个基于JMX（Java management extensions）的GUI性能监控工具。
官方教程：https://docs.oracle.com/javase/7/docs/technotes/guides/management/jconsole.html

启动

jdk/bin目录下，启动jconsole.exe命令即可。
打开DOS窗口，直接输入jconsole就可以了。

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

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

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

看一下我们这里的Local本地连接，首先启动idea中的一个项目，如下图：
在这里插入图片描述
然后点击jdk\bin\jconsole.exe，如下图：

连接上之后如下图：

看一下怎么使用JConsole.exe工具去检测死锁，我们有一个如下的程序，如下：

/**
 * @author xuan
 * @create 2023/10/8
 */
public class ScannerTest {
    static Object A = new Object();
    static Object B = new Object();

    public static void main(String[] args) {
        Runnable task = new Runnable() {
            @Override
            public void run() {
                synchronized (A) {
                    try {
                        Thread.sleep(1000);
                        synchronized (B) {
                            System.out.println();
                        }
                    } catch (InterruptedException e) {
                        throw new RuntimeException(e);
                    }
                }
            }
        };
        Thread thread = new Thread(task);
        thread.start();

        synchronized (B) {
            try {
                Thread.sleep(1000);
                synchronized (A) {
                    System.out.println();
                }
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        }

    }
}

然后去JConsole工具的线程菜单栏查看，如下图：
在这里插入图片描述
点击检测死锁之后如下图：

Visual VM

jvisualvm和visual vm的区别
没什么区别，只是visual vm是单独下载的，jvisualvm是JDK自带的

基本概述

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

首页：https://visualvm.github.io/index.html

jdk中自带的有VisualVM，如下图：
在这里插入图片描述
点击打开之后的界面，如下图：

如下图：

我们这里是写了一个while循环，无限循环创造对象，所以这里一直会进行垃圾回收，如果后续遇到了垃圾回收比较频繁的情况，那肯定是那个地方出问题了。

如果我们发现我们的程序出现卡顿了，那说明可能有些方法执行时间比较长，我们可以在抽样器里面去查看，如下图：
在这里插入图片描述
在抽样器里面，点击CPU可以去查看每个方法运行所占用的时间，它会把那些占用时间比较长的方法统计出来，我们后面可以单独分析分析，为什么这个方法的运行时间会比较长？比如说上面Server服里面的printNoticeCount方法的运行时间就比较长。

再谈内存泄漏

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

内存泄漏（memory leak）的理解
严格来说，只有对象不会再被程序用到，但是GC又不能回收他们的情况，才叫内存泄漏。
但实际情况很多时候一些不太好的时间（或疏忽）会导致对象的生命周期变得很长甚至导致OOM，也可以叫做宽泛意义上的“内存泄漏”。
在这里插入图片描述
对象X引用对象Y，X的生命周期比Y的生命周期长；

那么当Y生命周期结束的时候，X依然引用着Y，这个时候，垃圾回收器是不会回收对象Y的；

如果对象X还引用着生命周期比较短的A、B、C，对象A又引用着对象a、b、c，这样就可能造成大量无用的对象不能被回收，进而占据了内存资源，造成内存内存泄漏，直到内存溢出。

内存泄漏与内存溢出的关系
（1）内存泄漏（memory leak)
申请了内存用完了不释放，比如一共有1024M的内存，分配了512M的内存一直不回收，那么可以用的内存只有521M了，仿佛泄漏了一部分；
（2）内存溢出（out of memory)
申请内存时，没有足够的内存可以使用；
可见，内存泄漏和内存溢出的关系：内存泄漏的增多，最终会导致内存溢出。

内存泄漏的分类
（1）经常发生：发生内存泄漏的代码会被多次执行，每次执行，泄漏一块内存；
（2）偶然发生：在某些特定情况下才会发生；
（3）一次性：发生内存泄漏的方法只会执行一次；
（4）隐式泄漏：一直占着内存不释放，直到执行结束；严格的说这个不算内存泄漏，因为最终释放掉了。

Java中内存泄漏的8种情况

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

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

3、内部类持有外部类
内部类持有外部类，如果一个外部类的实例对象的方法返回了一个内部类的实例对象。

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

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

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

6、改变哈希值
改变哈希值，当一个对象被存储进HashSet集合以后，就不能修改这个对象中那些参与计算哈希值的字段了。
否则，对象修改后哈希值与最初存储进HashSet集合中时的哈希值就不同了，在这种情况下，及时在contains方法使用该对象的当前引用作为的参数去HashSet集合中检索对象，也将返回找不到对象的结果，这也就会导致无法从HashSet集合中单独删除当前对象，造成内存泄漏。
这也是String为什么被设置了不可变类型，我们可以放心地把String存入HashSet，或者把String当做HashMap的key值；

7、缓存泄漏
内存泄漏的另一个常见来源是缓存，一旦把对象引用放入到缓存中，他就很容易遗忘。比如：之前项目在一次上线的时候，应用启动奇慢无比，就是因为代码中会加载一个表的数据到缓存（内存）中，测试环境只有几百条数据，但是生产环境有几百万的数据。
对于这个问题，可以使用WeakHashMap代表缓存，此种Map的特点是，当除了自身有对Key的引用外，此key没有其他引用那么此map会自动丢次此值。

在读这条信息的时候，不知道怎么就突然想到如果一个方法A里面我们有条语句Student stu = new Student();那么这个方法执行完毕之后，当后面堆里面的新生代的伊甸园区里面进行GC垃圾回收的时候，会把我们创建在堆上的Student对象给回收掉吗？会的。因为当我们的A方法执行的时候它会变成栈帧入栈，一个方法相当于是一个栈帧，然后栈帧里面的局部变量表里面有个stu变量，它的地址就是引用堆区里面的Student对象，而当我们A方法执行完毕之后，A方法对应的栈帧就从栈里面出栈了，这个时候stu这个变量就消失了，因此就不会再有对Studnet对象的引用了，这个对象也就变成了一个垃圾对象，当伊甸园区的对象满了之后Java进行GC垃圾回收的时候，会自动的把Student这个对象给回收掉。这就是java的GC垃圾回收，现在懂了之后感觉java的设计非常的神奇。

8、监听器和回调
内存泄漏第三个常见来源是监听器和其他回调，如果客户端在你实现的API中注册回调，却没有显示的取消，那么就会积聚。
需要确保回调立即被当作垃圾回收的最佳方法是只保存它的弱引用，例如将他们保存称为WeakHashMap中的键。

Arthas（阿尔萨斯）

背景
Jvisualvm和Jprofile这两款工具在业界知名度也比较高，他们的优点是可以图形界面上看到各维度的性能数据，使用这根据这些数据进行综合分析，然后判断哪里出现了性能问题。

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

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

答案就是阿里巴巴开源的性能分析神器Arthas（阿尔萨斯）

概述
Artha（阿尔萨斯）是Alibaba开源的Java诊断工具，深受开发者喜爱。在线排查问题，无需重启；动态跟踪Java代码：实时监控JVM状态。

Arthas 支持 JDK 6+，支持 Linux/Mac/Windows，采用命令行交互模式，同时提供丰富的 Tab 自动补全功能，进一步方便进行问题的定位和诊断。

当你遇到一下类似问题而束手无策，Arthas可以帮助解决：

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

官方地址：https://arthas.aliyun.com/

Arthas阿尔萨斯概述https://www.cnblogs.com/qiaoyihang/p/10533672.htmlwindows下安装Arthas 首先需要下载arthas-boot.jar,然后用java -jar的方式启动，下载命令：

curl -O https://alibaba.github.io/arthas/arthas-boot.jar
在这里插入图片描述

在运行第二句代码之前一定要启动一个java进程，否则会发生错误，因为阿尔萨斯检测不到你本地的java进程，如下图：
在这里插入图片描述
我们可以启动idea，因为idea就是一个java进程，启动完idea之后，再执行上面的命令，如下图：

因为我们在idea中启动了程序StackErrorTest，所以这里会显示出这个程序对应的进程号，然后我们如果想要检测这个程序，就输入它前面对应的编号，这里是6，然后点击回车，成功检测的情况如下图：
在这里插入图片描述

在这里插入图片描述

在Idea里面安装Arthas插件因为Arthas的命令实在是太多了，我们不能一一记住，因此idea里面为我们集成了一个arthas插件，去idea插件库里搜索arthas即可发现。这个插件可以让我们拿到各种命令，如下图：
在这里插入图片描述
使用Arthas监听我们方法参数比如我们游戏中的人物可以行走，它行走的时候调用的方法，在线运行的时候的输入参数是什么呢？我们可以通过Arthas进行分析，找到对应的方法，拿到对应的arthas命令，如下图：
在这里插入图片描述
开启arthas监听，如下图：

客户端移动游戏人物之后，我们就可以在cmd命令行窗口中监听到方法的输入参数，如下图：

使用Arthas监听我们目标方法的调用堆栈信息可以在idea中获取相关的Arthas命令，如下图：
在这里插入图片描述
然后在cmd命令行窗口使用arthas监听方法的调用堆栈如下图：
方法调用的堆栈信息

康师傅使用阿尔萨斯的例子

首先启动一个java程序，如下图：
在这里插入图片描述
然后jps命令看下这个程序的java进程号id，如下图：

紧接着使用“java -jar atrhas-boot.jar 你想要监控的java程序对应的进程号id”命令去监控下你想要监控的java程序，这里是StackErrorTest程序，它对应的java进程号id是5748，如下图：
在这里插入图片描述