Java生产环境下性能监控与调优详解（七）JVM层GC调优

╰+攻爆jí腚メ 2023-01-17 14:54 185阅读 0赞

主要内容

*  JVM的内存结构
 *  垃圾回收算法
 *  垃圾收集器
 *  可视化GC日志分析工具
 *  Tomcat的GC调优实战

## 1.JVM的内存结构 ##

### 1.1 运行时数据区，主要包括以下部分 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70][]

（1）程序计数器PC Register

JVM支持多线程同时运行，每一个线程都有自己的PC Register，线程正在执行的方法叫做当前方法，如果是java代码，PC Register里面存放的就是正在**执行的指令的地址**，如果是C代码，则为空。

（2）虚拟机栈JVM Stacks

Java虚拟机栈（Java Virtual Machine Stacks）是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：**每个方法在执行的时候都会创建一个栈帧**，用于存储局部变量表、操作数表、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应这一个栈帧在虚拟机中入栈到出栈的过程。

……

### 1.2 JVM内存结构 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 1][]

## 2.常见的垃圾回收算法 ##

**2.1 思想： 枚举根节点，做可达性分析**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 2][]

**2.2 根节点：**类加载器、Thread、虚拟机栈的本地变量表、static成员、常量引用、本地方法栈的变量等等

### 2.3 常用算法 ###

（1）标记清除

算法：分为“标记”和“清除” 两个阶段：首先标记处所有需要回收的对象，在标记完成后统一回收所有。

**缺点：**

*  **效率不高。标记和清除两个过程的效率都不高**
 *  **产生碎片。碎片太多会导致提前GC**

（2）复制

算法：它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

优缺点：实现简单，运行高效，但是空间利用率低。

（3）标记整理

算法： 标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

优缺点：没有了内存碎片，但是整理内存比较耗时。

### 2.4 分代垃圾回收 ###

*  Young区用复制算法
 *  Old区用标记清除或者标记整理

### 2.5 对象分配 ###

*  对象优先在Eden区分配
 *  大对象直接进入老年代： -XX:PretenureSizeThreshold
 *  长期存活对象进入老年代：-XX:mAXtenuringThreshold

## 3.垃圾收集器 ##

### 3.1 常见的收集器 ###

*  串行收集器Serial：Serial、Serial Old
 *  并行收集器Parallel：Parallel Scavenge、Parallel Old，吞吐量
 *  并发收集器Concurrent：CMS、G1，停顿时间

### 3.2 并行 VS 并发 ###

（1）并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。适合科学计算、后台处理等弱交互场景。

（2）并发（Concurrent）：指哟用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），垃圾收集线程在执行的时候不会停顿用户程序的运行。适合对响应时间有要求的场景，比如：Web.

### 3.3 停顿时间 VS 吞吐量 ###

（1）停顿时间：垃圾收集器做垃圾回收中断应用执行的时间。

\-XX:MaxGCPauseMillis

（2）吞吐量：花在垃圾收集的时间和花在应用时间的占比。

-XX:GCTimeRatio=<n>，垃圾收集时间占： 1/1+n

### 3.4 串行收集器 ###

（1）启用：

-XX:+UseSerialGC -XX:+UseSerialOldGC

使用以上语句后，Young区和Old区都会使用串行收集器

### 3.5 并行收集器 ###

（1）吞吐量优先

（2）-XX:+UseParallelGC , -XX:+UseParallelOldGC 该字段将Young区、Old区同时启用并行收集器

（3）Server模式下的默认收集器

并行收集器的默认启用： JVM根据当前系统的内存、CPU来决定Clien模式还是Server模式。如果内存大于2G以上、双核以上，它就认为是Server模式。在Server模式下，它会自动启用**并行垃圾收集器。**

（4）开启并行垃圾收集器

默认情况下启用并行垃圾回收器，所以要注释掉自动添加的垃圾回收配置

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 3][]

在不设置收集器指令的情况下，启动tomcat和程序，可以得到结果如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 4][]

### 3.6 并发收集器 ###

（1）包括 CMS、G1两种收集器

（2）特点：响应时间优先

（3）开启脚本：

*  CMS： XX:+UseConcMarkSweepGC -XX:+UseParNewGC
 *  G1: -XX:+UseG1GC

（4）开启CMS/G1收集器

设置收集器指令

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 5][]

重启程序，用jinfo打印JVM的垃圾收集器信息

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 6][]

### 3.7 垃圾收集器搭配 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 7][]

上图为Young区、Old区所能使用的收集器。Young区、Old区有连线的部分是可以搭配使用的

### 3.8如何选择垃圾收集器 ###

*  优先调整堆的大小让服务器自己来选择
 *  如果内存小于100M，使用串行收集器
 *  如果是单核，并且没有停顿时间的要求，串行或者JVM自己选
 *  如果允许停顿时间超过1秒，选择则并行或者JVM自己选
 *  如果响应时间最重要，并且不能超过1秒，使用并发收集器

## 4.垃圾收集器 ##

### 4.1 并行垃圾收集器 —— Parallel Collector ###

（1）普通指令

-XX:+UseParallelGC 手动开启，Server默认开启

（2）根据CPU核心数开启多个线程

-XX:ParallelGCThreads=<N>多少个GC线程

*  当CPU>8 , N=5/8
 *  当CPU<8，N=CPU

（3）收集器自适应 —— Parallel Collector Ergonomics

*  \-XX:MaxGCPauseMillis=<N>
 *  \-XX:GCTimeRatio=<N>
 *  \-Xmx<N>

该自适应会自动调整上述三个参数，直到满足其中两个参数要求，而留下一个不满足的指令。

（4）动态内存调整

*  \-XX:YoungGenerationSizeIncrement=<Y>
 *  \-XX:TenuredGenerationSizeIncrement=<T>
 *  \-XX:AdaptiveSizeDecrementScaleFactor=<D>

生产环境不建议使用上述自适应模式，推荐使用手动调整。

### 4.2 并发收集器 —— CMS Collector ###

（1）特点

*  并发收集
 *  低停顿、低延迟
 *  老年代收集器

（2）CMS垃圾收集过程

第一阶段： CMS initial mark: 初始标记Root, STW

第二阶段：CMS concurrent mark: 并发标记

第三阶段：CMS-concurrent-preclean: 并发预清理

第四阶段：CMS remark: 重新标记，STW

第五阶段：CMS concurrent sweep: 并发清除

第六阶段：CMS-concurrent-reset: 并发重置

（3）CMS的相关参数（调优）

*  \-XX:ConcGCThreads: 并发的GC线程数
 *  \-XX:+UseCMSCompactAtFullCollection: FullGC之后做压缩
 *  \-XX:CMSFullGCsBeforeCompaction: 多少次FullGC之后压缩一次
 *  \-XX:CMSInitiatingOccupancyFraction:触发FullGC
 *  \-XX:+UseCMSInitiatingOccupancyOnly:是否动态调
 *  \-XX:+CMSScavengeBeforeRemark: FullGC之前先做YGC
 *  \-XX:+CMSClassUnloadingEnabled: 启用回收Perm区

### 4.3 并发收集器 —— iCMS ###

*  适用于单核或者双核

### 4.4 并发收集器 —— [G1 Collector][] ###

（1）简介

> The Garbage-First (G1) collector is a server-style garbage collector, targeted for multi-processor machines with large memories. It meets garbage collection (GC) pause time goals with a high probability, while achieving high throughput. *The G1 garbage collector is fully supported in Oracle JDK 7 update 4 and later releases*.

> Garbage-First（G1）收集器是一种服务器样式的垃圾收集器，适用于具有大内存的多处理器计算机。它极有可能满足垃圾回收（GC）暂停时间目标，同时实现高吞吐量。*Oracle JDK 7更新4和更高版本完全支持G1垃圾收集器*。JDK9的默认收集器。

（2）G1堆结构

堆是一个内存区域，分为多个固定大小的区域。

（3）G1堆分配

实际上，这些区域被映射为伊甸园，幸存者和旧时代空间的逻辑表示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 8][]

图片中的颜色显示了哪个区域与哪个角色相关联。将活动对象从一个区域撤离（即复制或移动）到另一个区域。区域被设计为在停止或不停止所有其他应用程序线程的情况下并行收集。

如图所示，可以将区域分配到伊甸园，幸存者和旧时代区域。此外，还有第四种类型的物体，称为“巨大区域”。这些区域旨在容纳标准区域大小的50％或更大的对象。它们存储为一组连续区域。最后，最后一种类型的区域将是堆的未使用区域。

**注意：**在撰写本文时，尚未优化收集庞大对象的过程。因此，应避免创建这种大小的对象。

本小节摘录自Oracle官网。

（4）G1的几个概念

*  Region
 *  SATB:  Snapshot-At-The-Beginning ，它是通过Root Tracing 得到的，GC开始时候存活对象的快照。
 *  RSet：记录了掐Region中的对象引用本Region中对象的关系，属于points-into结构（谁引用了我的对象）

### 4.5 并发收集器 ——G1: YoungGC ###

*  新对象进入Eden区
 *  存活对象拷贝到Survivor区
 *  存活时间达到年龄阈值时，对象晋升到Old区

### 4.6 并发收集器 ——G1: MixedGC ###

（1）不是FullGC，回收所有的Young和部分Old

（2）global concurrent marking（全局并发标记）

1.  Initial marking phase: 标记GC Root，STW
2.  Root region scanning phase: 标记存活Region
3.  Concurrent marking phase: 标记存活的对象
4.  Remark phase: 重新标记，STW
5.  Cleanup phase: 部分STW

（3）MixwdGC时机

有以下参数决定：

*  InitiatingHeapOccupancyPercent（并发标记）：

堆占有率达到这个数值则触发global concurrent marking ，默认45%

*  G1HeapWastePercent:

在global concurrent marking结束之后，可以知道区有多少空间要被回收，在每次YGC之后和再次发生Mixed GC之前，会**检查**垃圾占比**是否**达到此参数，只有达到了，下次才**会发生Mixed GC**.

*  G1MixedGCLiveThresholdPercent

Old区的region被回收时候的存活对象占比

*  ……

## 5. 可视化GC日志分析工具 ##

GC调优的对象： 吞吐量、响应时间。

### 5.1 可视化GC日志分析工具 ###

*  在线工具： http://gceasy.io/
 *  GCViewer

### 5.2 打印日志相关参数 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 9][]

### 5.3 添加参数到配置文件 Cataline.conf ###

![20210430092419926.png][]

重新程序后，会在tomcat的logs目录下生成gc.log，查看gc.log信息：

![20210430092649454.png][]

## 6.客户化工具分析GC日志 ##

### 6.1 gceasy ###

（1）下载

官网 [https://gceasy.io/][https_gceasy.io]

（2）上传本地gc.log压缩包进行分析

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 10][]

（3）使用

参考官网：[https://gceasy.io/][https_gceasy.io]

### 6.2 GCViewer ###

（1）官网—— [https://github.com/chewiebug/GCViewer][https_github.com_chewiebug_GCViewer] ，下载工程

（2）解压 压缩包，在根目录下打包：

![20210430113134466.png][]

打包后，在target目录下生成一个 jar包，直接双击 jar包启动工具

（3）打开工具

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 11][]

（4）分析结果：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 12][]

内存、响应时间：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 13][]

导致GC的tap:

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 14][]

## 7. ParallelGC调优 ##

（1）调优参数

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 15][]

（2）调优示例

默认不添加调优参数：

![20210430101438757.png][]

GC的吞吐量和响应时间：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 16][]

第一次调优：

![2021043010182936.png][]

新增元空间调优参数 ，调优结果如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 17][]

根据调优结果分析，性能明显提升了。

*  吞吐量： 从96.78% 提升到98.13%
 *  停顿时间：最大、最小值都降低了
 *  YGC：发生次数降低1
 *  FullGC: 为0次

吞吐量和停顿时间对单个线程单次效率影响，YGC、FullGC发生次数对所有线程效率有影响

第二次调优：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 18][]

以上新增调优参数： 吞吐量99%，最大停顿时间100。

调优结果比较：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 19][]

从结果可以看出，本次调优对性能不升反降。根据分析，发现 YGC 次数有提升，而添加的吞吐量、停顿时间参数并没有太大的变化，所以此次性能降低的因素可以归纳为 YGC 的频繁导致的。

原因：YGC 期间会阻塞吞吐量。

第三次优化：

![20210430102912287.png][]

优化参数：YGC 扩容为30

调优结果：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 20][]

从结果可以看出，吞吐量提升到98.14，而YGC降低到10。虽然停顿时间有所提升，但总体性能上是提升。

总结：性能调优就是针对相应的参数进行依次调试，知道符合对性能的优化行要求。

## 8. G1调优 ##

### 8.1 G1 GC最佳实践 ###

*  年轻代大小：避免使用-Xmn、-XX:NewRatio等显示设置Young区大小，会覆盖暂停时间目标。
 *  暂停时间目标：暂停时间不要太严苛，其吞吐量目标是90%的应用程序时间和10%的垃圾回收时间，太严苛会直接影响到吞吐量。
 *  关于MixGC调优：![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 21][]

### 8.2 G1 GC 调优 ###

（1）默认参数（未调优）：

![20210430105141168.png][]

默认参数下的结果：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 22][]

（2）第一次调优

分析存在的问题进行调优：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 23][]

上图中，所存在的都是影响性能的原因。这里选择先调优Metadata GC。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 24][]

根据当前Old区所占用内存为55.5M可知，只要将 MetaspaceSize 设置为大于该值便可以达到优化目的。如下：

![20210430110908135.png][]

设置元空间参数为64M

调优结果：  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 25][]

增大元空间后，吞吐量明显上升，并且GC发生次数也减少到42次。

（3）第二次调优：

分析还存在的问题：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 26][]

从上图可知，经过优化，因为MetaspaceSize导致的GC就没有了。而剩下的GC主要集中在YGC区域，YGC占用了 96.0%的 GC。

优化：

![20210430110943169.png][]

这里将整个堆大小提升为 128M，满足了Young只有74M发生频繁GC的优化。

调优结果：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 27][]

从结果看出，吞吐量上升，且GC发生次数也降低到39次。

### 8.3 调优总结 ###

1.  先打印出gc.log
2.  使用GCViewer来分析 gc.log 中的性能指标
3.  Event details tab查看哪些原因导致的GC![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 28][]
4.  根据原因调优——GC pauses标签内的GC原因

## 9.小结 ##

本章主要内容为：

（1）JVM的各种垃圾收集器，有并行、并发、串行三种收集器。

*  **并行：**并行收集器和应用线程之间不是并行的，而是多个垃圾收集线程之间是并行的。并行的垃圾收集器是吞吐量优先的。
 *  **并发：**垃圾收集线程和应用程序之间是并发执行的。并发垃圾收集器是响应时间优先的。

（2）评价垃圾收集器性能的2个关键指标

*  吞吐量
 *  停顿时间

（3）如何对垃圾收集器进行调优

*  主要对并行GC和G1GC进行调优。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70]: /images/20221021/abf8bc73c9ba443b8012d2702753445b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 1]: /images/20221021/6000094a579145498b4e55685baaf66e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 2]: /images/20221021/80d7fa8fca6f495ab10ed518eb130336.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 3]: /images/20221021/cb76f856414c45bcbc642f8262e298c8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 4]: /images/20221021/54afc460dd594003beb0899cb05eb256.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 5]: /images/20221021/d115ea9a989942179b696a3d4c6d5aea.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 6]: /images/20221021/9353c1be2aec4052bcf937a2d6c5490e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 7]: /images/20221021/51d4925c08794aaea204f284f53f40ec.png
[G1 Collector]: https://www.oracle.com/technetwork/tutorials/tutorials-1876574.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 8]: /images/20221021/50c99fbca88c44c38cc757c2e9e45a90.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 9]: /images/20221021/2a9c0a9374a744dcab84dc35e77abaf8.png
[20210430092419926.png]: /images/20221021/e2832d872d254742bf567f5a3f7c84e8.png
[20210430092649454.png]: /images/20221021/609636fde561472f9e10f1dc896a8bea.png
[https_gceasy.io]: https://gceasy.io/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 10]: /images/20221021/4b1913295e714671a057da344924b052.png
[https_github.com_chewiebug_GCViewer]: https://github.com/chewiebug/GCViewer
[20210430113134466.png]: /images/20221021/c74896d73e5a46b29cca743fd8ac8f31.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 11]: /images/20221021/0f8bffbdc8aa470aa0cdb46f51144f86.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 12]: /images/20221021/d3a9eb2e368f41babef0b96b44ffe876.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 13]: /images/20221021/3a6aa04b20834d9dbccb66a401ea6413.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 14]: /images/20221021/dbb3fee024154ca5b99732567ad5257c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 15]: /images/20221021/da72a461756b4d6d92369dec7ed40f19.png
[20210430101438757.png]: /images/20221021/a10a994e77994cf3ad0986b3de237aee.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 16]: /images/20221021/1c99efbff7fa44c5b488d2f01a151d49.png
[2021043010182936.png]: /images/20221021/f15120b1e3564c6881b0fd25cf6cdd92.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 17]: /images/20221021/53ee8eb4bcc443f0b517f23884867057.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 18]: /images/20221021/d27590056a1644e782fb013479b90b1e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 19]: /images/20221021/737b9568e5934e358bb8a077175202c2.png
[20210430102912287.png]: /images/20221021/f635489fce2d4988afbaf2b6951759c5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 20]: /images/20221021/4ea9fab11c6c4dbab7091c93ec51c0e1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 21]: /images/20221021/3916650bb82146e0b4ed7098992b8904.png
[20210430105141168.png]: /images/20221021/09df4d18d6b94fc7a72da4ce9757d42f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 22]: /images/20221021/a1ba127f667243a7bba4f031ca7f22de.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 23]: /images/20221021/62ac08c5696c4b7d9308984c07060ff8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 24]: /images/20221021/2d3d0f89e9d94013949fa8b0d1dbe991.png
[20210430110908135.png]: /images/20221021/9ad5cf50975a4257b34475567d9b2273.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 25]: /images/20221021/6dc05eda8e464078892d8ea767bc691b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 26]: /images/20221021/e5d54e3fe2ae44fbb781a69a60692a6e.png
[20210430110943169.png]: /images/20221021/ab5b710027f24975b3dc9a1e151eb096.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 27]: /images/20221021/4e64657bddb243699f378497754169e7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 28]: /images/20221021/84b11f8a738e425281472a33b96061f2.png