烟台网站建设求职简历,个人网站作业,上海高端网站定制开发,企业网络推广平台公司GC过程
G1#xff08;Garbage First#xff09;是JVM中的一种垃圾回收器#xff0c;设计用于处理具有大堆内存的应用程序#xff0c;减少GC停顿时间#xff0c;并提供更可预测的垃圾回收性能。G1的垃圾回收过程主要分为以下几个阶段#xff1a;
1. 年轻代垃圾回收…GC过程
G1Garbage First是JVM中的一种垃圾回收器设计用于处理具有大堆内存的应用程序减少GC停顿时间并提供更可预测的垃圾回收性能。G1的垃圾回收过程主要分为以下几个阶段
1. 年轻代垃圾回收Young GC
这个阶段主要回收新生代的对象回收发生在 Eden 区和 Survivor 区之间。
Eden 区满时触发当 Eden 区的对象分配满时触发 Young GC将 Eden 区中存活的对象移至 Survivor 区或直接移至老年代。复制算法Young GC 采用的是一种复制算法将存活的对象从 Eden 和 Survivor 区中复制到新的 Survivor 区或直接晋升到老年代。Young GC 是一个短暂停顿的过程。
2. 并发标记Concurrent Marking
这是老年代垃圾回收的第一个阶段用于标记堆中的存活对象检测哪些对象不再被引用可以被回收。
初始标记这个阶段标记所有直接与 GC Root 相关的对象伴随一个较短的停顿。并发标记在应用程序运行时并发执行递归地标记堆中所有可达的对象。这个过程不会停止应用线程。重新标记在并发标记阶段结束后重新标记那些由于应用线程运行而发生变化的引用这会导致短暂的停顿。
3. 最终清理Cleanup Phase
最终清理阶段负责整理堆空间并确定哪部分的内存需要进行压缩回收空闲内存块。
清理空闲区域标记阶段后G1 识别出哪些区域是完全空闲的并回收这些内存。整理部分区域在需要时G1 会选择部分老年代区域进行压缩将存活的对象移动到新的内存块中以释放连续的空闲空间。
4. 混合回收Mixed GC
混合回收是 G1 的一个特殊阶段它不仅回收新生代还会回收一部分老年代区域。
触发条件当老年代的使用率超过一定阈值时默认 45%混合 GC 被触发。年轻代和老年代混合回收混合回收在每次 Young GC 的基础上附加回收一部分老年代区域目标是逐步减少老年代中存活对象的数量从而避免老年代空间耗尽导致 Full GC。
5. 完全垃圾回收Full GC
这是 G1 回收器的最后一种回收模式通常是应对内存压力过大时触发的。
Stop-the-world 停顿Full GC 会完全暂停应用线程并进行整个堆的垃圾回收采用传统的单线程或多线程的标记-整理算法效率较低但能够回收整个堆中的所有垃圾对象。
阶段总结
年轻代回收Young GC只回收新生代暂停时间短。并发标记标记老年代中的存活对象尽量避免停顿。混合回收Mixed GC回收新生代和部分老年代对象减少 Full GC 触发的频率。完全垃圾回收Full GC应急阶段全堆回收停顿时间长。
通过这些阶段的配合G1 能够平衡应用的吞吐量和暂停时间适合大堆内存、低延迟要求的应用场景。
Young GC log
解析 G1 垃圾回收日志可以帮助我们更好地理解 G1 的各个阶段在实际应用中的执行情况。以下是一个典型的 G1 GC 日志片段以及相关阶段的说明
日志案例
[2024-10-10T14:15:23.1230000][info ][gc,start ] GC(0) Pause Young (Normal) (G1 Evacuation Pause) (to-space exhausted)
[2024-10-10T14:15:23.1240000][info ][gc,task ] GC(0) Using 8 workers of 8 for evacuation
[2024-10-10T14:15:23.1560000][info ][gc,phases ] GC(0) Pre Evacuate Collection Set: 0.0ms
[2024-10-10T14:15:23.1570000][info ][gc,phases ] GC(0) Evacuate Collection Set: 32.5ms
[2024-10-10T14:15:23.1570000][info ][gc,phases ] GC(0) Post Evacuate Collection Set: 0.7ms
[2024-10-10T14:15:23.1570000][info ][gc,phases ] GC(0) Other: 0.4ms
[2024-10-10T14:15:23.1570000][info ][gc,heap ] GC(0) Eden regions: 12-0(10)
[2024-10-10T14:15:23.1570000][info ][gc,heap ] GC(0) Survivor regions: 0-2(2)
[2024-10-10T14:15:23.1570000][info ][gc,heap ] GC(0) Old regions: 0-0
[2024-10-10T14:15:23.1570000][info ][gc,metaspace ] GC(0) Metaspace: 14M-14M(105M)
[2024-10-10T14:15:23.1570000][info ][gc ] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 35.2ms日志解析及相关阶段介绍
1. Young GC (Pause Young GC)
在日志中我们看到以下内容
GC(0) Pause Young (Normal) (G1 Evacuation Pause)这表示 G1 垃圾回收器在执行一次 Young GC年轻代垃圾回收。Evacuation Pause 说明该 GC 事件是为了清理新生代的 Eden 区并将存活对象复制到 Survivor 区或老年代。
GC(0)这是本次 GC 的标识符表示是 JVM 启动后第 0 次垃圾回收。Pause Young (Normal)说明这是一次年轻代回收Young GC且回收过程发生了短暂停顿STW。Evacuation PauseG1 在 Young GC 中的对象会被从 Eden 区“撤离”Evacuation移动到 Survivor 区或老年代。
2. GC 任务执行
GC(0) Using 8 workers of 8 for evacuation这说明了 G1 回收器使用了 8 个并行 GC 线程来执行对象的复制任务Evacuation。并行线程的使用有助于提高垃圾回收的效率减少停顿时间。
3. GC 阶段耗时
GC(0) Pre Evacuate Collection Set: 0.0ms
GC(0) Evacuate Collection Set: 32.5ms
GC(0) Post Evacuate Collection Set: 0.7ms
GC(0) Other: 0.4ms这些是 G1 不同阶段的耗时
Pre Evacuate Collection Set在开始实际清理之前的准备工作耗时通常非常短这里为 0.0ms。Evacuate Collection Set这个阶段是主要的对象移动阶段将存活对象从 Eden 区和 Survivor 区复制到 Survivor 区或老年代耗时 32.5ms。Post Evacuate Collection Set完成撤离之后的后续处理耗时这里为 0.7ms。Other其他非核心操作耗时通常与堆信息更新、统计等有关。
4. 堆状态变化
GC(0) Eden regions: 12-0(10)
GC(0) Survivor regions: 0-2(2)
GC(0) Old regions: 0-0这些日志显示了 GC 前后各个内存区域的变化
Eden regions: 12-0(10)GC 之前 Eden 区有 12 个 RegionGC 之后被清空0并且当前 Eden 区容量调整为 10 个 Region。Survivor regions: 0-2(2)GC 之后Survivor 区从 0 个 Region 增加到 2 个容量为 2 个 Region。Old regions: 0-0本次 GC 未涉及老年代的对象因此老年代保持不变。
5. Metaspace 状态
GC(0) Metaspace: 14M-14M(105M)这里显示了 Metaspace存放类元数据的区域在 GC 期间的大小变化。可以看到Metaspace 在此次 GC 过程中并没有变化仍然占用 14MB容量上限为 105MB。
6. GC 总耗时
GC(0) Pause Young (Normal) (G1 Evacuation Pause) 35.2ms本次 GC 事件的总耗时为 35.2 毫秒属于一次较快的年轻代回收。由于这是一次 Young GC停顿时间较短通常几十毫秒。
分析总结
这次垃圾回收是一次 年轻代垃圾回收Young GC主要清理了 Eden 区中的垃圾对象并将存活的对象移至 Survivor 区或老年代。G1 回收器采用并行处理通过 8 个 GC 线程加速了对象撤离过程。本次 GC 的总耗时为 35.2ms体现了 G1 在进行 Young GC 时较短的停顿时间。堆内存的变化显示Eden 区得到了清理Survivor 区得到了适量的存活对象而老年代未被涉及。
通过这样的日志分析可以发现 G1 回收器的回收行为及性能帮助判断系统在垃圾回收上的表现是否达到预期并据此优化 JVM 配置。
Mixed GC log
混合回收Mixed GC是 G1 垃圾回收器的一个关键特性它不仅回收新生代Eden 和 Survivor 区还会同时回收部分老年代Old Generation中的区域。它通常在老年代占用空间超过一定阈值默认是 45%时触发通过增量式回收老年代来避免 Full GC 的发生。
下面是一个典型的 G1 混合回收Mixed GC日志案例以及相关阶段的详细介绍。
日志案例
[2024-10-10T14:25:35.7890000][info ][gc,start ] GC(15) Pause Young (Mixed) (G1 Evacuation Pause)
[2024-10-10T14:25:35.7900000][info ][gc,task ] GC(15) Using 8 workers of 8 for evacuation
[2024-10-10T14:25:35.8300000][info ][gc,phases ] GC(15) Pre Evacuate Collection Set: 0.2ms
[2024-10-10T14:25:35.8300000][info ][gc,phases ] GC(15) Evacuate Collection Set: 39.5ms
[2024-10-10T14:25:35.8300000][info ][gc,phases ] GC(15) Post Evacuate Collection Set: 0.5ms
[2024-10-10T14:25:35.8300000][info ][gc,phases ] GC(15) Other: 0.3ms
[2024-10-10T14:25:35.8300000][info ][gc,heap ] GC(15) Eden regions: 10-0(12)
[2024-10-10T14:25:35.8300000][info ][gc,heap ] GC(15) Survivor regions: 2-2(2)
[2024-10-10T14:25:35.8300000][info ][gc,heap ] GC(15) Old regions: 25-20
[2024-10-10T14:25:35.8300000][info ][gc,metaspace ] GC(15) Metaspace: 35M-35M(105M)
[2024-10-10T14:25:35.8300000][info ][gc ] GC(15) Pause Young (Mixed) (G1 Evacuation Pause) 40.1ms日志解析及混合回收介绍
1. Mixed GC (Pause Young Mixed GC)
GC(15) Pause Young (Mixed) (G1 Evacuation Pause)这段日志显示了一次 混合回收Mixed GC 事件意味着这次回收不仅仅是 Young GC还回收了部分老年代的内存区域。
Pause Young (Mixed)表示这次是 Young GC 和 Mixed GC 的混合回收 Eden 区、Survivor 区以及部分老年代区域。G1 Evacuation Pause依旧是一次对象“撤离”Evacuation将存活的对象移动到 Survivor 区或老年代中同时回收部分老年代区域的垃圾对象。
2. GC 任务执行
GC(15) Using 8 workers of 8 for evacuationG1 使用了 8 个并行的 GC 线程来执行对象撤离任务从 Eden 区、Survivor 区以及老年代区域中搬移对象。
3. GC 阶段耗时
GC(15) Pre Evacuate Collection Set: 0.2ms
GC(15) Evacuate Collection Set: 39.5ms
GC(15) Post Evacuate Collection Set: 0.5ms
GC(15) Other: 0.3ms与之前的 Young GC 类似Mixed GC 也分为几个阶段
Pre Evacuate Collection Set在准备清理前的一些初步操作耗时 0.2 毫秒。Evacuate Collection Set这是真正执行对象撤离的阶段耗时 39.5 毫秒主要负责将 Eden 区的存活对象移动到 Survivor 区将老年代的存活对象整理。Post Evacuate Collection Set完成对象撤离后的后处理耗时 0.5 毫秒。Other一些其他辅助操作耗时 0.3 毫秒。
4. 堆状态变化
GC(15) Eden regions: 10-0(12)
GC(15) Survivor regions: 2-2(2)
GC(15) Old regions: 25-20这部分日志显示了堆内存区域在 GC 前后的变化
Eden regions: 10-0(12)Eden 区在 GC 之前有 10 个区域GC 之后被清空0 个 Region并调整了 Eden 区容量为 12 个 Region。Survivor regions: 2-2(2)Survivor 区保持不变有 2 个 Region。Old regions: 25-20老年代区域从 25 个减少到 20 个表示部分老年代区域的垃圾对象被成功回收。
5. Metaspace 状态
GC(15) Metaspace: 35M-35M(105M)Metaspace 没有发生变化依然保持 35MB 的使用量容量上限为 105MB。
6. GC 总耗时
GC(15) Pause Young (Mixed) (G1 Evacuation Pause) 40.1ms此次混合回收Mixed GC总共耗时 40.1 毫秒较一次普通的 Young GC 来说耗时略长因为混合回收同时涉及了新生代和老年代的对象处理。
混合回收的触发条件
老年代使用率阈值当老年代使用量超过一定的阈值默认是堆内存的 45%时G1 会触发并发标记阶段标记老年代中的存活对象。并发标记完成后当并发标记阶段完成后G1 将在随后的 Young GC 过程中混合回收部分老年代。这样做的好处是通过逐步清理老年代延缓甚至避免 Full GC 的发生。
混合回收的意义
减少 Full GC 频率通过逐步清理老年代G1 可以有效避免 Full GC 的频繁触发。Full GC 通常会暂停所有应用线程Stop-the-World是影响应用性能的一个大因素。可控的停顿时间G1 的 Mixed GC 能够通过分批回收老年代内存保持每次 GC 的停顿时间较短避免单次 GC 占用过多时间影响应用响应。增量回收老年代通过多个 Mixed GC 回收部分老年代G1 可以持续维持堆内存的健康状态而不是等待老年代填满再执行一次耗时的 Full GC。
分析总结
这个混合回收日志显示
Eden 区的对象成功撤离到 Survivor 区或老年代。老年代中的一些区域得到了回收减少了 5 个 Region。总体上GC 耗时 40.1ms比普通 Young GC 稍长但仍属于较短的停顿时间说明 G1 的混合回收能有效控制暂停时间避免 Full GC。
通过混合回收G1 在回收年轻代的同时逐步整理老年代从而达到减少 Full GC 的目标。
Full GC log
Full GC 是 JVM 中最耗时、影响性能最大的垃圾回收事件。在 G1 垃圾回收器中Full GC 发生的频率相对较低但当内存紧张且老年代无法通过 Mixed GC 及时回收时仍可能触发 Full GC。G1 的 Full GC 是通过单线程执行的 “Stop-the-World” 事件会暂停所有应用线程因此开发者通常尽量避免 Full GC。
接下来我们结合一个实际 Full GC 的日志案例逐步分析 Full GC 触发的过程、日志中的关键阶段以及相关信息。
Full GC 日志案例
[2024-10-10T14:45:55.1230000][info ][gc,start ] GC(25) Pause Full (G1 Evacuation Pause)
[2024-10-10T14:45:55.1240000][info ][gc,phases,start] GC(25) Phase 1: Mark live objects
[2024-10-10T14:45:55.2980000][info ][gc,phases ] GC(25) Phase 1: Mark live objects 174.1ms
[2024-10-10T14:45:55.2990000][info ][gc,phases,start] GC(25) Phase 2: Compute new object addresses
[2024-10-10T14:45:55.4020000][info ][gc,phases ] GC(25) Phase 2: Compute new object addresses 103.4ms
[2024-10-10T14:45:55.4020000][info ][gc,phases,start] GC(25) Phase 3: Adjust pointers
[2024-10-10T14:45:55.5230000][info ][gc,phases ] GC(25) Phase 3: Adjust pointers 121.2ms
[2024-10-10T14:45:55.5230000][info ][gc,phases,start] GC(25) Phase 4: Evacuate Collection Set
[2024-10-10T14:45:55.7790000][info ][gc,phases ] GC(25) Phase 4: Evacuate Collection Set 255.9ms
[2024-10-10T14:45:55.7800000][info ][gc,heap ] GC(25) Eden regions: 10-0(12)
[2024-10-10T14:45:55.7800000][info ][gc,heap ] GC(25) Survivor regions: 2-2(2)
[2024-10-10T14:45:55.7800000][info ][gc,heap ] GC(25) Old regions: 55-20
[2024-10-10T14:45:55.7800000][info ][gc,metaspace ] GC(25) Metaspace: 45M-44M(100M)
[2024-10-10T14:45:55.7800000][info ][gc ] GC(25) Pause Full (G1 Evacuation Pause) 657.4ms日志解析及 Full GC 介绍
1. Full GC 事件开始
GC(25) Pause Full (G1 Evacuation Pause)这次事件是一次 Full GC表示整个堆包括 Eden 区、Survivor 区和老年代都被回收。
Pause Full所有应用线程都被暂停即“Stop-the-World”。G1 Evacuation Pause和年轻代和混合回收类似Full GC 也执行了对象撤离Evacuation但这次是整个堆的对象处理。
2. Phase 1: Mark live objects
GC(25) Phase 1: Mark live objects 174.1ms第一阶段是 标记存活对象。G1 会遍历整个堆包括年轻代和老年代标记所有存活的对象。这个过程耗时 174.1 毫秒。对于 Full GC这个阶段是单线程的会导致长时间的停顿。
3. Phase 2: Compute new object addresses
GC(25) Phase 2: Compute new object addresses 103.4ms第二阶段是 计算新对象的地址。由于 G1 是区域化管理堆内存的标记完成后需要计算存活对象的新地址确保对象被压缩到更紧凑的内存区域中。这个过程耗时 103.4 毫秒。
4. Phase 3: Adjust pointers
GC(25) Phase 3: Adjust pointers 121.2ms第三阶段是 调整对象指针。随着对象被搬移到新的内存地址所有指向这些对象的引用需要更新为新的地址。这个阶段耗时 121.2 毫秒。
5. Phase 4: Evacuate Collection Set
GC(25) Phase 4: Evacuate Collection Set 255.9ms第四阶段是 对象撤离即将存活的对象从 Eden 区、Survivor 区和老年代搬移到新的内存区域并回收旧的内存区域。这个过程耗时 255.9 毫秒。
6. 堆内存状态变化
GC(25) Eden regions: 10-0(12)
GC(25) Survivor regions: 2-2(2)
GC(25) Old regions: 55-20这部分日志描述了 Full GC 前后堆内存各区域的变化
Eden regions: 10-0(12)Eden 区的 10 个 Region 被清空并且恢复为 12 个可用的区域。Survivor regions: 2-2(2)Survivor 区没有变化。Old regions: 55-20老年代的 Region 数量从 55 个减少到 20 个意味着老年代的垃圾对象得到了显著回收。
7. Metaspace 状态
GC(25) Metaspace: 45M-44M(100M)Metaspace 是 JVM 用来存储类元数据的内存区域。在 Full GC 中Metaspace 也可能被回收。在这次 Full GC 中Metaspace 的使用量从 45MB 减少到 44MB。
8. Full GC 总耗时
GC(25) Pause Full (G1 Evacuation Pause) 657.4ms整个 Full GC 的总耗时为 657.4 毫秒这是一次相对较长的垃圾回收停顿。相比 Young GC 或 Mixed GCFull GC 的耗时通常要长很多因为它涉及到整个堆的回收并且是单线程执行的。
Full GC 触发的原因
Full GC 通常在以下情况下触发
老年代无法回收当老年代的内存占用达到较高水平Mixed GC 不能及时清理足够的老年代区域时G1 会触发 Full GC。晋升失败当从 Eden 区撤离的存活对象无法晋升到老年代因为老年代空间不足时会触发 Full GC。元数据空间不足当 Metaspace 空间不足时也可能触发 Full GC。系统资源压力当 JVM 内存使用压力较大且回收效率低时系统可能强制执行 Full GC 以释放内存。
Full GC 的影响
长时间的停顿Full GC 会暂停所有应用线程导致应用长时间停止响应这对高性能、低延迟的应用非常不利。单线程处理相比于并行的 Young GC 或 Mixed GCFull GC 是单线程处理的因此速度较慢。最后的手段Full GC 是垃圾回收器的最后手段通常意味着内存管理已经到了非常紧张的状态混合回收无法有效解决问题。
如何避免 Full GC
调整老年代阈值可以通过调节 G1 的老年代启动 Mixed GC 的阈值让老年代尽早参与混合回收避免老年代过度膨胀。增大堆内存适当增大堆内存使得老年代和新生代有更多的空间避免频繁触发 Full GC。优化应用内存使用减少短生命周期的大对象创建优化内存占用减少垃圾产生。监控和调优使用监控工具如 Prometheus 或 JMX 监控垃圾回收情况及时发现问题进行调优。
通过以上方式可以降低 Full GC 的频率提升 JVM 性能。
Stop-The-World
“Stop-the-World” (STW) 事件指的是在垃圾回收过程中所有应用线程都被暂停的阶段。在 G1 垃圾回收器中Stop-the-World 事件的几个关键阶段与不同类型的 GC 有关。对于典型的 G1 GCStop-the-World 主要出现在 初始标记、最终标记 以及 清除 阶段。
让我们逐步分析
1. 初始标记Initial Mark
STW是的初始标记阶段是一个 Stop-the-World 事件。作用标记根对象GC Roots以及其直接可达的对象。GC Roots 包括线程栈、全局静态变量等。时间较短这个阶段的工作量较少仅仅是标记直接可达的对象通常时间较短。
[GC pause (G1 Evacuation Pause) (initial-mark) ...]2. 并发标记Concurrent Marking
非 STW并发标记阶段不会暂停应用线程垃圾收集线程和应用线程是并发运行的。作用遍历堆中的所有存活对象标记从 GC Roots 可达的所有对象。可能触发最终标记并发标记过程中如果标记过程中发现某些内存区域是空的或全是垃圾可能会提前触发混合回收。
[GC concurrent-mark-start ...]
[GC concurrent-mark-end ...]3. 最终标记Final Remark/Remark
STW最终标记阶段是一个 Stop-the-World 事件。作用由于并发标记过程中应用线程仍在运行可能有新的对象被分配或对象引用被修改因此需要一个短暂停顿来捕获这些变化确保标记准确。时间较短通常比并发标记快得多因为只需要处理自并发标记开始后的增量变化。
[GC pause (G1 Evacuation Pause) (remark) ...]4. 清理阶段Cleanup/Cleanup Phase
部分 STW清理阶段分为两部分初期会有短暂的 Stop-the-World 暂停标记出垃圾区域并释放这些内存。后续阶段回收是并发完成的。作用回收空闲的堆内存区域并将其重新加入可用的堆内存区域列表。
[GC cleanup-start ...]
[GC cleanup-end ...]总结
在 G1 垃圾回收的几个阶段中Stop-the-World 事件主要发生在以下几个阶段
初始标记Initial Mark阶段 —— 短暂的 STW用于标记 GC Roots。最终标记Final Remark阶段 —— 短暂的 STW用于标记并发标记期间未处理的对象变化。部分清理阶段Cleanup Phase—— 有一个短暂的 STW用于处理空闲区域的标记。
并发标记是非 STW 的应用线程与垃圾回收线程并发工作大大减少了对应用的影响。
