java 垃圾回收与算法

最新推荐文章于 2024-05-30 11:27:07 发布

猩球大战

最新推荐文章于 2024-05-30 11:27:07 发布

阅读量950

点赞数 1

分类专栏： jvm 文章标签： java 算法 jvm

本文链接：https://blog.csdn.net/qq_28444237/article/details/131403153

版权

jvm 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

一.垃圾回收算法

在这里插入图片描述

1.1 如何确定是否为垃圾

1.1.1 引用计数法

在 Java 中，引用和对象是有关联的。如果要操作对象则必须用引用进行。因此，很显然一个简单
的办法是通过引用计数来判断一个对象是否可以回收。简单说，即一个对象如果没有任何与之关
联的引用，即他们的引用计数都不为 0，则说明对象不太可能再被用到，那么这个对象就是可回收
对象，但是Java并没有使用引用计数法来管理内存，因为很难解决对象之间的相互循环引用问题。

public class ReferObject{
    public Object instance = null;
    private static final int TWO_MB = 2 * 1024 * 1024;
    private byte[] bigArray = new byte[4 * TWO_MB];


    public static void main(String[] args) {
        ReferObject a = new ReferObject();
        ReferObject b = new ReferObject();
        a.instance = b;
        b.instance = a;
        a = null;
        b = null;
        //假设系统在此行发生gc
        System.gc();
    }
}

java8 gc 设置：-Xms30M -Xmx30M -XX:+PrintGCDetails
在这里插入图片描述
从运行结果中可以清楚看到内存回收日志中包含“17159K->683K”，意味着虚拟机并没有因为这两
个对象互相引用就放弃回收它们，这也从侧面说明了Java虚拟机并不是通过引用计数算法来判断对象
是否存活的。

1.1.2 可达性分析

为了解决引用计数法的循环引用问题，Java 使用了可达性分析的算法。通过一系列的“GC roots”
对象作为起点搜索。如果在“GC roots”和一个对象之间没有可达路径，则称该对象是不可达的。
要注意的是。在可达性分析算法中判定为不可达的对象，也不是“非死不可”的，这时候它们暂时还处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记，随后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。假如对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，那么虚拟机将这两种情况都视为“没有必要执行”。
在这里插入图片描述
在 java 中，GC Roots的对象包括以下几种：

在虚拟机栈（栈帧中的本地变量表）中引用的对象，譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。
在方法区中类静态属性引用的对象，譬如Java类的引用类型静态变量。
在方法区中常量引用的对象，譬如字符串常量池（String Table）里的引用。
在本地方法栈中JNI（即通常所说的Native方法）引用的对象。
Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象（比如
NullPointExcepiton、OutOfMemoryError）等，还有系统类加载器。
所有被同步锁（synchronized关键字）持有的对象。
反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

除了这些固定的GC Roots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不
同，还可以有其他对象“临时性”地加入，共同构成完整GC Roots集合。所以可能会有一些特殊的GC Roots 加入。

1.2 算法

1.2.1 标记清除算法

最基础的垃圾回收算法，分为两个阶段，标注和清除。标记阶段标记出所有需要回收的对象，清除阶段回收被标记的对象所占用的空间。如图

在这里插入图片描述
从图中我们就可以发现，该算法最大的问题是内存碎片化严重，后续可能发生大对象不能找到可利用空间的问题。

1.2.2 复制算法（copying）

为了解决 Mark-Sweep 算法内存碎片化的缺陷而被提出的算法。按内存容量将内存划分为等大小的两块。每次只使用其中一块，当这一块内存满后将尚存活的对象复制到另一块上去，把已使用的内存清掉，如图：
在这里插入图片描述这种算法虽然实现简单，内存效率高，不易产生碎片，但是最大的问题是可用内存被压缩到了原
本的一半。且存活对象增多的话，Copying 算法的效率会大大降低。

1.2.3 标记整理算法(Mark-Compact)

结合了以上两个算法，为了避免缺陷而提出。标记阶段和 Mark-Sweep 算法相同，标记后不是清
理对象，而是将存活对象移向内存的一端。然后清除端边界外的对象。如图：
在这里插入图片描述

1.3 分代收集算法

分代收集法是目前大部分 JVM 所采用的方法，其核心思想是根据对象存活的不同生命周期将内存
划分为不同的域，一般情况下将 GC 堆划分为老生代(Tenured/Old Generation)和新生代(Young
Generation)。老生代的特点是每次垃圾回收时只有少量对象需要被回收，新生代的特点是每次垃
圾回收时都有大量垃圾需要被回收，因此可以根据不同区域选择不同的算法。

1.3.1 分代收集理论

弱分代假说（Weak Generational Hypothesis）：绝大多数对象都是朝生夕灭的。
强分代假说（Strong Generational Hypothesis）：熬过越多次垃圾收集过程的对象就越难以消
亡。
跨代引用假说（Intergenerational Reference Hypothesis）：跨代引用相对于同代引用来说仅占极
少数。

第三条其实是可根据前两条假说逻辑推理得出的隐含推论：存在互相引用关系的两个对象，是应该倾
向于同时生存或者同时消亡的。举个例子，如果某个新生代对象存在跨代引用，由于老年代对象难以
消亡，该引用会使得新生代对象在收集时同样得以存活，进而在年龄增长之后晋升到老年代中，这时
跨代引用也随即被消除了。

1.3.2 新生代与复制算法

目前大部分 JVM 的 GC 对于新生代都采取 Copying 算法，因为新生代中每次垃圾回收都要回收大部分对象，即要复制的操作比较少，但通常并不是按照 1：1 来划分新生代。一般将新生代划分为一块较大的 Eden 空间和两个较小的 Survivor 空间(From Space, To Space)，每次使用Eden 空间和其中的一块 Survivor 空间，当进行回收时，将该两块空间中还存活的对象复制到另一块 Survivor 空间中。

HotSpot虚拟机默认Eden和Survivor的大小比例是8∶1。也即每次新生代中可用内存空间为整个新
生代容量的90%（Eden的80%加上一个Survivor的10%），只有一个Survivor空间，即10%的新生代是会被“浪费”的。
在这里插入图片描述

1.3.3 老年代与标记整理算法

而老年代因为每次只回收少量对象，因而采用 Mark-Compact 算法。

JAVA 虚拟机提到过的处于方法区的永生代(Permanet Generation)，它用来存储 class 类，常量，方法描述等。对永生代的回收主要包括废弃常量和无用的类。
对象的内存分配主要在新生代的 Eden Space 和 Survivor Space 的 From Space(Survivor 目前存放对象的那一块)，少数情况会直接分配到老生代。
当新生代的 Eden Space 和 From Space 空间不足时就会发生一次 GC，进行 GC 后，Eden Space 和 From Space 区的存活对象会被挪到 To Space，然后将 Eden Space 和 From Space 进行清理。
如果 To Space 无法足够存储某个对象，则将这个对象存储到老生代。
在进行 GC 后，使用的便是 Eden Space 和 To Space 了，如此反复循环。
当对象在 Survivor 区躲过一次 GC 后，其年龄就会+1。默认情况下年龄到达 15 的对象会被移到老生代中。

1.4 GC分代收集算法和分区收集算法

1.4.1分代收集算法

当前主流 VM 垃圾收集都采用”分代收集”(Generational Collection)算法, 这种算法会根据对象存活周期的不同将内存划分为几块, 如 JVM 中的新生代、老年代、永久代，这样就可以根据各年代特点分别采用最适当的 GC 算法

1.4.2 在新生代-复制算法

每次垃圾收集都能发现大批对象已死, 只有少量存活. 因此选用复制算法, 只需要付出少量存活对象的复制成本就可以完成收集.

1.4.3 在老年代-标记整理算法

因为对象存活率高、没有额外空间对它进行分配担保, 就必须采用“标记—清理”或“标记—整理”算法来进行回收, 不必进行内存复制, 且直接腾出空闲内存.

1.4.4 分区收集算法

分区算法则将整个堆空间划分为连续的不同小区间, 每个小区间独立使用, 独立回收. 这样做的好处是可以控制一次回收多少个小区间 , 根据目标停顿时间, 每次合理地回收若干个小区间(而不是整个堆), 从而减少一次 GC 所产生的停顿。

二. GC 垃圾收集器

下图展示了七种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配
使用[1]，图中收集器所处的区域，则表示它是属于新生代收集器抑或是老年代收集器。接下来笔者将
逐一介绍这些收集器的目标、特性、原理和使用场景，并重点分析CMS和G1这两款相对复杂而又广泛使用的收集器，深入了解它们的部分运作细节。

[1].这个关系不是一成不变的，由于维护和兼容性测试的成本，在JDK 8时将Serial+CMS、
ParNew+Serial Old这两个组合声明为废弃（JEP 173），并在JDK 9中完全取消了这些组合的支持（JEP214）。
在这里插入图片描述

2.1 Serial 垃圾收集器（单线程、复制算法）

Serial收集器是最基础、历史最悠久的收集器，曾经（在JDK 1.3.1之前）是HotSpot虚拟机新生代
收集器的唯一选择。大家只看名字就能够猜到，这个收集器是一个单线程工作的收集器。但它的“单线
程”的意义并不仅仅是说明它只会使用一个处理器或一条收集线程去完成垃圾收集工作，更重要的是强
调在它进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束。–“Stop The World”
在这里插入图片描述
优点:对于内存资源受限的环境，它是所有收集器里额外内存消耗（Memory Footprint）[1]最小的；对于单核处理器或处理器核心数较少的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

2.2 ParNew 垃圾收集器（Serial+多线程）

ParNew 垃圾收集器其实是 Serial 收集器的多线程版本，也使用复制算法，除了使用多线程进行垃
圾收集之外，其余的行为和 Serial 收集器完全一样，ParNew 垃圾收集器在垃圾收集过程中同样也
要暂停所有其他的工作线程。ParNew 收集器默认开启和 CPU 数目相同的线程数，
可以通过 -XX:ParallelGCThreads 参数来限制垃圾收集器的线程数。【Parallel：平行的】ParNew虽然是除了多线程外和Serial 收集器几乎完全一样，但是ParNew垃圾收集器是很多 java虚拟机运行在 Server 模式下新生代的默认垃圾收集器。
ParNew/Serial Old收集器运行示意图

2.3. Parallel Scavenge 收集器（多线程复制算法、高效）

Parallel Scavenge 收集器也是一个新生代垃圾收集器，同样使用复制算法，也是一个多线程的垃
圾收集器，它重点关注的是程序达到一个可控制的吞吐量（Thoughput，CPU 用于运行用户代码
的时间/CPU 总消耗时间，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)），
高吞吐量可以最高效率地利用 CPU 时间，尽快地完成程序的运算任务，主要适用于在后台运算而
不需要太多交互的任务。自适应调节策略也是 ParallelScavenge 收集器与 ParNew 收集器的一个
重要区别

Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间
的和一个控制自适应分配大小的参数。

-XX：MaxGCPauseMillis参数以及直接设置吞吐量大小的,参数允许的值是一个大于0的毫秒数，收集器将尽力保证内存回收花费的时间不超过用户设定值。
-XX：GCTimeRatio参数。GCTimeRatio参数的值则应当是一个大于0小于100的整数，也就是垃圾收集时间占总时间的比率，相当于吞吐量的倒数。譬如把此参数设置为19，那允许的最大垃圾收集时间就占总时间的5%（即1/(1+19)），默认值为99，即允许最大1%（即1/(1+99)）的垃圾收集时间。
-XX：+UseAdaptiveSizePolicy值得我们关注。这是一个开关参数，当这个参数被激活之后，就不需要人工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX：SurvivorRatio）、晋升老年代对象大小（-XX：PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。

2.4 Serial Old 收集器（单线程标记整理算法）

Serial Old 是 Serial 垃圾收集器年老代版本，它同样是个单线程的收集器，使用标记-整理算法，
这个收集器也主要是运行在 Client 默认的 java 虚拟机默认的年老代垃圾收集器。
在 Server 模式下，主要有两个用途：

在 JDK1.5 之前版本中与新生代的 Parallel Scavenge 收集器搭配使用。
作为年老代中使用 CMS 收集器的后备垃圾收集方案。
新生代 Serial 与年老代 Serial Old 搭配垃圾收集过程图：

新生代 Parallel Scavenge 收集器与 ParNew 收集器工作原理类似，都是多线程的收集器，都使
用的是复制算法，在垃圾收集过程中都需要暂停所有的工作线程。新生代 Parallel
Scavenge/ParNew 与年老代 Serial Old 搭配垃圾收集过程图：

2.5. Parallel Old 收集器（多线程标记整理算法）

Parallel Old 收集器是Parallel Scavenge的年老代版本，使用多线程的标记-整理算法，在 JDK1.6
才开始提供。

在 JDK1.6 之前，新生代使用 ParallelScavenge 收集器只能搭配年老代的 Serial Old 收集器，只
能保证新生代的吞吐量优先，无法保证整体的吞吐量，Parallel Old 正是为了在年老代同样提供吞
吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，可以优先考虑新生代 Parallel Scavenge
和年老代 Parallel Old 收集器的搭配策略。
新生代 Parallel Scavenge 和年老代 Parallel Old 收集器搭配运行过程图：
在这里插入图片描述

2.6. CMS 收集器（多线程标记清除算法）

Concurrent mark sweep(CMS)收集器是一种年老代垃圾收集器，其最主要目标是获取最短垃圾
回收停顿时间，和其他年老代使用标记-整理算法不同，它使用多线程的标记-清除算法。
最短的垃圾收集停顿时间可以为交互比较高的程序提高用户体验。
CMS 工作机制相比其他的垃圾收集器来说更复杂，整个过程分为以下 4 个阶段：

2.6.1. 初始标记

只是标记一下 GC Roots 能直接关联的对象，速度很快，仍然需要暂停所有的工作线程。

2.6.2. 并发标记

进行 GC Roots 跟踪的过程，和用户线程一起工作，不需要暂停工作线程。

2.6.3. 重新标记

为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记
记录，仍然需要暂停所有的工作线程。

2.6.4. 并发清除

清除 GC Roots 不可达对象，和用户线程一起工作，不需要暂停工作线程。由于耗时最长的并
发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看
CMS 收集器的内存回收和用户线程是一起并发地执行。
CMS 收集器工作过程：
在这里插入图片描述

CMS默认启动的回收线程数是（处理器核心数量+3）/4，也就是说，如果处理器核心数在四个或以上，并发回收时垃圾收集线程只占用不超过25%的处理器运算资源，并且会随着处理器核心数量的增加而下降。但是当处理器核心数量不足四个时，CMS对用户程序的影响就可能变得很大。

在JDK5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在实际应用中老年代增长并不是太快，可以适当调高参数
-XX：CMSInitiatingOccu-pancyFraction的值来提高CMS的触发百分比，降低内存回收频率，获取更好的性能。

到了JDK 6时，CMS收集器的启动阈值就已经默认提升至92%。但这又会更容易面临另一种风险：要是CMS运行期间预留的内存无法满足程序分配新对象的需要，就会出现一次“并发失败”（Concurrent Mode Failure），这时候虚拟机将不得不启动后备预案：冻结用户线程的执行，临时启用Serial Old收集器来重新进行老年代的垃圾收集，但这样停顿时间就很长了。

所以参数-XX：CMSInitiatingOccupancyFraction设置得太高将会很容易导致大量的并发失败产生，性能反而降低，用户应在生产环境中根据实际应用情况来权衡设置

2.7. G1 收集器

Garbage first 垃圾收集器是目前垃圾收集器理论发展的最前沿成果，相比与 CMS 收集器，G1 收
集器两个最突出的改进是：

基于标记-整理算法，不产生内存碎片。
可以非常精确控制停顿时间，在不牺牲吞吐量前提下，实现低停顿垃圾回收。
G1 收集器避免全区域垃圾收集，它把堆内存划分为大小固定的几个独立区域，并且跟踪这些区域
的垃圾收集进度，同时在后台维护一个优先级列表，每次根据所允许的收集时间，优先回收垃圾
最多的区域。区域划分和优先级区域回收机制，确保 G1 收集器可以在有限时间获得最高的垃圾收
集效率。

G1开创的基于Region的堆内存布局是它能够实现这个目标的关键。虽然G1也仍是遵循分代收集理
论设计的，但其堆内存的布局与其他收集器有非常明显的差异：G1不再坚持固定大小以及固定数量的
分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域（Region），每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。

虽然G1仍然保留新生代和老年代的概念，但新生代和老年代不再是固定的了，它们都是一系列区
域（不需要连续）的动态集合。G1收集器之所以能建立可预测的停顿时间模型，是因为它将Region作为单次回收的最小单元，即每次收集到的内存空间都是Region大小的整数倍，这样可以有计划地避免在整个Java堆中进行全区域的垃圾收集。更具体的处理思路是让G1收集器去跟踪各个Region里面的垃圾堆积的“价值”大小，价值即回收所获得的空间大小以及回收所需时间的经验值，然后在后台维护一个优先级列表，每次根据用户设定允许的收集停顿时间（使用参数-XX：MaxGCPauseMillis指定，默认值是200毫秒），优先处理回收价值收益最大的那些Region，这也就是“Garbage First”名字的由来。这种使用Region划分内存空间，以及具有优先级的区域回收方式，保证了G1收集器在有限的时间内获取尽可能高的收集效率。
在这里插入图片描述

G1收集器的运作过程大致可划分为以下四个步骤：

初始标记（Initial Marking）：仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS
指针的值，让下一阶段用户线程并发运行时，能正确地在可用的Region中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行Minor GC的时候同步完成的，所以G1收集器在这个阶段际并没有额外的停顿。
并发标记（Concurrent Marking）：从GC Root开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫描完成以后，还要重新处理SATB记录下的在并发时有引用变动的对象。
最终标记（Final Marking）：对用户线程做另一个短暂的暂停，用于处理并发阶段结束后仍遗留
下来的最后那少量的SATB记录。
筛选回收（Live Data Counting and Evacuation）：负责更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理掉整个旧Region的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多条收集器线程并行完成的。

2.8 ZGC收集器

首先从ZGC的内存布局说起。G1一样，ZGC也采用基于Region的堆内存布局，但
与它们不同的是，ZGC的Region（在一些官方资料中将它称为Page或者ZPage，本章为行文一致继续称为Region）具有动态性——动态创建和销毁，以及动态的区域容量大小。在x64硬件平台下，ZGC的Region可以具有如图3-19所示的大、中、小三类容量：

小型Region（Small Region）：容量固定为2MB，用于放置小于256KB的小对象。
中型Region（Medium Region）：容量固定为32MB，用于放置大于等于256KB但小于4MB的对
象。
大型Region（Large Region）：容量不固定，可以动态变化，但必须为2MB的整数倍，用于放置
4MB或以上的大对象。每个大型Region中只会存放一个大对象，这也预示着虽然名字叫作“大型
Region”，但它的实际容量完全有可能小于中型Region，最小容量可低至4MB。大型Region在ZGC的实现中是不会被重分配（重分配是ZGC的一种处理动作，用于复制对象的收集器阶段，稍后会介到）的，因为复制一个大对象的代价非常高昂。

ZGC收集器是如何工作的。ZGC的运作过程大致可划分为以下四个大的阶
段。全部四个阶段都是可以并发执行的，仅是两个阶段中间会存在短暂的停顿小阶段，这些小阶段，
譬如初始化GC Root直接关联对象的Mark Start。

并发标记（Concurrent Mark）：与G1一样，并发标记是遍历对象图做可达性分析的阶段，前后也要经过类似于G1的初始标记、最终标记（尽管ZGC中的名字不叫这些的短暂停顿，而且这些停顿阶段所做的事情在目标上也是相类似的。与G1不同的是ZGC的标记是在指针上而不是在对象上进行的，标记阶段会更新染色指针中的Marked 0、Marked 1标志位。
并发预备重分配（Concurrent Prepare for Relocate）：这个阶段需要根据特定的查询条件统计得出本次收集过程要清理哪些Region，将这些Region组成重分配集（Relocation Set）。重分配集与G1集器的回收集（Collection Set）还是有区别的，ZGC划分Region的目的并非为了像G1那样做收益优的增量回收。相反，ZGC每次回收都会扫描所有的Region，用范围更大的扫描成本换取省去G1中记忆集的维护成本。因此，ZGC的重分配集只是决定了里面的存活对象会被重新复制到其他的Region中，里面的Region会被释放，而并不能说回收行为就只是针对这个集合里面的Region进行，因为标记过程是针对全堆的。此外，在JDK 12的ZGC中开始支持的类卸载以及弱引用的处理，也是在这个阶段中完成的。
并发重分配（Concurrent Relocate）：重分配是ZGC执行过程中的核心阶段，这个过程要把重分配集中的存活对象复制到新的Region上，并为重分配集中的每个Region维护一个转发表（ForwardTable），记录从旧对象到新对象的转向关系。得益于染色指针的支持，ZGC收集器能仅从引用上明确得知一个对象是否处于重分配集之中，如果用户线程此时并发访问了位于重分配集中的对象，这次访问将会被预置的内存屏障所截获，然后立即根据Region上的转发表记录将访问转发到新复制的对象上，并同时修正更新该引用的值，使其直接指向新对象，ZGC将这种行为称为指针的“自愈”（Self-Healing）能力。这样做的好处是只有第一次访问旧对象会陷入转发，也就是只慢一次。
一个直接的好处是由于染色指针的存在，一旦重分配集中某个Region的存活对象都复制完毕后，这个Region就可以立即释放用于新对象的分配（但是转发表还得留着不能释放掉），哪怕堆中还有很多指向这个对象的未更新指针也没有关系，这些旧指针一旦被使用，它们都是可以自愈的。
并发重映射（Concurrent Remap）：重映射所做的就是修正整个堆中指向重分配集中旧对象的所
有引用，ZGC的并发重映射并不是一个必须要“迫切”去完成的任务，因为前面说过，即使是旧引用，它也是可以自愈的，最多只是第一次使用时多一次转发和修正操作。重映射清理这些旧引用的主要目的是为了不变慢（还有清理结束后可以释放转发表这样的附带收益），所以说这并不是很“迫切”。因此，ZGC很巧妙地把并发重映射阶段要做的工作，合并到了下一次垃圾收集循环中的并发标记阶段里去完成，反正它们都是要遍历所有对象的，这样合并就节省了一次遍历对象图的开销。一旦所有指针都被修正之后，原来记录新旧对象关系的转发表就可以释放掉。

三垃圾收集器日志

3.1 jdk9 之前

3.1.1 常见 gc 参数

1.查看GC基本信息

-XX: +PrintGC

2.查看GC详细信息

-XX： +PrintGCDetails

3.查看GC前后的堆、方法区可用容量变化

-XX： +PrintHeapAtGC，

4.查看GC过程中用户线程并发时间以及停顿的时间

-XX： +PrintGCApplicationConcurrentTime
-XX： +PrintGCApplicationStoppedTime

5.查看收集器Ergonomics机制（自动设置堆空间各分代区域大小、收集目标等内容，从Parallel收
集器开始支持）自动调节的相关信息。

-XX： +PrintAdaptive-SizePolicy.

6.查看熬过收集后剩余对象的年龄分布信息

-XX： +PrintTenuring-Distribution

3.2 jdk9 之后

在JDK 9以前，HotSpot并没有提供统一的日志处理框架，虚拟机各个功能模块的日志开关分布在不同的参数上，日志级别、循环日志大小、输出格式、重定向等设置在不同功能上都要单独解决。直到JDK 9，这种混乱不堪的局面才终于消失，HotSpot所有功能的日志都收归到了“-Xlog”参数上，这个参数的能力也相应被极大拓展了。

3.2.1Xlog 语法

-Xlog[:option]
    option        :=  [<what>][:[<output>][:[<decorators>][:<output-options>]]]
                       'help'
                       'disable'
    what          :=  <selector>[,...]
    selector       :=  <tag-set>[*][=<level>]
    tag-set        :=  <tag>[+...]
                       'all'
    tag           :=  name of tag
    level          :=  trace
                       debug
                       info
                       warning
                       error
    output         :=  'stderr'
                       'stdout'
                       [file=]<filename>
    decorators      :=  <decorator>[,...]
                       'none'
    decorator       :=  time
                       uptime
                       timemillis
                       uptimemillis
                       timenanos
                       uptimenanos
                       pid
                       tid
                       level
                       tags
    output-options    :=  <output_option>[,...]
    output-option     :=  filecount=<file count>
                       filesize=<file size in kb>
                       parameter=value

3.2.2配置格式

-Xlog[:[what][:[output][:[decorators][:output-options[,...]]]]]

如果不配置，默认的是：

-Xlog:all=warning:stdout:uptime,level,tags

这是一个冒号分割的配置，第一个冒号后面的就是[what]，第二个是[output]，第三个是[decorators]，第四个是逗号分割的[output-options].没有配置的部分就是默认值的对应部分，例如下面的几组配置就是等价的：

-Xlog:all=warning与-Xlog::stdout与-Xlog::::uptime,level,tags
与-Xlog:all=warning:stdout -Xlog::stdout:uptime,level,tags与 -Xlog:all=warning:stdout:uptime,level,tags

-Xlog:gc*=info与-Xlog:gc*=info:stdout:uptime,level,tags

-Xlog::file=/jvm/log/app.log::filecount=30,filesize=10M 与
-Xlog:all=warning:file=/jvm/log/app.log:uptime,level,tags:filecount=30,filesize=10M

what

主要是配置tag及level

tag

其中all代表所有的tag，其他的如下：

add，age，alloc，annotation，aot，arguments，attach，barrier，biasedlocking，blocks，bot，breakpoint，bytecode，census，class，classhisto，cleanup，compaction，comparator，constraints，constantpool，coops，cpu，cset，data，defaultmethods，dump，ergo，event，exceptions，exit，fingerprint，freelist，gc，hashtables，heap，humongous，ihop，iklass，init，itables，jfr，jni，jvmti，liveness，load，loader，logging，mark，marking，metadata，metaspace，method，mmu，modules，monitorinflation，monitormismatch，nmethod，normalize，objecttagging，obsolete，oopmap，os，pagesize，parser，patch，path，phases，plab，preorder，promotion，protectiondomain，purge，redefine，ref，refine，region，remset，resolve，safepoint，scavenge，scrub，setting，stackmap，stacktrace，stackwalk，start，startuptime，state，stats，stringdedup，stringtable，subclass，survivor，sweep，system，task，thread，time，timer，tlab，unload，update，verification，verify，vmoperation，vtables，workgang

level

主要分off，trace，debug，info，warning，error

output

stdout(Sends output to stdout)
stderr(Sends output to stderr)
file=filename(Sends output to text file(s))

有如上三种，其中指定file的话，可以使用%p变量表示当前jvm的pid，用%t表示jvm的启动时间戳。比如

输出的文件名如下：

demotest-gc-16728-2023-03-11_22-40-16.log

decorators

日志级别从低到高，共有Trace， Debug， Info， Warning， Error， Off六种级别，日志级别决定了输出信息的详细程度，默认级别为Info， HotSpot的日志规则与Log4j、 SLF4j这类Java日志框架大体上是一致的。另外，还可以使用修饰器（Decorator）来要求每行日志输出都附加上额外的内容，支持附加在日志行上的信息包括：
time：当前日期和时间。
uptime：虚拟机启动到现在经过的时间，以秒为单位。
timemillis：当前时间的毫秒数，相当于System.currentTimeMillis()的输出。
uptimemillis：虚拟机启动到现在经过的毫秒数。
timenanos：当前时间的纳秒数，相当于System.nanoTime()的输出。
uptimenanos：虚拟机启动到现在经过的纳秒数。
pid：进程ID。
tid：线程ID。
level：日志级别。
tags：日志输出的标签集。
如果不指定，默认值是uptime、 level、 tags这三个，此时日志输出类似于以下形式：

不指定的话，默认是uptime, level, and tags这三个。比如

[3.080s][info][gc,cpu        ] GC(5) User=0.03s Sys=0.00s Real=0.01s

实例

-Xlog:gc=trace:file=gctrace-%p.txt:uptimemillis,pid:filecount=3,filesize=2048

tag为gc，levle为trace，rotate文件数为3，每个文件2M，文件名为gctrace-pid.txt，decrotators为uptimemillis和pid

输出实例

[1110ms][1867] GC(2) Pause Remark 17M->17M(256M) 2.024ms
[1110ms][1867] GC(2) Finalize Live Data 0.000ms
[1110ms][1867] GC(2) Pause Cleanup 17M->17M(256M) 0.177ms
[1112ms][1867] GC(2) Concurrent Cycle 7.470ms
[2951ms][1867] GC(3) Pause Initial Mark (Metadata GC Threshold) 149M->30M(256M) 27.175ms
[2951ms][1867] GC(4) Concurrent Cycle
[2972ms][1867] GC(4) Pause Remark 32M->32M(256M) 5.132ms
[2974ms][1867] GC(4) Finalize Live Data 0.000ms
[2974ms][1867] GC(4) Pause Cleanup 32M->32M(256M) 0.214ms
[2976ms][1867] GC(4) Concurrent Cycle 25.422ms

1.查看GC基本信息 -Xlog:gc

2.查看GC详细信息-X-log:gc*，用通配符*将GC标签下所有细分过程都打印出来，如果把日志级别调整到Debug或者Trace

3.查看GC前后的堆、方法区可用容量变化 -Xlog:gc+heap=debug

4.查看GC过程中用户线程并发时间以及停顿的时间 -Xlog:safepoint

5.查看收集器Ergonomics机制,使用-Xlog:gc+ergo*=trace：

6.查看熬过收集后剩余对象的年龄分布信息,使用-Xlog:gc+age=trace