Loading [MathJax]/jax/input/TeX/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >Java11 的 G1 垃圾收集器

Java11 的 G1 垃圾收集器

作者头像
没有故事的陈师傅
发布于 2023-11-16 03:53:03
发布于 2023-11-16 03:53:03
52000
代码可运行
举报
文章被收录于专栏:运维开发故事运维开发故事
运行总次数:0
代码可运行

首先我先抛出以下几个问题:

  1. 很多服务需要过一段时间重启一次,如果不重启系统就会越来越慢?
  2. 突然一个中间件挂了一段时间过后,但是一些不相关的服务越来越卡,后面 OOM?
  3. 上线一个功能过后,CPU 就飙升到 100%,但是服务还是正常运行?
  4. 服务的某一个 CPU 出现有规律的,周期性的尖刺该如何解决?

作为 5 年以上工作经验的技术人员,或多或少在系统维护,系统保障,系统调优遇到过上面的这几个场景,你可能是通过重启,调整一些 jvm 参数解决,如果大家需要深入的探究找到问题的原因,可以耐心看看下文我对 G1 的一些总结。

本文讲哪些东西?

  1. 堆布局(以 Region 为基础划分:新生代(Eden 区、Survivor 区)、年老代、Humongous 区域)
  2. 垃圾收集周期
  3. GC 运作过程:初始标记、并发标记、最终标记、筛选回收
  4. GC 类型:Minor GC、Full GC 、Mixed GC
  5. CSet (年轻代需要收集的 Region 集合就是 CSet)
  6. 跨代引用
  7. 停顿预测模型
  8. GC 日志分析

G1 内存堆布局

G1 的英文全称是 Garbagge First,是一个有分代,按照 Region 的方式进行内存布局的垃圾收集器。

上图,我将一些 Region 标明了 H,它代表Humongous,这表示这些 Region 存储的是巨大对象(humongous object,H-obj),即大小大于等于 region 一半的对象。H-obj 有如下几个特征:

  • H-obj 直接分配到了old gen,防止了反复拷贝移动。
  • H-obj 在 global concurrent marking 阶段的 cleanup 和 full GC阶段回收。
  • 在分配 H-obj 之前先检查是否超过 initiating heap occupancy percent 和 the marking threshold, 如果超过的话,就启动 global concurrent marking,为的是提早回收,防止 evacuation failures 和 full GC。

GC 类型

  1. Young GC,垃圾收集范围:年轻代区域 + 大对象区
  2. Mixed GC,垃圾收集范围:年轻代区域 + 老年区 + 大对象区
  3. Full GC,垃圾收集范围:年轻代区域 + 老年区 + 大对象区 + 元空间

Collection Set (收集区域)

Collection Set 就是我们垃圾收集器的一个区域,在不同的垃圾回收阶段,会有不同的区域。

  • Young GC, 垃圾收集区域包括:年轻代区域 + 大对象区
  • Mixed GC, 垃圾收集区域包括:年轻代区域 + 老年区 + 大对象区

跨代引用

Young GC 主要是清理,新生代中的对象,我们知道整个堆空间包括老年代,新生代,我们在 Young GC 过程中会去找 GCRoots 然后判断对象是是否可达, 如果不可达,如果可达就标记。如果对于老年代中引用新生代的对象,我们如果要找出来就就需要对老年代进行全扫描,这样是不太现实的。所以 G1 通过记忆集的形式记录了老年代对新生代的引用。具体在 G1 中通过 CarTable 来实现记忆集。

RSet(记忆集)

记录了其它 Region 中的对象到 Region 的引用。RSet 的价值在于使得垃圾回收不需要扫描整个堆,能够快速定位到真正引用它的堆对象地址。ReSet 本身就是一个 Hash 表,存储在新生代的每个 Region 中。但是存储需要消耗空间,多的能达到百分之 20。因此G1对内存的空间要求较高(小空间没资本玩),空间越大性能越彪悍。

CardTable (卡表)

由于新生代GC时,需要扫描整个old区,效率非常低。所以old区就是用卡表的方式进行一次逻辑分区。一般一页卡表的大小是2的n次幂。每一个区域也是用Key,Value结构进行记录。每一区域记录为Key不重复,Value则记录这片区域的老年代对象与新生代对象是否存在引用关系,存在则标记为1,否则为0。记录完毕后把value为1的key作为ReSet的key进行记录,并且ReSet的value存储引用,从而提高跨代引用的查询效率。

停顿预测模型

所有的预测都是基于历史的拟合,HotSpot使用了基于方差与标准差的技术。参考:https://sdww2348115.github.io/jvm/g1/PausePredictionModel

G1 垃圾收集周期

图片来源 Oracle 官网

G1 有两个阶段,它会在这两个阶段往返,分别是 Young-only,Space Reclamation.

  1. Young-only 包含一系列的操作,如果长期存活的对象会逐渐转移到 Old gen
  2. Space Reclamation G1 会递进地回收 Old gen 的空间,同时也处理 Young region

图是来自 Oracle 上对 GC 周期的描述,实心圆都表示一次 GC 停顿

  • 蓝色 Young-only
  • 黄色 标记过程的停顿
  • 红色 Mixed GC 停顿

在几次 GC 后,Old gen 的对象占有比超过了 InitiatingHeapOccupancyPercent (简称为IHOP,默认值为45,这个值是启动并发标记的阈值,当老年代使用内存占用堆内存的45%启动并发标记。如果该区域过大,可能会导致mixed gc跟不上内存分配的速度从而导致full gc ),gc 就会进入并发标记准备 (Concurrent Mark)。

  • G1 在每一次 Young 回收中都会查找活对象 (有引用的对象)
  • G1 在 old region 并发查找存活对象
    • 是 Concurrent Marking
    • 可能花费很长时间
    • 不会停止 Java 应用
  • G1 没有活对象的引用信息是不能进行垃圾回收的
    • Mixed GC 依赖 Concurrent Mark

回到 Full GC,从上面简单分析得出,Full GC 发生是没有足够的 free region,如果堆是足够大的,Mixed gc 没有回收足够的 old region,或者 concurrent mark 没法及时完成,都可能会导致 full gc。

GC 日志分析

下面是网上找的一个 GC 日志案例,解析如下(配合 G1 垃圾收集周期结合来看):

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
[gc,start      ] GC(44265) Pause Young (Normal) (G1 Evacuation Pause)
[gc,task       ] GC(44265) Using 13 workers of 13 for evacuation
[gc,phases     ] GC(44265)   Pre Evacuate Collection Set: 0.1ms
[gc,phases     ] GC(44265)   Evacuate Collection Set: 101.8ms
[gc,phases     ] GC(44265)   Post Evacuate Collection Set: 3.2ms
[gc,phases     ] GC(44265)   Other: 2.7ms
[gc,heap       ] GC(44265) Eden regions: 1850->0(1851)
[gc,heap       ] GC(44265) Survivor regions: 70->69(240)
[gc,heap       ] GC(44265) Old regions: 766->768
[gc,heap       ] GC(44265) Humongous regions: 20->19
[gc,metaspace  ] GC(44265) Metaspace: 193280K->193280K(1230848K)
[gc            ] GC(44265) Pause Young (Normal) (G1 Evacuation Pause) 21642M->6843M(25600M) 107.561ms
[gc,cpu        ] GC(44265) User=1.31s Sys=0.00s Real=0.11s

[gc,start      ] GC(44266) Pause Young (Normal) (G1 Evacuation Pause)
[gc,task       ] GC(44266) Using 13 workers of 13 for evacuation
[gc,phases     ] GC(44266)   Pre Evacuate Collection Set: 0.1ms
[gc,phases     ] GC(44266)   Evacuate Collection Set: 99.8ms
[gc,phases     ] GC(44266)   Post Evacuate Collection Set: 3.3ms
[gc,phases     ] GC(44266)   Other: 2.7ms
[gc,heap       ] GC(44266) Eden regions: 1851->0(1854)
[gc,heap       ] GC(44266) Survivor regions: 69->66(240)
[gc,heap       ] GC(44266) Old regions: 768->772
[gc,heap       ] GC(44266) Humongous regions: 20->19
[gc,metaspace  ] GC(44266) Metaspace: 193280K->193280K(1230848K)
[gc            ] GC(44266) Pause Young (Normal) (G1 Evacuation Pause) 21659M->6848M(25600M) 105.713ms
[gc,cpu        ] GC(44266) User=1.29s Sys=0.01s Real=0.10s

[gc,start      ] GC(44267) Pause Young (Normal) (G1 Evacuation Pause)
[gc,task       ] GC(44267) Using 13 workers of 13 for evacuation
[gc,phases     ] GC(44267)   Pre Evacuate Collection Set: 0.1ms  //初始标记,查找 gc root 
[gc,phases     ] GC(44267)   Evacuate Collection Set: 89.8ms     //并发标记
[gc,phases     ] GC(44267)   Post Evacuate Collection Set: 3.5ms //清理工作
[gc,phases     ] GC(44267)   Other: 2.7ms
[gc,heap       ] GC(44267) Eden regions: 1854->0(1856)
[gc,heap       ] GC(44267) Survivor regions: 66->64(240)
[gc,heap       ] GC(44267) Old regions: 772->775
[gc,heap       ] GC(44267) Humongous regions: 20->19
[gc,metaspace  ] GC(44267) Metaspace: 193280K->193280K(1230848K)
[gc            ] GC(44267) Pause Young (Normal) (G1 Evacuation Pause) 21688M->6859M(25600M) 95.891ms
[gc,cpu        ] GC(44267) User=1.16s Sys=0.00s Real=0.10s

[gc,start      ] GC(44268) Pause Young (Normal) (G1 Evacuation Pause)                 // Young GC
[gc,task       ] GC(44268) Using 13 workers of 13 for evacuation
[gc,phases     ] GC(44268)   Pre Evacuate Collection Set: 0.1ms
[gc,phases     ] GC(44268)   Evacuate Collection Set: 100.5ms
[gc,phases     ] GC(44268)   Post Evacuate Collection Set: 3.8ms
[gc,phases     ] GC(44268)   Other: 2.8ms
[gc,heap       ] GC(44268) Eden regions: 1856->0(1855)
[gc,heap       ] GC(44268) Survivor regions: 64->65(240)
[gc,heap       ] GC(44268) Old regions: 775->777
[gc,heap       ] GC(44268) Humongous regions: 20->19
[gc,metaspace  ] GC(44268) Metaspace: 193280K->193280K(1230848K)
[gc            ] GC(44268) Pause Young (Normal) (G1 Evacuation Pause) 21715M->6876M(25600M) 107.037ms
[gc,cpu        ] GC(44268) User=1.30s Sys=0.00s Real=0.11s

[gc,start      ] GC(44269) Pause Young (Concurrent Start) (G1 Humongous Allocation)  // 并发阶段
[gc,task       ] GC(44269) Using 13 workers of 13 for evacuation
[gc,phases     ] GC(44269)   Pre Evacuate Collection Set: 0.6ms
[gc,phases     ] GC(44269)   Evacuate Collection Set: 90.9ms
[gc,phases     ] GC(44269)   Post Evacuate Collection Set: 3.2ms
[gc,phases     ] GC(44269)   Other: 2.9ms
[gc,heap       ] GC(44269) Eden regions: 1519->0(1855)
[gc,heap       ] GC(44269) Survivor regions: 65->65(240)
[gc,heap       ] GC(44269) Old regions: 777->777
[gc,heap       ] GC(44269) Humongous regions: 19->19
[gc,metaspace  ] GC(44269) Metaspace: 193280K->193280K(1230848K)
[gc            ] GC(44269) Pause Young (Concurrent Start) (G1 Humongous Allocation) 19024M->6883M(25600M) 97.391ms
[gc,cpu        ] GC(44269) User=1.16s Sys=0.01s Real=0.10s

[gc            ] GC(44270) Concurrent Cycle                                          // 完成 clearup
[gc,marking    ] GC(44270) Concurrent Clear Claimed Marks
[gc,marking    ] GC(44270) Concurrent Clear Claimed Marks 0.562ms
[gc,marking    ] GC(44270) Concurrent Scan Root Regions
[gc,marking    ] GC(44270) Concurrent Scan Root Regions 719.931ms
[gc,marking    ] GC(44270) Concurrent Mark (280799.914s)
[gc,marking    ] GC(44270) Concurrent Mark From Roots
[gc,task       ] GC(44270) Using 3 workers of 3 for marking
[gc,marking    ] GC(44270) Concurrent Mark From Roots 2268.905ms
[gc,marking    ] GC(44270) Concurrent Preclean
[gc,marking    ] GC(44270) Concurrent Preclean 3.078ms
[gc,marking    ] GC(44270) Concurrent Mark (280799.914s, 280802.186s) 2272.068ms
[gc,start      ] GC(44270) Pause Remark
[gc,stringtable] GC(44270) Cleaned string and symbol table, strings: 87967 processed, 92 removed, symbols: 442773 processed, 13 removed
[gc            ] GC(44270) Pause Remark 13740M->13740M(25600M) 32.599ms
[gc,cpu        ] GC(44270) User=0.29s Sys=0.00s Real=0.04s
[gc,marking    ] GC(44270) Concurrent Rebuild Remembered Sets            //重构记忆集
[gc,marking    ] GC(44270) Concurrent Rebuild Remembered Sets 1906.792ms
[gc,start      ] GC(44270) Pause Cleanup
[gc            ] GC(44270) Pause Cleanup 18019M->18019M(25600M) 0.782ms
[gc,cpu        ] GC(44270) User=0.00s Sys=0.01s Real=0.00s
[gc,marking    ] GC(44270) Concurrent Cleanup for Next Mark
[gc,marking    ] GC(44270) Concurrent Cleanup for Next Mark 25.530ms
[gc            ] GC(44270) Concurrent Cycle 4963.833ms

[gc,start      ] GC(44271) Pause Young (Prepare Mixed) (G1 Evacuation Pause)  // Space Reclamation 阶段了,多个 Mixed GC 会进行
[gc,task       ] GC(44271) Using 13 workers of 13 for evacuation
[gc,phases     ] GC(44271)   Pre Evacuate Collection Set: 0.1ms
[gc,phases     ] GC(44271)   Evacuate Collection Set: 102.6ms
[gc,phases     ] GC(44271)   Post Evacuate Collection Set: 3.7ms
[gc,phases     ] GC(44271)   Other: 3.9ms
[gc,heap       ] GC(44271) Eden regions: 1855->0(98)
[gc,heap       ] GC(44271) Survivor regions: 65->62(240)
[gc,heap       ] GC(44271) Old regions: 777->778
[gc,heap       ] GC(44271) Humongous regions: 21->19
[gc,metaspace  ] GC(44271) Metaspace: 193271K->193271K(1230848K)
[gc            ] GC(44271) Pause Young (Prepare Mixed) (G1 Evacuation Pause) 21739M->6869M(25600M) 110.034ms
[gc,cpu        ] GC(44271) User=1.32s Sys=0.01s Real=0.10s

[gc,start      ] GC(44272) Pause Young (Mixed) (G1 Evacuation Pause)
[gc,task       ] GC(44272) Using 13 workers of 13 for evacuation
[gc,phases     ] GC(44272)   Pre Evacuate Collection Set: 0.4ms
[gc,phases     ] GC(44272)   Evacuate Collection Set: 150.8ms
[gc,phases     ] GC(44272)   Post Evacuate Collection Set: 3.2ms
[gc,phases     ] GC(44272)   Other: 2.3ms
[gc,heap       ] GC(44272) Eden regions: 98->0(149)
[gc,heap       ] GC(44272) Survivor regions: 62->11(20)
[gc,heap       ] GC(44272) Old regions: 778->547
[gc,heap       ] GC(44272) Humongous regions: 19->19
[gc,metaspace  ] GC(44272) Metaspace: 193271K->193271K(1230848K)
[gc            ] GC(44272) Pause Young (Mixed) (G1 Evacuation Pause) 7653M->4605M(25600M) 156.486ms
[gc,cpu        ] GC(44272) User=1.95s Sys=0.01s Real=0.15s
[gc,start      ] GC(44273) Pause Young (Mixed) (G1 Evacuation Pause)
[gc,task       ] GC(44273) Using 13 workers of 13 for evacuation
[gc,phases     ] GC(44273)   Pre Evacuate Collection Set: 0.2ms
[gc,phases     ] GC(44273)   Evacuate Collection Set: 122.9ms
[gc,phases     ] GC(44273)   Post Evacuate Collection Set: 2.0ms
[gc,phases     ] GC(44273)   Other: 3.1ms
[gc,heap       ] GC(44273) Eden regions: 149->0(1900)
[gc,heap       ] GC(44273) Survivor regions: 11->20(20)
[gc,heap       ] GC(44273) Old regions: 547->520
[gc,heap       ] GC(44273) Humongous regions: 19->19
[gc,metaspace  ] GC(44273) Metaspace: 193271K->193271K(1230848K)
[gc            ] GC(44273) Pause Young (Mixed) (G1 Evacuation Pause) 5797M->4468M(25600M) 128.036ms
[gc,cpu        ] GC(44273) User=1.57s Sys=0.01s Real=0.12s

上面是连续几次 GC 的日志,可以对照着 GC 周期来看。

  • GC (44265) 是一次普通的 Young GC里面信息有各种 Region 的变化

这里简单说一下 humongous 对象的处理,humongous 对象在 G1 中是被特殊对待的,G1 只决定它们是否生存,回收他们占用的空间,从不会移动它们。

  • Young-Only 阶段,humongous regions 可能会被回收
  • Space-Reclamation,humongous regions 可能会被回收
  • GC (44269) 开始进入并发阶段
  • GC (44270) 完成了 Cleanup,紧接着一个 Prepare Mixed GC (44271) 的垃圾收集,对应周期虚线右边的蓝实心圆
  • GC (44272) 之后就是 Space Reclamation 阶段了,多个 Mixed GC 会进行

JVM 性能监控工具

我们可以通过以下几种工具辅助分析 JVM 性能瓶颈:

综合组件:

  • VisualVM
  • Glowroot
  • https://arthas.aliyun.com/

thread dump 分析:

  • https://fastthread.io/

gc 日志分析:

  • https://gceasy.io/gc-index.jsp

heap dump 分析:

  • https://www.ibm.com/support/pages/ibm-heapanalyzer
  • https://projects.eclipse.org/projects/tools.mat

参考资料

【GC 停顿预测模型】

  1. http://www.narihiro.info/g1gc-impl-book/scheduling.html
  2. https://sdww2348115.github.io/jvm/g1/PausePredictionModel

【垃圾收集器执行过程】

  1. https://bugs.openjdk.org/browse/JDK-8295118
  2. https://my.oschina.net/u/4273516/blog/4550072

【跨代引用】

  1. https://blog.csdn.net/weixin_47184173/article/details/113627337

【空闲时自动将Java堆内存返回给操作系统】

  1. https://openjdk.org/jeps/346

【其他】

  1. https://docs.oracle.com/javacomponents/jmc-5-4/jfr-runtime-guide/comline.htm#JFRUH197
  2. https://www.redhat.com/en/blog/part-1-introduction-g1-garbage-collector
  3. https://blog.csdn.net/qq_16500963/article/details/132133125
  4. http://cs.williams.edu/~dbarowy/cs334s18/assets/p37-detlefs.pdf
  5. https://tech.meituan.com/2016/09/23/g1.html
  6. https://hllvm-group.iteye.com/group/topic/44381
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2023-11-15,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 运维开发故事 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
java9系列(九)Make G1 the Default Garbage Collector
本文主要研究下JEP 248: Make G1 the Default Garbage Collector
code4it
2018/09/17
8350
JVM性能调优实践——G1 垃圾收集器分析、调优篇
这一篇先简单总结一下GC的种类,然后侧重总结下G1(Garbage-First)垃圾收集器的分代,结合open-jdk源码分析下重要算法如SATB,重要存储结构如CSet、RSet、TLAB、PLAB、Card Table等。最后会再梳理下G1 GC的YoungGC,MixedGC收集过程。
周三不加班
2019/09/04
4.8K0
JVM性能调优实践——G1 垃圾收集器分析、调优篇
G1垃圾收集器概述
开始学习前,抛出两个常见面试问题:1.G1的回收原理是什么?为什么G1比传统的GC回收性能好?2.为什么G1如此完美仍然会有ZGC?简单的回顾下CMS垃圾回收机制,下面介绍了一个极端的场景(而且是经常发生的) 在发生Minor GC时,由于Survivor区已经放不下了,多出的对象只能提升(Promotion)到老年代。但是此时老年代因为空间碎片的缘故,会发生Concurrent mode failure的错误。这个时候,就需要降级为Serial Old垃圾回收器进行收集。这就是比concurrent mode failure 更加严重的promotion failed的问题。一个简单的Minor,竟然能演化成耗时最长的Full GC。最要命的是,这个停顿时间是不可预知的。有没有一种方法,能够首先定义一个停顿时间,然后反向推算收集内容呢?就像是领导在年初制定KPI一样,分配的任务多久多干些,任务少就少干点。类似需要徒步一段很长的路,然后在路中有多个里程碑,到达一个后可以休息一会。G1的思路说起来类似,它不要求每次都把垃圾清理的干干净净,只是努力做它认为对的事情。我们要求G1,在任意1秒的时间内,停顿不得超过10ms,这就是在给它制定KPI。G1会尽量达成这个目标,它能够推算出本次要收集的大体区域,以增量的方式完成收集。这也是使用G1垃圾回收器不得不设置的一个参数:-XX:MaxGCPauseMilis=10
黑洞代码
2021/04/28
1K0
G1垃圾收集器概述
JVM性能调优实践(二)——G1 垃圾收集器分析、调优篇
关于G1 GC以及其他垃圾收集器的介绍可以参考前一篇JVM性能调优实践——G1 垃圾收集器介绍篇。了解了G1垃圾收集器的运行机制之后,就可以针对一些GC相关参数来调整内存分配以及运行策略。下文的调优主要针对G1垃圾收集器进行介绍,以及会分析一下G1 GC的日志格式。
周三不加班
2019/09/03
2.4K0
JVM G1(Garbage-First Garbage Collector)收集器全过程剖析
G1垃圾收集器的设计原则是“首先收集尽可能多的垃圾(Garbage First)”,目标是为了尽量缩短处理超大堆(超过4GB)产生的停顿。
斯武丶风晴
2020/05/09
1.4K0
JVM G1(Garbage-First Garbage Collector)收集器全过程剖析
用了很多年的 CMS 垃圾收集器,终于换成了 G1,真香!!
作者:Eric Fu 链接:https://ericfu.me/g1-garbage-collector/
Java技术栈
2021/06/16
1.1K0
Java GC Log 分析工具解析
了解 GC Log (垃圾收集日志)并不是一件容易的事情,至少对于大多数技术人员而已。毕竟,对于这玩意,需要我们能够深入地了解 Java 虚拟机的工作原理以及对应用程序的内存使用情况的理解。在此篇文章中,我们将跳过应用程序的分析,因为它与应用程序的应用程序不同,并且需要对代码的知识。我们将讨论的是可以借助哪些工具使得我们能够读取和分析从 JVM 中获取的垃圾收集日志,以便正确定位问题。
Luga Lee
2021/11/22
2K0
Java GC Log 分析工具解析
JVM性能调优实践—G1垃圾收集器全视角解析
本文将总结一下GC的种类,然后侧重总结下G1(Garbage-First)垃圾收集器的分代,结合open-jdk源码分析下重要算法如SATB,重要存储结构如CSet、RSet、TLAB、PLAB、Card Table等。最后会再梳理下G1 GC的YoungGC,MixedGC收集过程。
王知无-import_bigdata
2021/01/05
4.5K0
G1收集器图解
在JVM在启动时来决定每个小块,也就是region的大小。 JVM一般是把一整块堆切分成2000个小region。然后每个小region从1到32Mb不等。
全栈程序员站长
2022/06/30
4640
G1收集器图解
做数据开发就不需要了解G1了么?
G1(Garbadge First Collector)作为一款JVM最新的垃圾收集器,可以解决CMS中Concurrent Mode Failed问题,尽量缩短处理超大堆的停顿,在G1进行垃圾回收的时候完成内存压缩,降低内存碎片的生成。G1在堆内存比较大的时候表现出比较高吞吐量和短暂的停顿时间,而且已成为Java 9的默认收集器。未来替代CMS只是时间的问题。
王知无-import_bigdata
2019/12/19
9450
通过 G1 GC Log 重新认识 G1 垃圾回收器
但事实上,g1 由于他的诸多优势已经越来越多的受到 java 程序员的青睐,尤其在机器内存日益增大的今天,巨大的内存分区无疑会让 CMS 回收时间过长,而这已经成为程序员们无法忍受 CMS 最重要的一个原因。
用户3147702
2022/06/27
1.3K0
通过 G1 GC Log 重新认识 G1 垃圾回收器
JavaAgent技术应用和原理:JVM持久化监控
JavaAgent技术基于JVM工具接口(JVMTI),通过字节码插桩实现其功能,字节码增强技术就是一类对现有字节码进行修改或者动态生成全新字节码文件的技术。
后台技术汇
2024/12/23
841
JavaAgent技术应用和原理:JVM持久化监控
G1垃圾收集器(10)之mixed gc日志
并发标记日志 并发标记是全局的,与回收过程是两个阶段,所以并发标记可以说是独立的。 //并发标记 - 初始标记阶段,在年轻代GC中完成 100.070: [GC pause (G1 Evacuation Pause) (young) (initial-mark), 0.0751469 secs] [Parallel Time: 74.7 ms, GC Workers: 8] [GC Worker Start (ms): Min: 100070.4, Avg: 100070.5, Max: 100
黑洞代码
2021/06/23
1.3K0
详解 JVM Garbage First(G1) 垃圾收集器
G1(Garbage First)垃圾收集器是当今垃圾回收技术最前沿的成果之一。早在JDK7就已加入JVM的收集器大家庭中,成为HotSpot重点发展的垃圾回收技术。同优秀的CMS垃圾回收器一样,G1也是关注最小时延的垃圾回收器,也同样适合大尺寸堆内存的垃圾收集,官方也推荐使用G1来代替选择CMS。G1最大的特点是引入分区的思路,弱化了分代的概念,合理利用垃圾收集各个周期的资源,解决了其他收集器甚至CMS的众多缺陷。
全栈程序员站长
2022/07/01
8670
详解 JVM Garbage First(G1) 垃圾收集器
【愚公系列】2023年11月 大数据教学课程 012-JVM垃圾收集器以及内存分配
垃圾收集器是一种自动化程序,用于管理计算机内存中不再使用的数据,并在需要时回收它们。垃圾收集器有助于确保内存空间被充分利用,并且不会因为程序员的错误而产生内存泄漏问题。垃圾收集器可用于各种编程语言和平台,包括Java、Python、C#等。不同的垃圾收集器使用不同的回收算法,例如标记-清除、复制、标记-整理等。
愚公搬代码
2025/06/02
740
【愚公系列】2023年11月 大数据教学课程 012-JVM垃圾收集器以及内存分配
Java Hotspot G1 GC的一些关键技术
G1 GC,全称Garbage-First Garbage Collector,通过-XX:+UseG1GC参数来启用,作为体验版随着JDK 6u14版本面世,在JDK 7u4版本发行时被正式推出,相信熟悉JVM的同学们都不会对它感到陌生。在JDK 9中,G1被提议设置为默认垃圾收集器(JEP 248)。在官网中,是这样描述G1的:
大学里的混子
2019/03/04
6270
JVM之G1收集器
allocation failture,当收集垃圾,从一个区域复制数据到另一个区域时,找不到可用区域时,会引发allocation failture,进而引起full gc (stop the world)
WindWant
2020/09/11
4860
JVM之G1收集器
不标题党地学习G1
对于大多数人来说,Java的垃圾收集器就是一个黑盒子,这个黑盒子自己在里边愉快的玩耍,而我们却不太知道它内部的事情。
ImportSource
2018/07/25
7010
不标题党地学习G1
大厂面试题:有了 G1 还需要其他垃圾回收器吗?
我们在上一篇中,简要的介绍了 CMS 垃圾回收器,下面我们简单回忆一下它的一个极端场景(而且是经常发生的场景)。
小熊学Java
2023/09/19
3520
大厂面试题:有了 G1 还需要其他垃圾回收器吗?
G1 垃圾收集器深入剖析(图文超详解)
G1(Garbage First)垃圾收集器,是目前垃圾回收技术最前沿的成果之一。
mikechen的互联网架构
2022/11/02
4.8K0
G1 垃圾收集器深入剖析(图文超详解)
相关推荐
java9系列(九)Make G1 the Default Garbage Collector
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验