首页  思维导图  详情

JVM-GC

2023-04-28 16:59:57   10  举报





AI智能生成

JVM

Java

Jvm

作者其他创作

大纲/内容

参考文献：深入理解Java虚拟机：JVM高级特性与最佳实践（第3版）

判断对象是否存活

计数器法

给每一个对象设置一个引用计数器，当有一个地方引用该对象的时候，引用计数器就+1，引用失效时，引用计数器就-1；
当引用计数器为0的时候，就说明这个对象没有被引用，也就是垃圾对象，等待回收；
缺点：无法解决循环引用的问题，当A引用B，B也引用A的时候，此时AB对象的引用都不为0，此时也就无法垃圾回收。
所以一般主流虚拟机都不采用这个方法；

可达性分析法

从GC Roots的对象向下搜索，如果一个对象到GC Roots没有任何引用链接时，说明此对象不可用

GC Root对象分类

虚拟机栈中引用的对象

方法区类静态属性引用的变量

方法区常量池引用的对象

本地方法栈JNI引用的对象

三色标记法

白色：本对象还没有被标记线程访问过。
灰色：本对象已经被访问过，但是本对象引用的其他对象还没有被全部访问。
黑色：本对象已经被访问过，并且本对象引用的其他对象也都被访问过了。

初始阶段，所有对象都是白色。
将 GC Roots 直接引用的对象标记为灰色。
处理灰色对象，把当前灰色对象引用的所有对象都变成灰色，之后将当前灰色对象变成黑色。
重复步骤 3，直到不存在灰色对象为止。

三色标记结束后，白色对象就是没有被引用的对象（比如上图中的 H 和 G），可以被回收了。

满足上述条件时，不会马上GC，需要进行两次标记

判断当前对象是否有finalize()方法并且该方法有没有被执行过，若不存在该方法，则标记为垃圾对象
将当前对象放入F-Queue队列，并生成一个finalize线程执行finalize()方法（虚拟机不保值该方法一定被执行，因为如果线程执行缓慢或者进入了死锁，导致GC系统奔溃）

如果执行了finalize()仍然没有GC Roots引用，则对象在GC时会被回收

引用级别

强引用

普通的对象引用关系，如 String s = new String("ConstXiong")

软引用

内存不足时，GC才会回收，通过SoftReference实现

弱引用

GC时就会回收，通过WeakReference实现

虚引用

一种形同虚设的引用，基本用不到，通过PhantomReference实现

垃圾回收算法

标记清除法

标记需要回收的对象，然后统一回收

特点：效率低，容易产生内存碎片，影响分配大对象空间的效率

标记复制法

将内存空间复制成两份，一份回收使用，一份正常使用

特点：浪费一半空间，不会产生内存碎片

标记整理法

标记需要回收的对象，把所有存活的对象往一端移动，最后清除掉另一端

特点：对于移动大对象，开销很大，不会产生内存碎片

分代收集算法

根据不同的生命周期区域，使用不同的算法
新生代使用复制算法
老年代使用标记整理法

总结

GC处理器

概述及基础概念引入

堆区域分布示意图

垃圾收集器根据发展实践可以分为

串行

吞吐量优先

响应时间优先

并发和并行

并行：并行描述的是多条垃圾收集器线程之间的关系，说明同一时间有多条这样的线程在协同工作，
通常默认此时用户线程是处于等待状态

并发：并发描述的是垃圾收集器线程与用户线程之间的关系，说明同一时间垃圾收集器线程与用户线程都在运行。
由于用户线程并未被冻结，所以程序仍然能响应服务请求，但由于垃圾收集器线程占用了一部分系统资源，
此时应用程序的处理的吞吐量将受到一定影响。

各个处理器介绍

ZGC（Z Garbage Collector）

JDK11引入，JDK15不在是实验功能正式投入

三个重要特性特性

暂停时间不会超过10ms
最大支持 16TB 的大堆，最小支持 8MB 的小堆
跟 G1 相比，对应用程序吞吐量的影响小于 15 %

JDK 16 发布后，GC 暂停时间已经缩小到 1 ms 以内，并且时间复杂度是 o(1)
，这也就是说 GC 停顿时间是一个固定值了，并不会受堆内存大小影响

内存多重映射

就是使用 mmap 把不同的虚拟内存地址映射到同一个物理内存地址上

ZGC 为了更灵活高效地管理内存，使用了内存多重映射，把同一块儿物理内存映射为 Marked0、Marked1 和 Remapped 三个虚拟内存。

当应用程序创建对象时，会在堆上申请一个虚拟地址，这时 ZGC 会为这个对象在 Marked0、Marked1 和 Remapped 这三个视图空间分别申请一个虚拟地址，这三个虚拟地址映射到同一个物理地址。

Marked0、Marked1 和 Remapped 这三个虚拟内存作为 ZGC 的三个视图空间，在同一个时间点内只能有一个有效。ZGC 就是通过这三个视图空间的切换，来完成并发的垃圾回收。

染色指针

ZGC 出现之前， GC 信息保存在对象头的 Mark Word 中。比如 64 位的 JVM，对象头的 Mark Word 中保存的信息如下图

染色指针是一种将少量信息直接存储在指针上的技术

在这个 64 位的指针上，高 16 位都是 0，暂时不用来寻址。剩下的 48 位支持的内存可以达到 256 TB（2 ^48）,这可以满足多数大型服务器的需要了
不过 ZGC 并没有把 48 位都用来保存对象信息，而是用高 4 位保存了四个标志位，这样 ZGC 可以管理的最大内存可以达到 16 TB（2 ^ 44）

通过这四个标志位，JVM 可以从指针上直接看到对象的三色标记状态（Marked0、Marked1）、
是否进入了重分配集（Remapped）、是否需要通过 finalize 方法来访问到（Finalizable）。

内存布局

ZGC的堆内存也是基于Region分布，不过ZGC不区分老年代和新生代，
ZGC 的 Region 支持动态地创建和销毁，并且 Region 的大小不是固定的，包括三种类型的 Region

Small Region

2MB，主要用于放置小于 256 KB 的小对象

Medium Region

32MB，主要用于放置大于等于 256 KB 小于 4 MB 的对象

Large Region

N * 2MB。这个类型的 Region 是可以动态变化的，不过必须是 2MB 的整数倍，
最小支持 4 MB。每个 Large Region 只放置一个大对象，并且是不会被重分配的

读屏障

读屏障类似于 Spring AOP 的前置增强，是 JVM 向应用代码中插入一小段代码，当应用线程从堆中读取对象的引用时，会先执行这段代码

注意：只有从堆内存中读取对象的引用时，才会执行这个代码

读屏障在解释执行时通过 load 相关的字节码指令加载数据。作用是在对象标记和转移过程中，判断对象的引用地址是否满足条件，并作出相应动作。如下图

读屏障会对应用程序的性能有一定影响，据测试，对性能的最高影响达到 4%，但提高了 GC 并发能力，降低了 STW。

GC过程

ZGC 初始化后，整个内存空间的地址视图被设置为 Remapped

具体步骤

初始标记

从 GC Roots 出发，找出 GC Roots 直接引用的对象，放入活跃对象集合，这个过程需要 STW，不过 STW 的时间跟 GC Roots 数量成正比，耗时比较短

并发标记

并发标记过程中，GC 线程和 Java 应用线程会并行运行

GC 标记线程访问对象时，如果对象地址视图是 Remapped，就把对象地址视图切换到 Marked0，如果对象地址视图已经是 Marked0，说明已经被其他标记线程访问过了，跳过不处理。
标记过程中Java 应用线程新创建的对象会直接进入 Marked0 视图。
标记过程中Java 应用线程访问对象时，如果对象的地址视图是 Remapped，就把对象地址视图切换到 Marked0，可以参考前面讲的读屏障。
标记结束后，如果对象地址视图是 Marked0，那就是活跃的，如果对象地址视图是 Remapped，那就是不活跃的。

标记阶段的活跃视图也可能是 Marked1，区分第一次标记还是第二次标记

再标记

并发标记阶段 GC 线程和 Java 应用线程并发执行，标记过程中可能会有引用关系发生变化而导致的漏标记问题。再标记阶段重新标记并发标记阶段发生变化的对象，还会对非强引用（软应用，虚引用等）进行并行标记。

这个阶段需要 STW，但是需要标记的对象少，耗时很短。

初始转移

转移就是把活跃对象复制到新的内存，之前的内存空间可以被回收

初始转移需要扫描 GC Roots 直接引用的对象并进行转移，这个过程需要 STW，STW 时间跟 GC Roots 成正比。

并发转移

并发转移过程 GC 线程和 Java 线程是并发进行的。上面已经讲过，转移过程中对象视图会被切回 Remapped 。转移过程需要注意以下几点：

如果 GC 线程访问对象的视图是 Marked0，则转移对象，并把对象视图设置成 Remapped。
如果 GC 线程访问对象的视图是 Remapped，说明被其他 GC 线程处理过，跳过不再处理。
并发转移过程中 Java 应用线程创建的新对象地址视图是 Remapped。
如果 Java 应用线程访问的对象被标记为活跃并且对象视图是 Marked0，则转移对象，并把对象视图设置成 Remapped。

重定位

转移过程对象的地址发生了变化，在这个阶段，把所有指向对象旧地址的指针调整到对象的新地址上。

垃圾收集算法

标记 - 整理算法

JDK16前

需要一块独立的空间

因为有预留内存，能给 Java 线程分配的堆内存小于 JVM 声明的堆内存。
Reserve 仅仅用于存放 GC 过程中搬移的对象，有点内存浪费。
因为 Reserve 不能给 GC 过程中搬移对象的 Java 线程使用，搬移线程可能会因为申请不到足够内存而不能完成对象搬移，
这返回过来又会导致应用程序的 OOM。

JDK16后

缺点：必须考虑搬移对象的顺序，否则可能会覆盖尚未移动的对象。这就需要 GC 线程之间更好的进行协作，不利于并发收集，
同时也会导致搬移对象的 Java 线程需要考虑什么可以做什么不可以做。

优点：JDK 16 在支持就地搬移的同时，也支持预留（Reserve）堆内存的方式，并且 ZGC 不需要真的预留空闲的堆内存。默认情况下，
只要有空闲的 region，ZGC 就会使用预留堆内存的方式，如果没有空闲的 region，否则 ZGC 就会启用就地搬移。
如果有了空闲的 region， ZGC 又会切换到预留堆内存的搬移方式

总结

内存多重映射和染色指针的引入，使 ZGC 的并发性能大幅度提升。
ZGC 只有 3 个需要 STW 的阶段，其中初始标记和初始转移只需要扫描所有 GC Roots，STW 时间 GC Roots 的数量成正比，不会耗费太多时间。再标记过程主要处理并发标记引用地址发生变化的对象，这些对象数量比较少，耗时非常短。可见整个 ZGC 的 STW 时间几乎只跟 GC Roots 数量有关系，不会随着堆大小和对象数量的变化而变化。
ZGC 也有一个缺点，就是浮动垃圾。因为 ZGC 没有分代概念，虽然 ZGC 的 STW 时间在 1ms 以内，但是 ZGC 的整个执行过程耗时还是挺长的。在这个过程中 Java 线程可能会创建大量的新对象，这些对象会成为浮动垃圾，只能等下次 GC 的时候进行回收

总结

Serial GC

串行回收器、新生代回收器

Serial Old GC

串行回收器、老年代回收器

CMS失败后的兜底操作，
在并发收集发生Concurrent Mode Failure 时使用

ParNew GC

并行回收器，新生代回收器

可以于CMS收集器配合工作

线程数和处理器核心数相同

Parallel Scavenge GC

并行回收器、新生代回收器

别名：吞吐量优先收集器

Parallel Old GC

并行回收器、老年代回收器

Parallel Scavenge的老年代版本

CMS(Concurrent Mark Sweep) GC

并发回收器、老年代回收器

一种并发的GC，主要用于需要短暂停顿实际的应用程序

操作步骤

初始标记

需要Stop The Word，仅仅标记从GC Roots的直接关联对象，速度很快

并发标记

从GC Roots的直接关联对象开始遍历整个对象图的过程，
过程耗时但不需要停顿用户线程，可以与垃圾收集线程一起并发允许

重新标记

需要Stop The Word，为了修正并发标记期间，
因为用户程序继续允许而导致标记产生变动的拿一些对象的标记记录
停顿时间比初始标记时间常，但比并发标记时间短

并发清除

清除标记阶段判断已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以和用户进程同时运行的

缺点

无法处理浮动垃圾

由于标记清除法，会产生内存碎片

对CPU要求高

G1 GC

并发回收器、整堆回收器

一种基于区域的GC，可以实现更加预测的GC停顿时间，并在能够在大堆内存的情况下保证高吞吐量
JDK9以后版本成为默认GC

G1收集器面向堆内存任何部分来组成回收集 (Collection Set，一般简称 CSet)进行回收，衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收收益最大，这就是 G1 收集器的 Mixed GC 模式

基于Region的堆内存布局

Region 是 G1收集器的单位回收的最小单位

根据区域的价值大小，产生一个后台队列，在根据用户设定允许的STW，优先处理哪些回收价值大的区域

运行步骤

初始标记

仅仅标记GC Roots能直接关联到的对象并且修改TAMS指针的值，让下一阶段与用户线程并发运行时，能正确的在可用的Region中分配新对象
这个阶段需要短暂的STW，而且是借用进行Minor GC的时候同步完成的，所有G1收集器在这个阶段实际并没有额外的停顿

并发标记

从GC Root开始对堆中对象进行可达性分析，递归扫描这个堆里的对象图，找出要回收的对象，该阶段耗时较长，可与用户线程并发执行
当对象图扫描完成以后，还要重新处理SATB记录下的并发时引用变动的对象

最终标记

对用户现在做一个短暂的STW，用于处理并发阶段结束后仍遗留下来的最后那部分少量的SATB记录

筛选回收

负责更新Region的统计数据，对各个Region的回收价值和成本排序，根据用户期望的停顿时间来指定回收计划，
可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象赋值到空的Region中，
在清理掉整个旧的Region的全部空间。这里的操作设计存活对象的移动，是必须暂停用户线程，由多条收集器线程并行完成

示意图

什么是完整GC

堆空间划分

新生代 ( Young )、老年代 ( Old )，新生代默认占总空间的 1/3，老年代默认占 2/3。新生代有 3 个分区：Eden、To Survivor、From Survivor，它们的默认占比是8/10，1/10，1/10

新生代的垃圾回收（又称Minor GC）

只有少量对象存活，所有选用复制算法，只需要少量的复制成本就可以完成回收

只负责新生代的GC

Eden区满时触发

老年代的垃圾回收（又称Major GC）

通常使用标记整理法或者标记清除法

负责整个堆空间的GC，包括新生代、老年代、永久代(在 JDK 1.8及以后，永久代被移除，换为metaspace 元空间)

触发条件

通过Minor GC后进入老年代的平均大小大于老年代的可用内存空间
如果统计发现Minor GC的平均今生大小都比老年代的剩余空间大，则不触发Minor GC而是直接触发Full GC

老年代空间不够分配新的内存（或永久代空间不足，但只是JDK1.7有的，这也是用元空间来取代永久代的原因，可以减少Full GC的频率，减少GC负担，提升其效率）

进入老年代的对象大于老年代剩余的内存空间，例：由Eden区、From Space区向To Space区复制时

调用System.gc时，系统建议执行Full GC，但是不必然执行

一般场景下，不建议手动调用gc，可能造成不可预知的Stop the world

堆之间的转化流程

对象优先在Eden分配，当Eden区内存空间不够的时候，虚拟机会发起一个Minor GC

第一个GC后存活的对象进入Survivor区，S0

Eden再次GC，这时会采用复制算法，将Eden区和S0区一起清除，并将存活的对象复制到S1区

进入老年代方式

对象每移动一次，对象年龄+1，对象达到一定年龄会进入老年代。

GC年龄的阀值可以通过参数 -XX:MaxTenuringThreshold 设置，默认为 15

动态对象年龄判定：Survivor 区相同年龄所有对象大小的总和 > (Survivor 区内存大小 * 目标使用率)时，
大于或等于该年龄的对象直接进入老年代

目标使用率通过 -XX:TargetSurvivorRatio 指定，默认为 50%；

Survivor 区内存不足会发生担保分配，超过指定大小的对象可以直接进入老年代

大对象直接进入老年代，大对象就是需要大量连续内存空间的对象（例:字符串、数组），
为了避免对象分配内存时由于分配担保机制带来的复制而降低效率

老年代满了而无法容纳更多的对象，Minor GC 之后通常会进行Full GC，Full GC 清理整个堆的内存（新生代+老年代）

空间分配担保原则

在执行每次 YoungGC 之前，JVM会先检查老年代最大可用连续空间是否大于新生代所有对象的总大小。因为在极端情况下，可能新生代 YoungGC 后，所有对象都存活下来了，而 survivor 区又放不下，那可能所有对象都要进入老年代了。这个时候如果老年代的可用连续空间是大于新生代所有对象的总大小的，那就可以放心进行 YoungGC。但如果老年代的内存大小是小于新生代对象总大小的，那就有可能老年代空间不够放入新生代所有存活对象，这个时候JVM就会先检查 -XX:HandlePromotionFailure 参数是否允许担保失败，如果允许，就会判断老年代最大可用连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试进行一次YoungGC，尽快这次YoungGC是有风险的。如果小于，或者 -XX:HandlePromotionFailure 参数不允许担保失败，这时就会进行一次 Full GC。

担保失败

YoungGC后，存活对象小于survivor大小，此时存活对象进入survivor区中

YoungGC后，存活对象大于survivor大小，但是小于老年大可用空间大小，此时直接进入老年代

YoungGC后，存活对象大于survivor大小，也大于老年大可用空间大小，老年代也放不下这些对象了，此时就会发生“Handle Promotion Failure”，就触发了 Full GC。如果 Full GC后，老年代还是没有足够的空间，此时就会发生OOM内存溢出了。

图解