Idea安装VisualGC插件手把手教程

1.简介

  开发阶段实时监测，自己的JVM信息，实时可视化 Hotspot JVM 垃圾回收监控工具, 支持查看本地和远程JVM进程, 支持G1 and ZGC算法。

整个界面主要分为四个区域，分别为：Spaces、Graphs、Histogram和JVM浏览器。

如果需要不依赖IDEA单独运行, 请移步: VisualGC 3.0 独立运行增强版, 支持JDK 8

1. **停止监控 按钮: **点击后会停止当前JVM进程的GC监控.
2. JVM 浏览器窗口：
   呈现了当前探测到的所有 Java 进程列表, 双击即可进入垃圾回收监控界面。
3. Spaces/空间窗口：
   呈现了程序运行时我们比较关注的几个区域的内存使用情况

应用程序信息： 显示了当前进程的命令行执行参数等详细信息。

• Metaspace： 方法区，如果JDK1.8之前的版本，就是Perm，JDK7和之前的版本都是以永久代(PermGen)来实现方法区的，JDK8之后改用元空间来实现(MetaSpace)。
• Old： 老年代
• Eden: 新生代Eden区 (伊甸园, 指代所有对象最初产生的地方)
• S0和S1：新生代的两个 Survivor(存活) 区

1. Graphs/图表窗口：
   该窗口区域包含8个以上的图表，以时间为横坐标动态展示各个指标的运行状态

下面从上往下对各个图表及其状态进行说明

• Compile Time：编译情况 24266 compoles - 39.416s 表示编译总数为24266，编译总耗时为39.416s。 一个脉冲表示一次JIT编译，脉冲越宽表示编译时间越长。
• Class Loader Time：类加载情况 49052 loaded，39 unloaded - 29.937s表示已加载的数量为49052，卸载的数量为39，耗时为29.537s。
• GC Time：总的（包含新生代和老年代）gc情况记录 123 collections，859.203ms Last Cause：Allocation Failure表示一共经历了123次gc(包含Minor GC和Full GC)，总共耗时859.203ms。

GC 明细时间的执行情况记录 这里会随着JVM使用的GC算法的不同, 显示一到多个GC详情图表。

• Eden Space：新生代Eden区内存使用情况 (200.00M，34.125M): 31.52M，109 collections，612.827ms表示Eden区的最大容量为200M，当前容量为34.125M，当前已使用31.52M，从开始监控到现在在该内存区域一共发生了109次gc(Minor GC)，gc总耗时为612.827ms。
• Survivor 0和Survivor 1：新生代的两个Survivor区内存使用情况 (25.000M，4.250M):1.757M表示该Survivor区的最大容量为25M（默认为Eden区的1/8），当前已用1.757M。
• Old Gen：老年代内存使用情况 (500.000M,255.195M):206.660M,14 collections，246.375ms表示老年区的最大容量为500M，当前容量为255.195M，当前已用206.660M，从开始监控到现在在该内存区域一共发生了14次gc(Full GC)，gc总耗时为246.375ms，换算下可以看出单次Full GC要比Minor GC耗时长很多。
• Metaspace：方法区内存使用情况 (1.053G,278.250M):262.345M表示方法区最大容量为1.053G,当前容量为278.250M,当前使用量为262.345MM。

1. Histogram/存活直方图窗口：
   Histogram窗口是对当前正在被使用的Survivor区内存使用情况的详细描述，

• Tenuring Threshold： 我们知道Survivor区中的对象有一套晋升机制，就是其中的每个对象都有一个年龄标记，每当对象在一次Minor GC中存活下来，其年龄就会+1，当对象的年龄大于一个阈值时，就会进入老年代，这个阈值就是Tenuring Threshold，要注意这个值不是固定不变的，一般情况下Tenuring Threshold会与Max Tenuring Threshold大小保持一致，可如果某个时刻Servivor区中相同年龄的所有对象的内存总等于Survivor空间的一半，那Tenuring Threshold就会等于该年龄，同时大于或等于该年龄的所有对象将进入老年代。
• Max Tenuring Threshold： 表示新生代中对象的最大年龄值，这个值在JDK1.8中默认为6，在JDK1.7及之前的版本中默认为15，可以通过参数-XX:MaxTenuringThreshold来指定。
• Desired Survivor Size： Survivor空间大小验证阈值(默认是survivor空间的一半)，用于给Tenuring Threshold判断对象是否提前进入老年代。
• Current Survivor Size： 当前Survivor空间大小，单位为字节（Byte，B）。
• Histogram柱状图： 表示Survivor中不同年龄段对象分布。

1.1安装方式

1.1.1在线安装

  在线安装需求确保你的电脑可以正常上网，不然是内网、vpn网络等在Marketplace中是加载不出插件来的

  本文讲解的是在线安装教程，plugins中的应用的Marketplace中输入VisualGC搜索进行安装重启即可。

1.1.2离线安装

  离线安装的只需要下载对应的安装包，然后在

JDK VisualGC官网离线下载：

https://plugins.jetbrains.com/plugin/14557-jdk-visualgc/versions

  plugins中选择从本地磁盘安装插件即可

2.idea插件Marketplace不显示也搜索不到插件的问题及解决办法

  解决方法只需要设置SystemSettings中HTTP Proxy中选择Auto-detect-proxy-settings确定即可。

3.plugins中输入VisualGC搜索安装插件后重启

4.安装VisualGC插件遇到的问题

4.1idea版本

  idea版本需要去官方下载安装，然后输入license激活即可，这一步骤省略，我本机上是JDK8的java环境。

4.2Help中找到Register-Plugins激活插件

激活后：

4.3打开一个项目点击VisualGC模式启动


  如上图所示：第一个是：run启动，第二个是：debug启动

  正常启动会弹出如下弹框：

  选择java进程点击进入可视化监控界面

  在这里有一个bug，然后会弹出一个idea的警告弹框说是有一个issue的解决方法：点击弹框中的链接：

https://plugins.jetbrains.com/plugin/14557-jdk-visualgc/idea-2022-2-fix

  配置idea的jvm参数

--add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
--add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor.event=ALL-UNNAMED
--add-exports=jdk.internal.jvmstat/sun.jvmstat.perfdata.monitor=ALL-UNNAMED

  idea配置jvm参数，打开进入项目界面，点击Help中的Edit Custom VM Options.加入上面的参数后保存重启idea后就可以以VisualGC模式启动正确弹框了。

5.总结

  VisualGC工具也可以远程监控其它jvm的运行的，

  分享几款超好用的JVM调优工具，建议收藏：

https://cloud.tencent.com/developer/article/2412196

  还有jdk自带的那几个工具及命令：

https://blog.csdn.net/attcat/article/details/127481700
https://cloud.tencent.com/developer/article/2372144
https://blog.51cto.com/u_12947/8551237
https://blog.csdn.net/longool/article/details/139712664

  Java jvm工具 的相关内容:

https://www.aliyun.com/sswb/1577069.html?spm=5176.26934562.main.3.3f773147FXXtDy

  还有阿里搞的那个arthas教程及官网:

https://blog.csdn.net/qq_27706119/article/details/136233125

  arthas官网:

https://arthas.aliyun.com/

  使用以上的方法可以在本地来进行模拟观察jvm运行的垃圾回收可视化监控，从而来进行整段问题和jvm参数调优，生产还是使用Arthas比较靠谱一点，使用jdk自带的工具搞不好会把线上的jvm干卡死了，这个还是有一定的风险的，所以需要经过充分的验证和观察才可以去生产搞的，使用idea安装VisualGC插件可以在本地运行可视化监控，使用JMeter来压测接口，然后通过VisualGC插件可视化监控jvm的对象在每个代中的情况及垃圾回收等情况，看看是否存在接口性能问题，可以进行优化处理，提高程序接口的性能。

  还有一个很好玩的东西：

  图文并茂教你学会使用 IntelliJ IDEA 进行远程调试：

https://cloud.tencent.com/developer/article/1551668

  下面是我之前的实践总结：

  配置一个idea的Remote JVM Debug：

  构建应用镜像的dockerfile：关于如何编写构建dockerfile，我之前的文章里面也有分享的，有兴趣的可以去看下之前的文章：

FROM openjdk:8-jre-alpine-apm
VOLUME /tmp
ADD target/*.jar xxxx.jar
RUN echo "Asia/Shanghai" > /etc/timezone
EXPOSE 9001
ENTRYPOINT java ${JAVA_OPTS} ${JAVA_PARAMETERS} ${SERVER_NAME} -jar /xxx.jar

  然后启动容器命令：

docker run -d -p ${port}:${port} --net=host -e JAVA_OPTS="-Xms512m -Xmx512m -Xss256K -Xdebug -Xrunjdwp:transport=dt_socket,suspend=n,server=y,address=9001" --name xxx  image_tagxxxx

  配置idea的远程debug之后，启动好服务器上的程序，启动Remote JVM Debug，点击debug启动：容器映射主机的端口一致，且主机端口对外可以访问到或者是内网可以访问到(cmd打开命令行：使用telnet ip port是通的，这个才可以玩，否则，网络不同就玩不了的了，如果是虚拟机需要打开对应端口的防火墙，如果是云服务器需要配置安全组将TCP端口开发外网可用(这种一般很危险，可以使用vpn组建一个内网，云服务器和公司的网络都是内网，可以使用OpenVpn组建内网专业vpn网络，这种访问就是安全的，只需要管理好vpn链接账号和密码即可))

  保证本地idea应用代码和服务器部署的应用代码一致，然后在本地对应接口上打上断点，请求服务器上的这个接口的地址，服务器上的请求就转发到本地idea上来了，这种就可以很方便的远程jvm进行dubug了，刚才我去试了下，发现之前部署在服务器上的那个应用时间长了之后，idea使用Remote JVM Debug启动就链接不上了，然后我就重新使用jekiens打了一个包，重新部署之后，启动本地idea项目的Remote JVM Debug就可以正常监听到服务器上远程的jvm了：

  然后浏览器访问一个接口：

  本地idea项目断点正常进入：

  本次分享到此结束，都是日常中的一些好玩的东西，把这些东西都串联到一起就更好玩了，举一反三，触类旁通，也是解决问题的利器，希望我的分享能给你启发和帮助，请一键三连，么么么哒!