Garbage First - Card Table

最新推荐文章于 2025-08-23 14:38:11 发布
原创 最新推荐文章于 2025-08-23 14:38:11 发布 · 131 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#.net #HTML

本文通过探讨CardTable在GarbageFirst垃圾回收器中的应用,为读者提供了对该技术的深入了解。文章揭示了CardTable如何帮助提升垃圾回收效率。

之前一直以为只是在Garbage First垃圾回收器中，有Card Table，终于在这篇文章中有些提示，让我对Card Table的作用有了清晰的认识，对Garbage First基本上有所了解了，应该可以进行总结了。。。。。。

 

http://vrlinux.com/wenzhangjingxuan/20101115/79907_2.html

http://www.blogjava.net/BlueDavy/archive/2009/03/11/259230.html

详解 JVM Garbage First(G1) 垃圾收集器
专注基础架构领域
07-29 698
G1(Garbage First)垃圾收集器是当今垃圾回收技术最前沿的成果之一。早在JDK7就已加入JVM的收集器大家庭中，成为HotSpot重点发展的垃圾回收技术。同优秀的CMS垃圾回收器一样，G1也是关注最小时延的垃圾回收器，也同样适合大尺寸堆内存的垃圾收集，官方也推荐使用G1来代替选择CMS。G1最大的特点是引入分区的思路，弱化了分代的概念，合理利用垃圾收集各个周期的资源，解决了其他收集器甚至CMS的众多缺陷。G1是一款非常优秀的垃圾收集器，不仅适合堆内存大的应用，同时也简化了调优的工作。
JVM调优:卡表（CardTable）简介
z69183787的专栏
03-18 8980
我们知道，JVM在进行垃圾收集时，需要先标记所有可达对象，然后再清除不可达对象，释放内存空间。那么，如何快速的找到所有可达对象呢？ 最简单粗暴的实现，就是每次进行垃圾收集时，都对整个堆中的所有对象进行扫描，找到所有存活对象。逻辑是简单，但性能比较差。 简单粗暴的实现方式，通常都是不可取的。那JVM是如何实现快速标记可达对象的？ 答案是GC Roots。 GC Roots是垃圾收集器寻找可达...
Java内存管理（三）——卡片表
EthanPark的博客
05-24 3446
在垃圾回收的过程中，会碰到一个问题，就是老年代中的对象可能引用年轻代中的对象。在这种情况下，每次遍历老年代的对象来查找所有存活对象的时候就会消耗相当的时间。而且，在应用中，通常来说，这种引用是非常少的（某些研究表明，这种情况的引用占总引用量的1%都不到）。但是这些引用需要遍历整个老年代对象是一个相当大的Overhead。Card-tableJVM中会维护一个卡片表的数据结构，主要用于查看老年代中指向
JVM（4）原理篇
qq_45968392的博客
02-14 2968
1、着色指针(Colored Pointers）着色指针将原来的8字节保存地址的指针拆分成了三部分，不仅能保存对象的地址，还可以保存当前对象所属的状态。不支持32位系统、不支持指针压缩2、读屏障（Load Barrier）在获取对象引用判断对象所属状态，如果所属状态和当前GC阶段的颜色状态不一致，由用户线程完成本阶段的工作。会损失一部分的性能，大约在5%~10%之间。1、着色指针(Colored Pointers）
JVM-卡表
左灯右行的爱情
04-23 1193
卡表本质上是一个字节数组（byte[]。它将整个堆内存划分成固定大小的连续区域，每个区域称为一个“卡页（Card Page）”或“卡（Card）”（通常是 2 的幂次方大小，如 512 字节）。卡表中的每一个字节都对应堆内存中的一个卡页。画一个堆内存条，下面对应一个卡表数组，展示其映射关系。卡表中每个字节的值代表其对应卡页的状态。最简单的实现中，有两种状态：通常用 0 表示，意味着对应的卡页“可能没有”需要关心的引用（具体含义看应用场景）。
JVM进阶之卡表
Deronn的博客
09-05 1609
卡表
Garbage-First (G1) 收集器
Road_的专栏
02-02 589
一、G1收集器简述 Garbage First 简称(G1) 收集器是一款面向服务端应用的垃圾收集器，从 JDK9 开始也是服务端模式下的默认垃圾收集器。它可以说是垃圾收集器发展中一个重要的里程碑，因为它提出了面向局部收集的设计思想和基于Region的内存布局形式。在JDK 7刚刚确立项目目标时，其实就已经把G1作为一个重要的进化特征，直到JDK7 Update 4，Oracle才认为其够商业的使用，到JDK8Update 40的时候，G1提供了并发类卸载功能，完成了计划的全部功能。此后的JDK版本才被O
JVM（八）深入理解G1 GC（Garbage First）
m0_58466443的博客
08-06 2265
探讨了G1垃圾回收器，一种在Java虚拟机中用于老年代垃圾回收的算法。G1的设计目标是减少停顿时间，适用于对延迟敏感的应用。它通过多个阶段实现垃圾回收，包括初始标记、并发标记、重新标记和并发清理。文章详细描述了这些阶段的工作原理和G1如何处理内存碎片问题。虽然G1能减少停顿时间，但它也有缺点，如内存碎片、需要预留空间处理浮动垃圾，以及更高的CPU资源消耗。随着新垃圾回收器如ZGC的出现，G1的使用正在逐渐减少，但对于运行在Java 8及以下版本的应用，G1的优化仍然重要。
G1 (Garbage-First) 垃圾收集器详解
最新发布
zwh1zwh的博客
08-23 1025
​可控的停顿时间​：可以设定明确的停顿时间目标。​高吞吐量​：整体效率很高。​空间整合​：基于“标记-整理”算法，不会产生内存碎片。​灵活的堆内存管理​：Region 模型使得新生代和老年代的大小不再固定，可以动态调整。G1 垃圾收集器通过将堆划分为 Region、使用 ​​ 来记录跨代引用、以及优先回收垃圾最多的区域 (Garbage-First)​​ 的策略，成功地在可预测的短暂停顿时间内实现了高吞吐量，并有效避免了内存碎片。它是处理大堆内存、低延迟要求的服务器端应用的理想选择。
【Java 8 GC 调优】Garbage-First（G1）
一个被IT搞的
02-19 860
G1 是一个 服务器风格（Server-Style）的垃圾收集器。其适用目标是具有大内存的多处理器计算机。它试图在实现高吞吐量的同时，高概率地满足 GC暂停时间 目标。整个堆操作，如 全局标记，与业务线程同时运行。这可以防止 中断的发生概率 与 堆或存活数据大小 成比例。 G1 通过几种技术实现了 高性能 和 暂停时间 目标。 堆被划分成一些大小相等的区域，每个区域都是一片连续的虚拟内存（vi...
【深入理解JVM】JVM-卡表（Card Table）
天天新知
11-22 3421
我们知道，JVM在进行垃圾收集时，需要先标记所有可达对象，然后再清除不可达对象，释放内存空间。那么，如何快速的找到所有可达对象呢？ 最简单粗暴的实现，就是每次进行垃圾收集时，都对整个堆中的所有对象进行扫描，找到所有存活对象。逻辑是简单，但性能比较差。 简单粗暴的实现方式，通常都是不可取的。那JVM是如何实现快速标记可达对象的？ 答案是GC Roots。 简介 现代JVM，堆空间通常被划分为新生代和老年代。由于新生代的垃圾收集通常很频繁，如果老年代对象引用了新生代的对象，那么，需要跟踪从老年代...
G1 Java垃圾回收 rset card table
stevewong的专栏
04-15 2802
这个结构可以看得比较清楚RSet和Cardtable了 https://youtu.be/Gee7QfoY8ys 每个region都有一个Rset，记录了哪些region的哪些对象引用了本region的对象。 如图所示，站在EDEN region的角度，Old Region的B对象引用了我的E对象，C对象引用了我的D对象，所以在我的Rset里保存了B和D对象的内存地址（是一个范围） 结...
JVM之卡表（Card Table）
weixin_33896726的博客
01-12 4913
我们知道，JVM在进行垃圾收集时，需要先标记所有可达对象，然后再清除不可达对象，释放内存空间。那么，如何快速的找到所有可达对象呢？ 最简单粗暴的实现，就是每次进行垃圾收集时，都对整个堆中的所有对象进行扫描，找到所有存活对象。逻辑是简单，但性能比较差。 简单粗暴的实现方式，通常都是不可取的。那JVM是如何实现快速标记可达对象的？ 答案是GC Roots。 GC Roots是垃圾收集器寻找可达对象的起...
jvm的card table数据结构
weixin_34249367的博客
03-24 476
jvm系列 垃圾回收基础 JVM的编译策略 GC的三大基础算法 GC的三大高级算法 GC策略的评价指标 JVM信息查看 GC通用日志解读 jvm的card table数据结构 Java类初始化顺序 Java对象结构及大小计算 Java的类加载机制 Java对象分配简要流程 年老代过大有什么影响 Survivor空间溢出实例 关于Obje...
JVM笔记（三）垃圾收集算法以及HotSpot的算法实现(安全点、记忆集与卡表、写屏障、三色标记等)
一颗小陨石的博客
03-15 2803
目录一、垃圾收集算法1.1 堆的布局1.2 GC类型1.2.1 Minor GC流程1.2.2 分配担保1.3 内存分配策略二、垃圾收集算法2.1 标记-清除算法2.2 标记-复制算法2.3 标记-整理算法三、HotSpot的算法细节实现3.1 根节点枚举3.2 安全点如何在垃圾收集时让所有线程跑到最近的安全点停顿下来3.3 安全区域原理3.4 记忆集与卡表3.4.1 记忆集的实现卡表3.5 写屏...
炸了! 阿里巴巴面试官一口气问了我 18 个 JVM 问题!
m0_50180963的博客
11-13 262
前言 GC 对于Java 来说重要性不言而喻，不论是平日里对 JVM 的调优还是面试中的无情轰炸。 这篇文章我会以一问一答的方式来展开有关 GC 的内容。 不过在此之前强烈建议先看这个视频【理论篇+实战篇】关于JVM性能调优知识看这一个视频就够了 因为这个视频解释了很多有关垃圾回收的基本知识，能从源头上理解垃圾回收和日益发展的垃圾收集器演进的方向，这很重要。 本文章所说的 GC 实现没有特殊说明的话，默认指的是 HotSpot 的。 我先将十八个问题都列出来，如果都清楚的话那就可以关闭这篇文章了
MySQL万字精华总结！你连基础的JVM运行时内存布局都忘了？含面试题+答案
m0_56037919的博客
03-16 648
前言 Netty 是一款基于 Java 的网络编程框架，能为应用程序管理复杂的网络编程、多线程处理以及并发。Netty 隐藏了样板和底层代码，让业务逻辑保持分离，更加易于复用。使用 Netty 可以得到一个易于使用的 API，让开发人员可以专注自己的应用程序的独特之处。介绍了 Netty 框架，并展示了如何将它引入到 Java 网络应 用程序中通过对本书的学习，读者能学到如何编写高度可伸缩的应用程序而无需关心底层 API。本书将通过许多动手的例子教读者以异步的方式进行思考，并帮助读者掌握构建大规模网络应用程
java 卡表_jvm-卡表，垃圾回收时的重要手段
weixin_34965737的博客
02-12 929
背景最近在跟同事进行jvm垃圾回收的交流，讨论到通过GC Roots进行对象的可达性分析，标记存活对象的时候，同事提出了一个疑问，因为年轻代中发生minor gc的频率很高，如果在经常会扫描年轻代中的对象进行标记，如果老年代中有对象引用了年轻代中的对象，那岂不是每次进行minor gc时也要进行全堆的扫描？嘿嘿，其实不然，jvm引入了卡表(card table)技术来解决这个问题。卡表(card ...
JVM四种对象引用类型
iteye_5555的博客
05-17 188
JVM 中将对象的引用分为了四种类型，不同的对象引用类型会造成GC 采用不同的方法进行回收： 1.强引用 默认情况下，对象采用的均为强引用，例如： A a=null; public void execute(){ a=new A();， // 其他代码 } 只有当execute 所在的这个对象的实例没有其他对象引用，GC 时才会被回收。 2.软引用（Soft Refe...
G1垃圾回收器的工作原理和调优参数
08-07
<think>我们正在讨论G1垃圾回收器（Garbage-First）的工作原理和调优参数。根据引用内容，G1是在Java7 update4之后引入的，旨在降低暂停时间的同时兼顾高吞吐量，适用于大内存和多处理器的场景。下面我将详细解释G1的工作机制和常用调优参数。 ### 一、G1垃圾回收器的工作原理 G1是一种面向服务端应用的垃圾回收器，它采用分区的思想，将整个堆空间划分为多个大小相等的区域（Region）。这些区域可以是Eden区、Survivor区、Old区或Humongous区（用于存放大对象）。G1通过可预测的停顿模型，允许用户设置期望的停顿时间目标（如`-XX:MaxGCPauseMillis`），并尽力在该时间内完成垃圾回收。 #### 1. **内存布局** - **区域（Region）**：堆被划分为多个Region，每个Region的大小在1MB到32MB之间，且必须是2的幂。Region的大小可以通过`-XX:G1HeapRegionSize`设置。 - **区域类型**： - **Eden Regions**：新对象分配的区域。 - **Survivor Regions**：存放年轻代GC后存活的对象。 - **Old Regions**：存放长时间存活的对象。 - **Humongous Regions**：存放大小超过Region一半的大对象，连续分配。 #### 2. **垃圾回收过程** G1的垃圾回收过程分为两个阶段：**年轻代GC（Young GC）**和**混合回收（Mixed GC）**。 - **年轻代GC（Young GC）**： - 当Eden区满时触发，只回收Eden区和Survivor区。 - 采用复制算法，将存活对象复制到新的Survivor区或晋升到Old区。 - 该过程需要STW（Stop-The-World），但时间较短。 - **混合回收（Mixed GC）**： - 当堆内存使用达到一定阈值（由`-XX:InitiatingHeapOccupancyPercent`设置，默认45%）时触发。 - 回收范围包括整个年轻代和部分老年代（根据预测选择回收价值最高的Region，即垃圾最多的Region，这也是“Garbage-First”名称的由来）。 - 同样采用复制算法，将存活对象复制到空闲Region。 - 混合回收可能分多次进行，每次回收一部分Region，以控制停顿时间。 - **Full GC**： - 当混合回收速度跟不上对象分配速度，或者无法找到足够的空闲Region时，会触发Full GC（单线程的Serial Old GC），此时停顿时间会很长。因此，应尽量避免Full GC。 #### 3. **核心算法** - **SATB（Snapshot-At-The-Beginning）**： - G1使用SATB算法处理并发标记阶段的漏标问题。它在标记开始时对堆内存做快照，确保标记过程中新分配的对象不会被遗漏。 - **RSet（Remembered Set）**： - 每个Region都有一个RSet，用于记录其他Region中的对象对本Region的引用。这样在回收某个Region时，无需扫描整个堆，只需扫描RSet即可确定跨代引用。 #### 4. **工作流程** 1. **初始标记（Initial Mark）**：标记从GC Roots直接可达的对象，伴随一次Young GC，STW。 2. **并发标记（Concurrent Marking）**：从GC Roots开始进行可达性分析，找出存活对象，与用户线程并发执行。 3. **最终标记（Final Marking）**：处理SATB缓冲区，修正并发标记期间变动的引用，STW。 4. **筛选回收（Evacuation）**：根据回收价值和停顿时间要求，选择Region进行回收（复制存活对象），STW。 ### 二、G1常用调优参数 | **参数** | **默认值** | **说明** | |----------|------------|----------| | `-XX:+UseG1GC` | - | 启用G1垃圾回收器 | | `-XX:MaxGCPauseMillis` | 200ms | 设置期望的最大停顿时间目标（非硬性保证） | | `-XX:InitiatingHeapOccupancyPercent` | 45% | 触发并发标记周期的堆占用率阈值 | | `-XX:G1HeapRegionSize` | 根据堆大小计算 | 设置Region大小（1MB~32MB，2的幂） | | `-XX:G1NewSizePercent` | 5% | 年轻代占堆的最小比例 | | `-XX:G1MaxNewSizePercent` | 60% | 年轻代占堆的最大比例 | | `-XX:ConcGCThreads` | 根据CPU计算 | 并发标记阶段使用的线程数 | | `-XX:ParallelGCThreads` | 根据CPU计算 | 并行回收阶段的线程数（如Young GC） | | `-XX:G1ReservePercent` | 10% | 堆内存保留比例，用于晋升失败时的备用空间 | | `-XX:G1HeapWastePercent` | 5% | 允许的堆浪费百分比，达到该值会触发混合回收 | #### 调优建议： 1. **设置停顿时间目标**：根据应用需求调整`-XX:MaxGCPauseMillis`（如50ms），但设置过小可能导致频繁GC。 2. **避免Full GC**： - 增加`-XX:InitiatingHeapOccupancyPercent`（如60%），避免过早触发混合回收。 - 增大`-XX:G1ReservePercent`（如15%），预留更多空间应对晋升失败。 3. **调整Region大小**：大对象较多时，可增大`-XX:G1HeapRegionSize`减少Humongous对象。 4. **并发线程数**：高并发场景可增加`-XX:ConcGCThreads`加速标记过程。 ### 三、适用场景 - 堆内存较大（>6GB）且要求低延迟的应用。 - 需要平衡吞吐量和停顿时间的场景。 - 替代CMS，避免老年代碎片问题。 > 通过合理调优，G1可在满足低延迟的同时保持较高吞吐量[^1][^3]。 --- ### 相关问题 1. **G1与ZGC/Shenandoah在延迟控制上有何差异？** 2. **如何诊断G1的Full GC问题？** 3. **G1的RSet如何维护？对性能有何影响？** 4. **G1的混合回收阶段如何选择回收的Region？** 5. **G1的SATB算法如何解决漏标问题？**</think>### G1垃圾回收器工作原理 G1（Garbage-First）是JDK 7u4引入的面向服务端应用的垃圾回收器，其核心设计目标是在**可控的停顿时间**内实现**高吞吐量**，特别适合大内存（>6GB）和多核CPU环境[^1][^3]。以下是其工作原理的核心机制： --- #### 1. **分区化内存布局** - **Region结构**：将堆划分为多个大小相等的区域（Region，默认2,048个），每个Region可以是Eden、Survivor、Old或Humongous（存放大对象）区。 - **动态角色分配**：Region类型在GC过程中动态变化，避免传统分代模型的固定划分。 - **优势**：允许更灵活的内存管理，减少内存碎片。 #### 2. **回收过程分阶段** | **阶段** | **工作内容** | **是否STW** | **耗时占比** | |-------------------|---------------------------------------------|-------------|--------------| | **年轻代GC** | 回收Eden+Survivor区（复制算法） | STW | 短（毫秒级） | | **并发标记** | 扫描堆中存活对象（SATB算法） | 并发 | 长 | | **混合回收** | 回收年轻代+高收益老年代Region（复制算法） | STW | 可控 | | **Full GC** | 仅当回收速度跟不上分配速度时触发（应避免） | STW | 长 | #### 3. **核心算法机制** - **RSet（记忆集）** 每个Region维护一个RSet，记录其他Region对本Region的引用。GC时只需扫描RSet而非全堆，减少扫描范围。 ```java // 伪代码：RSet记录跨Region引用 class Region { HashTable<Region*, CardTable*> rset; // 记录引用来源 } ``` - **SATB（Snapshot-At-The-Beginning）** 并发标记开始时对堆做快照，确保标记期间新分配对象不被遗漏，解决“漏标”问题[^1]。 - **停顿预测模型** 基于历史GC数据预测本次回收时间，动态选择回收Region数量以满足`-XX:MaxGCPauseMillis`目标。 #### 4. **回收策略（Garbage-First来源）** 1. 计算每个Region的**回收价值**（垃圾比例 × 回收速度） 2. 优先回收垃圾比例最高的Region（即Garbage-First） 3. 在停顿时间内回收尽可能多的内存 --- ### 关键调优参数 #### 基础参数 | **参数** | **默认值** | **说明** | |-----------------------------------|------------|--------------------------------------------------------------------------| | `-XX:+UseG1GC` | - | 启用G1回收器（必需参数） | | `-XX:MaxGCPauseMillis` | 200ms | **核心目标**：期望最大停顿时间（非硬性保证）[^1] | | `-XX:InitiatingHeapOccupancyPercent` | 45% | 触发并发标记的老年代占用阈值（建议监控调整） | #### 内存与线程控制 | **参数** | **默认值** | **调优建议** | |------------------------------|------------------|---------------------------------------------| | `-XX:G1HeapRegionSize` | 根据堆大小计算 | 大堆（>32GB）建议设16-32MB | | `-XX:G1NewSizePercent` | 5% | 年轻代最小占比，根据对象分配速率调整 | | `-XX:G1MaxNewSizePercent` | 60% | 年轻代最大占比 | | `-XX:ConcGCThreads` | ≈1/4 CPU核心数 | 并发标记线程数（CPU密集时增加） | | `-XX:ParallelGCThreads` | =CPU核心数 | 并行回收线程数（STW阶段使用）[^2] | #### 高级调优 | **参数** | **场景** | |-----------------------------------|--------------------------------------------------------------------------| | `-XX:G1ReservePercent=15` | 防止晋升失败（OOM）的保留内存（默认10%，大堆可增至15-20%） | | `-XX:G1HeapWastePercent=5` | 触发混合回收的堆垃圾比例阈值（默认5%，降低可提前回收） | | `-XX:G1MixedGCCountTarget=8` | 混合回收阶段的最大回收次数（增加可降低单次停顿时间） | --- ### 调优实践建议 1. **目标停顿时间** ```bash -XX:MaxGCPauseMillis=100 # 典型值100-200ms ``` 设置过高可能导致Full GC；过低会过度收缩年轻代，引发频繁GC。 2. **避免Full GC** - 增加`G1ReservePercent`预留内存 - 降低`InitiatingHeapOccupancyPercent`（如40%）提前触发并发标记 - 监控`GC Pause`和`Allocation Rate`（工具：GC日志+Prometheus） 3. **大对象优化** ```bash -XX:G1HeapRegionSize=16m # 若Humongous对象过多 -XX:G1MixedGCLiveThresholdPercent=85 # 跳过存活率高的老年代Region ``` > 通过合理调优，G1可做到99.9%停顿<200ms，吞吐量>90%[^3]。 --- ### 与其他回收器对比 | **场景** | **推荐回收器** | **原因** | |------------------|----------------------|------------------------------------------| | 客户端/小堆 | Serial GC | 低开销 | | Web服务（JDK8+） | **G1**（默认） | 平衡停顿与吞吐[^3] | | 金融/实时系统 | ZGC | 亚毫秒级停顿（JDK15+） | | 大数据计算 | Parallel GC | 最大化吞吐量[^3] | --- ### 相关问题 1. **G1的SATB算法如何解决并发标记期间的漏标问题？** 2. **如何通过GC日志诊断G1的Full GC原因？** 3. **G1与ZGC在内存布局和回收策略上有何本质区别？** 4. **为什么G1适合大堆而CMS不适合？** 5. **如何监控G1的RSet对性能的影响？**
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值