G1收集器优化总结

G1垃圾回收原理及参数优化
最新推荐文章于 2025-09-21 15:07:55 发布
原创 最新推荐文章于 2025-09-21 15:07:55 发布 · 319 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java #jvm #算法

         随着jdk的升级，原CP+CMS的垃圾回收机制 被G1替代，从jdk11开始默认为G1垃圾回收。

G1垃圾回收原理

        将内存分为2048个块，每块大小为1-32M，所以jvm的内存一定是2G-64G，所以如果内存不再此范围内需要进行复杂调参（不用G1更好）。对象存储在每个块中（region），会按块进行标记内存回收

edengc：初始标记为eden区，当到达一定阈值时进行回收，满阈值（8）到老年代

mixgc: eden和old一起标记，引用或满阈值标记到老年代，该回收回收，但不超过配置的

-XX:MaxGCPauseMillis 

fullgc: 一定要GC完

因为region本身不区分是否是old，所以不存在物理上的 年轻代 老年代，但也会逻辑上控制，默认eden的region在10%--60%之间，用以提高性能，但具体多少是根据GC情况动态调整的

参数优化

        根据以上，G1是一个自动调优的算法，主要影响参数：内存大小，暂停毫秒数

所以关键参数为：-Xms -Xmx -XX:MaxGCPauseMillis

因为时并发标记，而且有指定暂停时间，所以在高并发场景下，将参数值往大调即可，当然到达原CMS那种调优结果（如可控稳定fullGC）是很难的

深入解剖 G1 收集器的分区模型与调优策略
阿文的博客
05-20 257
分区结构灵活可预测的 GC 停顿混合回收提升吞吐支持并发标记、并发清理自动调整内存分区，减轻调优压力下一篇，垃圾回收（GC）基础原理，敬请关注！
G1收集器的Remembered Set跨Region引用处理优化
ma451152002的专栏
06-18 102
G1收集器的RSet优化是其高性能的关键，通过多层次设计、并发处理等技术实现了低延迟垃圾回收。
必知必会——G1收集器详解及调优
JavaMonsterr的博客
06-08 1024
故事发生在这周二的深夜。当时准备上一个需求，会导致服务中单个线程的IO变长，这个是预知的。在灰度中，发现了下游的服务dubbo请求超时数增加，脑海中立马想到了去查了底层存储的监控，发现底层存储服务的999线都正常，凭借着多年的经验，脑海中一个声音告诉我一定是服务GC出问题了。右边的请求超时个数是之前的10倍（涉及到公司业务保密，相关监控数据打码处理）然后看了服务的GC，果然单次gc的时间比之前增加了不少。当时立马找了下游的服务，告诉我这部分的超时是在范围允许之内的，心里终于松了一口气。于是继续搞其他的业务去
G1收集器调优
augsm的专栏
12-24 1398
本篇针对官网G1性能调优进行翻译，以此为调优理论依据。本文可作参考模板，在完全理解G1收集器的情况下后续会有更加详细的内容讲解。
JVM实战-G1参数调优
最新发布
吖脖（博）
09-21 1007
当在进行混合回收的过程中，由于无论是新生代还是老年代都是基于复制算法进行的，都需要将各个Region中的存活对象拷贝到别的Region中，此时如果一旦出现拷贝的过程中发现没有空闲的Region可以进行存储了，就会触发一次失败！在运行过程中，G1收集器会调整新生代和老年代的Region数量，主要是通过adapt代的大小来调整对象晋升的速度和年龄，从而达到为收集器设置的暂停时间目标，因此不建议手动设置新生代和老年代的大小，只要设置整个堆的大小即可。#设置新生代大小，默认5%，默认最大60%。
【JVM】G1收集器调优
ZQ741552720的博客
03-16 420
1. 使用G1垃圾收集器 修改配置参数，获取到gc日志，使用GCViewer分析吞吐量和响应时间 -XX:+UseG1GC Throughput Min Pause Max Pause Avg Pause GC count 99.16% 0.00016s 0.0137s 0.00559s ...
JVM性能调优-垃圾收集器G1详解
EverythingAtOnce的博客
01-19 2581
XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值，在混合回收的时候，对Region回收都是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region，然后这个Region中的垃圾对象全部清理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收就结束了。ZGC的停顿时间是在10ms以下，但是ZGC的执行时间还是远远大于这个时间的。
06_G1调优配置
migo_的专栏
05-05 2014
本章主要介绍，如果G1默认的一些配置无法满足你的需求，要如何进一步调优。
Java理解G1垃圾收集器.pdf
07-01
在G1收集器的工作流程中，区域可以被分为新生代（Young Generation）、老年代（Old Generation）和Survivor空间。新生代主要存放短生命周期的对象，而老年代则存放生命周期较长的对象。G1垃圾收集器会根据对象的存活...
高效内存管理与性能优化：Java Hotspot G1 GC全景解析
热门推荐
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
05-12 169万+
本文深入分析了 Java Hotspot G1 GC 的工作原理、特点以及优化策略。G1 GC 是一种为低延迟和高吞吐量设计的垃圾回收器，适用于大内存和高响应要求的应用。文章详细介绍了 G1 GC 的基本回收流程、各类垃圾回收策略，以及如何通过调优 JVM 参数来优化垃圾回收过程。通过监控工具和 GC 日志分析，开发者可以精准调整 G1 GC 的行为，提升应用的性能和响应速度。 参考文献、书籍及链接 1.https://tech.meituan.com/2016/09/23/g1.html 2.书
G1垃圾收集器1
08-03
### CMS收集器与G1收集器的比较 CMS（Concurrent Mark Sweep）收集器是一种并发的垃圾回收器，主要特点是尽可能减少Stop-the-World（STW）事件。然而，CMS在某些阶段仍然需要STW，比如初始标记和最终标记阶段。CMS...
G1详解
weixin_43390345的博客
09-26 3602
一 G1收集器 g1收集器是一个面向服务端的垃圾收集器适用于多核处理器、大内存容量的服务端系统。它满足短时间gc停顿的同时达到一个较高的吞吐量。JDK7以上版本适用 “ 先介绍两个概念：吞吐量和响应能力，响应能力和吞吐量是评价一个系统的两个重要指标 吞吐量 吞吐量关注的是,在一个指定的时间内,最大化一个应用的工作量。如下方式来衡量一个系统吞吐量的好坏：在一定时间内同一个事务(或者任务、请求)完成的次数(tps)数据库一定时间以完成多少次查询对于关注吞吐量的系统,一定次数卡顿（即stw）是可以接受的,因为
深入理解 Java G1 垃圾收集器--转
12-23 2864
原文地址：http://blog.jobbole.com/109170/?utm_source=hao.jobbole.com&utm_medium=relatedArticle 本文首先简单介绍了垃圾收集的常见方式，然后再分析了G1收集器的收集原理，相比其他垃圾收集器的优势，最后给出了一些调优实践。 一，什么是垃圾回收 首先，在了解G1之前，我们需要清楚的知道，垃圾回收是...
jvm 垃圾收集器（G1）
weixin_43931625的博客
03-25 380
jvm垃圾收集器（ZGC）
G1垃圾收集器详解以及调优参数设置
搓搓那年时光静好
03-10 7031
（1）G1垃圾回收器，将堆内存进行了更细致的划分和管理，分为一个个Region。每个Region大小是2的整数倍。可以理解，将堆内存划分成一个Region池子。这里的每个Region，可能属于新生代，也可能属于老年代使用。 （2）G1回收器对新生代和老年代都会进行工作，使用复制回收算法，可以高效，并且避免内存碎片的产生。 （3）G1还规划了一个大对象Region区域。这是G1特有的一个专门用来存放大对象的地方。默认超过1/2 Region大小的对象就是大对象。 （4）G1中，新生代和老年代的大小是不固
JVM垃圾回收器-G1垃圾收集器
FLY的博客
07-22 1767
jvm G1 垃圾回收 java cms
G1垃圾回收器参数调优：优化性能，提升系统稳定性
C_19870的博客
11-23 892
如果没有设置新生代最大值和最小值，或者只设置了最大值和最小值中的一个，那么G1垃圾回收器会根据参数G1MaxNewSizePercent（默认值为60）和G1NewSizePercent（默认值为5）占整个堆空间的比例来计算最大值和最小值，并动态平衡来分配新生代空间。如果应用程序的内存占用量较大，可以考虑增加这个值，以减少堆区域的数量，从而提高垃圾回收的效率。默认值为200毫秒。通过以上的参数调优和优化策略，可以提升G1垃圾回收器的性能和效率，从而提升系统的稳定性和响应速度。
十、G1垃圾回收器
qq_45128800的博客
05-25 937
Region可以继续细分的：HHR（大对象区：当一个对象大小超过Region的1.5倍时）：大对象头分区、大对象连续区老年代分区：Old Generation在jdk11后，还有归档区（关闭归档区，开启归档区），用的是堆外内存Region总共2048个，大小1~32M。为什么都是2的N次幂？2的N次在位运算的时候效率是最高的。
jvm实用调优参数（G1）
m0_55613022的博客
04-19 1946
性能参数： 参数名称 含义 默认值 描述 性能参数 -Xms 初始堆大小 物理内存的1/64(<1GB) 默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制. -Xmx 最大堆大小 物理内存的1/4(<1GB) 默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制， 一般这两个值会设置成一致的，避免在GC完之后动态的调整堆大小，调整内存会消耗系统资源，对应用会有影响 -X
G1 收集器是怎么处理大对象的？
09-01
<think>好的，用户问的是G1收集器如何处理大对象。我需要先回忆一下G1的基本机制，特别是关于大对象的处理方式。G1将堆内存划分为多个大小相等的Region，每个Region可以是Eden、Survivor或Old区的一部分。大对象的处理在G1中有特殊处理，因为它们可能无法放入单个Region中。 首先，大对象在G1中被称为Humongous对象。当一个对象的大小超过一个Region的一半时，就会被标记为Humongous。这时候，G1会将这些对象直接分配到老年代的Humongous Region中。这可能与普通对象不同，普通对象通常先分配到年轻代，经过多次GC后晋升到老年代。 接下来，需要考虑Humongous对象的回收时机。由于它们位于老年代，通常会在Mixed GC中被回收。Mixed GC会同时处理年轻代和部分老年代的Region，包括Humongous Region。但这里可能存在效率问题，因为Humongous对象可能占用多个连续的Region，回收时需要处理这些连续区域。 另外，Humongous对象的分配和回收可能会导致内存碎片。因为它们需要连续的多个Region，如果频繁分配和释放大对象，可能导致无法找到足够大的连续空间，从而触发Full GC，这会影响性能。G1如何管理这些Humongous Region的分配和回收策略是关键点。 还需要提到G1的一些优化措施，比如Humongous对象的回收时机，是否在Young GC中处理，或者只在Mixed GC中处理。此外，可能涉及参数调优，如调整Region大小，或者控制Humongous对象的分配阈值，以减少内存浪费。 用户可能关心如何避免大对象导致的性能问题，比如Full GC频繁发生。这时候需要给出建议，如合理设置Region大小，避免频繁创建大对象，或者使用特定参数来优化Humongous分配。 最后，要检查是否有遗漏点，比如Humongous对象的标记和根节点处理，是否影响并发标记阶段的效率。可能还要提到G1对Humongous对象的特殊标记过程，比如在标记阶段如何处理这些大对象，以及回收后的内存整理策略。 总结回答结构：先解释Humongous对象的定义和分配策略，再说明其回收机制，接着讨论可能的性能问题及优化方法，最后给出相关问题建议。</think>G1（Garbage-First）垃圾收集器通过 **Humongous Region** 机制处理大对象（通常指大小超过单个Region容量50%的对象），其核心策略如下： --- ### **1. 大对象的定义与分配** - **判定阈值**： 当对象大小超过 **单个Region容量的一半**（默认值，可通过`-XX:G1HeapRegionSize`调整Region大小，范围1MB~32MB），则被标记为Humongous对象。 - **分配规则**： - Humongous对象**直接分配到老年代的Humongous Region**（而非年轻代），避免频繁复制。 - 若对象需要多个连续Region（如大小为3.5个Region），G1会分配连续的Humongous Region链。 --- ### **2. Humongous Region的管理** - **存储结构**： - 每个Humongous Region链由**起始Region**和**连续的辅助Region**组成，起始Region记录对象头信息。 - **内存浪费问题**：若对象未占满最后一个Region，剩余空间无法复用（类似内存对齐的开销）。 - **回收策略**： - Humongous对象的回收**仅在Mixed GC阶段触发**（不参与Young GC），通过标记-清理算法回收。 - 回收时会释放整个Region链，避免碎片化。 --- ### **3. 性能影响与优化** - **潜在问题**： 1. **内存浪费**：小对象占用大Region或未填满最后一个Region链。 2. **分配压力**：频繁创建Humongous对象可能导致Region链分配失败，触发Full GC。 3. **标记开销**：并发标记阶段需扫描Humongous对象，增加CPU负载。 - **优化建议**： 1. **调整Region大小**： 若应用频繁分配大对象，可增大`G1HeapRegionSize`（如从默认4MB调整为8~16MB），减少Region链数量。 ```bash -XX:G1HeapRegionSize=8M ``` 2. **控制Humongous分配阈值**： 通过`-XX:G1HumongousThreshold`调整大对象判定阈值（默认50%）。 ```bash -XX:G1HumongousThreshold=60 # 提高阈值，减少Humongous对象数量 ``` 3. **监控GC日志**： 关注Humongous对象的分配与回收频率，避免Full GC频繁触发。 ```bash # GC日志示例（Humongous对象分配） [allocation failure] GC pause (G1 Evacuation Pause) (young) (to-space exhausted) ``` --- ### **4. 回收流程示例** ```bash # Mixed GC回收Humongous对象的GC日志片段 [GC pause (Mixed) (1111111K->1010101K, 0.1234567 secs] [Eden: 1234M(1234M)->0B(1234M) Survivors: 123M->123M Heap: 1111111K(2222222K)->1010101K(2222222K)] [Humongous regions: 45->30] # Humongous Region数量从45减少到30 ``` --- ### **关键参数总结** | 参数 | 作用 | 示例值 | |------|------|--------| | `-XX:G1HeapRegionSize` | 设置Region大小 | 8M | | `-XX:G1HumongousThreshold` | 调整Humongous对象判定阈值 | 60 | | `-XX:MaxGCPauseMillis` | 控制目标停顿时间（影响Mixed GC频率） | 200 | ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值