JVM之卡表（Card Table）

最新推荐文章于 2025-04-23 09:56:34 发布
最新推荐文章于 2025-04-23 09:56:34 发布
阅读量4.8k 收藏 7
点赞数
CC 4.0 BY-SA版权
文章标签： java 数据库 运维
原文链接：https://juejin.im/post/5c39920b6fb9a049e82bbf94
本文深入探讨了JVM中的卡标记（CardMarking）技术，解释了其在垃圾回收过程中如何通过卡表和写屏障优化对GCRoots的扫描，以减少YGC时的老年代扫描开销，特别是在高并发环境下的性能提升。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

我们知道，JVM在进行垃圾收集时，需要先标记所有可达对象，然后再清除不可达对象，释放内存空间。那么，如何快速的找到所有可达对象呢？

最简单粗暴的实现，就是每次进行垃圾收集时，都对整个堆中的所有对象进行扫描，找到所有存活对象。逻辑是简单，但性能比较差。

简单粗暴的实现方式，通常都是不可取的。那JVM是如何实现快速标记可达对象的？

答案是GC Roots。

GC Roots是垃圾收集器寻找可达对象的起点，通过这些起始引用，可以快速的遍历出存活对象。GC Roots最常见的是静态引用和堆栈的局部引用变量。然而，这不是我们这讲的重点：)

现代JVM，堆空间通常被划分为新生代和老年代。由于新生代的垃圾收集通常很频繁，如果老年代对象引用了新生代的对象，那么，需要跟踪从老年代到新生代的所有引用，从而避免每次YGC时扫描整个老年代，减少开销。

对于HotSpot JVM，使用了卡标记（Card Marking）技术来解决老年代到新生代的引用问题。具体是，使用卡表（Card Table）和写屏障（Write Barrier）来进行标记并加快对GC Roots的扫描。

卡表（Card Table）

基于卡表（Card Table）的设计，通常将堆空间划分为一系列2次幂大小的卡页（Card Page）。

卡表（Card Table），用于标记卡页的状态，每个卡表项对应一个卡页。

HotSpot JVM的卡页（Card Page）大小为512字节，卡表（Card Table）被实现为一个简单的字节数组，即卡表的每个标记项为1个字节。

当对一个对象引用进行写操作时（对象引用改变），写屏障逻辑将会标记对象所在的卡页为dirty。

OpenJDK/Oracle 1.6/1.7/1.8 JVM默认的卡标记简化逻辑如下：

CARD_TABLE [this address >> 9] = 0;
复制代码

首先，计算对象引用所在卡页的卡表索引号。将地址右移9位，相当于用地址除以512（2的9次方）。可以这么理解，假设卡表卡页的起始地址为0，那么卡表项0、1、2对应的卡页起始地址分别为0、512、1024（卡表项索引号乘以卡页512字节）。

其次，通过卡表索引号，设置对应卡标识为dirty。

带来的2个问题

1.无条件写屏障带来的性能开销

每次对引用的更新，无论是否更新了老年代对新生代对象的引用，都会进行一次写屏障操作。显然，这会增加一些额外的开销。但是，与YGC时扫描整个老年代相比较，这个开销就低得多了。

不过，在高并发环境下，写屏障又带来了虚共享（false sharing）问题。

2.高并发下虚共享带来的性能开销

在高并发情况下，频繁的写屏障很容易发生虚共享（false sharing），从而带来性能开销。

假设CPU缓存行大小为64字节，由于一个卡表项占1个字节，这意味着，64个卡表项将共享同一个缓存行。

HotSpot每个卡页为512字节，那么一个缓存行将对应64个卡页一共64*512=32KB。

如果不同线程对对象引用的更新操作，恰好位于同一个32KB区域内，这将导致同时更新卡表的同一个缓存行，从而造成缓存行的写回、无效化或者同步操作，间接影响程序性能。

一个简单的解决方案，就是不采用无条件的写屏障，而是先检查卡表标记，只有当该卡表项未被标记过才将其标记为dirty。

这就是JDK 7中引入的解决方法，引入了一个新的JVM参数-XX:+UseCondCardMark，在执行写屏障之前，先简单的做一下判断。如果卡页已被标识过，则不再进行标识。

简单理解如下：

if (CARD_TABLE [this address >> 9] != 0)
  CARD_TABLE [this address >> 9] = 0;
复制代码

与原来的实现相比，只是简单的增加了一个判断操作。

虽然开启-XX:+UseCondCardMark之后多了一些判断开销，但是却可以避免在高并发情况下可能发生的并发写卡表问题。通过减少并发写操作，进而避免出现虚共享问题（false sharing）。

也用于CMS GC

CMS在并发标记阶段，应用线程和GC线程是并发执行的，因此可能产生新的对象或对象关系发生变化，例如：

  • 新生代的对象晋升到老年代；
  • 直接在老年代分配对象；
  • 老年代对象的引用关系发生变更；
  • 等等。

对于这些对象，需要重新标记以防止被遗漏。为了提高重新标记的效率，并发标记阶段会把这些发生变化的对象所在的Card标识为Dirty，这样后续阶段就只需要扫描这些Dirty Card的对象，从而避免扫描整个老年代。

参见：Java之CMS GC的7个阶段

参考

psy-lob-saw.blogspot.com/2014/10/the…

blogs.oracle.com/dave/false-…

bibliography.selflanguage.org/_static/wri…

www.memorymanagement.org/glossary/b.…

www.memorymanagement.org/glossary/w.…

docs.oracle.com/cd/E19205-0…

ifeve.com/falsesharin…

《深入拆解 Java 虚拟机》郑雨迪

个人公众号

更多文章，请关注公众号：二进制之路

JVM——记忆集与卡表(跨代)
专注写bug
05-07 957
文章目录前言记忆集 Remember Set卡表 Card Table卡表的维护 前言 假设年轻代进行Minor GC做垃圾回收处理。此时会采取GC Roots (可达性分析算法)，标记非垃圾对象。 如果此时新生代中的某个对象，被老年代某个对象引用着。 此时Minor GC操作前，需要判断当前新生代中的这个对象是否为垃圾对象，则需要去老年代中进行检索。导致可达性分析算法执行效率低下。 基于上述问题，在JVM中，引入了记忆集和卡表的概念。 记忆集 Remember Set JVM在年轻代中开辟了一块内存空间，
垃圾回收之CardTable和Remembered Set
互联网架构师笔记
04-02 1121
JVM 在进行垃圾收集的时候，有一项非常重要的工作就是确定这一次垃圾收集的对象到底有多少个，即确定 live set 的范围。卡表和 RSet（Remember Set），是 JVM 为了解决分代收集时，live set 扫描需要穿梭到不同的代的时候的效率问题。对于新生代垃圾收集器而言，这个问题又有其特殊之处。根据 JVM 的弱分代收集假设（weak generational hypothesis）的存在，每次垃圾收集的时候，新生代的扫描范围可能很大，但新生代的 live set 不应该太大。
【深入理解JVM】JVM-卡表（Card Table）
天天新知
11-22 3172
我们知道，JVM在进行垃圾收集时，需要先标记所有可达对象，然后再清除不可达对象，释放内存空间。那么，如何快速的找到所有可达对象呢？ 最简单粗暴的实现，就是每次进行垃圾收集时，都对整个堆中的所有对象进行扫描，找到所有存活对象。逻辑是简单，但性能比较差。 简单粗暴的实现方式，通常都是不可取的。那JVM是如何实现快速标记可达对象的？ 答案是GC Roots。 简介 现代JVM，堆空间通常被划分为新生代和老年代。由于新生代的垃圾收集通常很频繁，如果老年代对象引用了新生代的对象，那么，需要跟踪从老年代...
JVM-卡表
最新发布
左灯右行的爱情
04-23 1053
卡表本质上是一个字节数组（byte[]。它将整个堆内存划分成固定大小的连续区域，每个区域称为一个“卡页（Card Page）”或“卡（Card）”（通常是 2 的幂次方大小，如 512 字节）。卡表中的每一个字节都对应堆内存中的一个卡页。画一个堆内存条，下面对应一个卡表数组，展示其映射关系。卡表中每个字节的值代表其对应卡页的状态。最简单的实现中，有两种状态：通常用 0 表示，意味着对应的卡页“可能没有”需要关心的引用（具体含义看应用场景）。
jvm-卡表
KD的博客
08-25 2341
#背景     最近在跟同事进行jvm垃圾回收的交流，讨论到通过GC Roots进行对象的可达性分析，标记存活对象的时候，同事提出了一个疑问，因为年轻代中发生minor gc的频率很高，如果在经常会扫描年轻代中的对象进行标记，如果老年代中有对象引用了年轻代中的对象，那岂不是每次进行minor gc时也要进行全堆的扫描？嘿嘿，其实不然，jvm引入了卡表（card table）技术来解决这个问题。 #卡表（card table） jvm是如何通过卡表来避免每次进行minor gc时扫描全堆的
jvm的card table数据结构
weixin_34249367的博客
03-24 454
jvm系列 垃圾回收基础 JVM的编译策略 GC的三大基础算法 GC的三大高级算法 GC策略的评价指标 JVM信息查看 GC通用日志解读 jvm的card table数据结构 Java类初始化顺序 Java对象结构及大小计算 Java的类加载机制 Java对象分配简要流程 年老代过大有什么影响 Survivor空间溢出实例 关于Obje...
JVM进阶之卡表
Deronn的博客
09-05 1537
卡表
关于jvm中卡表和写屏障的讨论1
08-04
卡表（Card Table）是分代垃圾收集器中用来提高效率的一种技术。它是为了避免遍历整个老年代来查找可能存在的对年轻代对象的引用。卡表将内存空间分割成固定大小的块，通常每个块代表512字节。这些块被称为卡片，...
JVM高频面试基本问题与知识点整理
热门推荐
张彦峰的博客
01-16 86万+
JVM高频面试基本问题与知识点整理
JVM 面试必问的 CMS，你懂了吗？
python6_quanzhan的博客
12-07 688
前言 虽然 CMS 已经是很古老的垃圾回收器了，大家现在动不动就G1、ZGC啥的，但是据我所了解，还是有很多公司的生产环境主要使用的 CMS，包括我自己呆过的几家大厂也是。 因此在 JVM 面试中，CMS 也是问的最多的，包括我自己现在面试别人时，问到 JVM 这一块，我也喜欢从CMS开始，逐渐深入。 不多废话，今天我们就来盘他。 正文 1、什么是卡表（card table）？ 试想一下，在进行 YGC 时，如何判断是否存在老年代到新生代的引用？ 一个简单的办法是扫描整个老年代，但是这个代价太
面试官：你知道JVM的卡表吗？
悟已往之不谏，知来者之可追
04-20 485
跨代引用 跨代引用假说 卡表（Card Table） 卡表元素如何维护——写屏障
JVM调优:卡表（CardTable）简介
z69183787的专栏
03-18 8862
我们知道，JVM在进行垃圾收集时，需要先标记所有可达对象，然后再清除不可达对象，释放内存空间。那么，如何快速的找到所有可达对象呢？ 最简单粗暴的实现，就是每次进行垃圾收集时，都对整个堆中的所有对象进行扫描，找到所有存活对象。逻辑是简单，但性能比较差。 简单粗暴的实现方式，通常都是不可取的。那JVM是如何实现快速标记可达对象的？ 答案是GC Roots。 GC Roots是垃圾收集器寻找可达...
JVM G1源码分析（一）——卡表和位图
qq_16500963的博客
08-06 929
借助额外的数据结构描述这种引用关系，例如使用类似位图（bitmap）的方法，记录A和B的内存块之间的引用关系，用一个位来描述一个字，假设在32位机器上（一个字为32位），需要32KB（32KB×32=1M）的空间来描述一个分区。那么我们就可以在这个对象ObjA所在分区A里面添加一个额外的指针，这个指针指向另外一个分区B的位图，如果我们可以把对象ObjA和指针关系进行映射，那么当访问ObjA的时候，顺便访问这个额外的指针，从这个指针指向的位图就能找到被ObjA引用的分区B对应的内存块。
Java内存管理（三）——卡片表
EthanPark的博客
05-24 3332
在垃圾回收的过程中，会碰到一个问题，就是老年代中的对象可能引用年轻代中的对象。在这种情况下，每次遍历老年代的对象来查找所有存活对象的时候就会消耗相当的时间。而且，在应用中，通常来说，这种引用是非常少的（某些研究表明，这种情况的引用占总引用量的1%都不到）。但是这些引用需要遍历整个老年代对象是一个相当大的Overhead。Card-tableJVM中会维护一个卡片表的数据结构，主要用于查看老年代中指向
java 卡表_jvm-卡表，垃圾回收时的重要手段
weixin_34965737的博客
02-12 886
背景最近在跟同事进行jvm垃圾回收的交流，讨论到通过GC Roots进行对象的可达性分析，标记存活对象的时候，同事提出了一个疑问，因为年轻代中发生minor gc的频率很高，如果在经常会扫描年轻代中的对象进行标记，如果老年代中有对象引用了年轻代中的对象，那岂不是每次进行minor gc时也要进行全堆的扫描？嘿嘿，其实不然，jvm引入了卡表(card table)技术来解决这个问题。卡表(card ...
JVM中的记忆集与卡表
qq_18505089的博客
06-28 323
当老年代的对象都有指针指向新生代对象，那么再使用记忆集去记录就不可取了，因此引入了卡表，卡表就是记忆集这种思想的具体实现。（1）卡表是使用一个字节数组实现的，每个元素对应着一块特定大小的内存块，也称之为“卡页”；（2）一个卡页中可以包含多个对象，只要其中有一个对象存在跨代指针，其对应卡表的元素标识就变为1，表示该卡页变脏，否则为0，当GC时，只需要筛选出卡表中变脏的对象加入GC Roots中。
2024年Go最全浅谈JVM垃圾收集——记忆集与卡表_记忆集和卡表，理论+实战双管齐下
2401_84904308的博客
05-14 902
HotSpot虚拟机是用记忆集来记录某块内存区域是否包含跨代引用的对象。记忆集是抽象概念，而卡表是记忆集的实现。卡表是用字节数组实现的，卡表数组的每个元素都是代表某块具体内存区域，这个内存区域叫卡页。既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新如果你需要这些资料，可以戳这里获取真正体系化！
JVM-记忆集、卡表、并发标记、重标记
qq_42861526的博客
08-31 829
目前的垃圾回收器，在做垃圾回收的时候首先都要进行初始标记，也就是查找GC Root节点，但是除了GC Root和GC Root引用链上的对象需要保留之外，被老年代引用的Eden中的对象也需要保留，那么问题来了，现在我们已经知道了卡表的作用以及它的工作原理，现在出现一个新的问题，那就是卡表的更新。卡表就是一个字节类型的数组，数组中的每个元素对应着一块固定大小的内存区域叫做。，卡页的大小通常设置为2的N次幂，默认是512字节。，接下来我们来说一下记忆集的实现。的实现上，这也是我们常说的卡表，...
jvm新生老年代垃圾回收过程图
03-24
<think>好的，我现在需要回答用户关于JVM新生代和老年代垃圾回收过程图的问题。首先，我得回忆一下JVM的内存结构以及垃圾回收的相关知识。 用户想要了解的是垃圾回收的过程图，可能需要详细解释新生代和老年代的回收机制，包括步骤和相关算法。首先，我应该从JVM的内存划分开始，明确新生代和老年代的位置。新生代通常分为Eden区、Survivor区（From和To），而老年代则是存放长期存活的对象。 接下来，需要考虑垃圾回收的具体过程。新生代的GC是Minor GC，使用复制算法；老年代的GC是Major GC或Full GC，通常使用标记-清除或标记-整理算法。需要详细描述对象如何从Eden区分配到Survivor区，再晋升到老年代的过程。 可能会遇到的问题是如何用文字描述这个流程图，因为用户可能期望一个图，但这里只能用文字解释。我需要分步骤说明，每个步骤中的对象状态变化，以及涉及的垃圾回收算法。此外，要确保术语正确，比如区分Minor GC和Full GC，以及不同的收集器（如Serial、Parallel、CMS、G1等）是否有不同的处理方式，但用户可能只需要基础流程，所以保持通用性较好。 还要注意用户提到的LaTeX格式要求，所有数学公式需要用$...$，但这个问题可能涉及较少的数学公式，更多是流程和结构描述。不过如果有涉及算法的时间复杂度或其他公式，需要正确应用格式。 需要确认流程的正确性，比如对象优先在Eden区分配，当Eden满时触发Minor GC，存活对象复制到Survivor From区，年龄增加到1，下次GC时From和To交换，年龄递增，达到阈值（默认15）则晋升到老年代。老年代空间不足时会触发Major GC，可能伴随Full GC，导致STW时间较长。 在组织回答时，按照用户的要求结构清晰，分步骤解释，可能分为新生代回收过程、老年代回收过程、跨代引用处理等部分。同时，需要指出常见算法和可能的影响，如STW暂停时间。 需要检查是否有遗漏的关键点，比如大对象直接进入老年代，空间分配担保机制等，但根据用户的问题，可能不需要太深入，保持基础即可。 最后，确保用中文回答，使用正确的术语，避免拼写和语法错误，并符合用户给出的格式要求，比如行内公式的正确使用（如果有的话），但这个问题可能更多是文字描述，所以需要合理分段，使用列表或步骤式说明。</think>以下是JVM新生代与老年代垃圾回收过程的逐步解析，采用文字描述“流程图”的关键节点和逻辑： --- ### **1. JVM堆内存结构** JVM堆内存分为**新生代**和**老年代**： - **新生代** - **Eden区**：新对象优先分配在此 - **Survivor区**：分`From`和`To`两个区，用于存放Minor GC后存活的对象 - **对象年龄计数器**：记录对象经历GC的次数（默认阈值15） - **老年代**：存放长期存活的对象或大对象 --- ### **2. 新生代垃圾回收（Minor GC）** **触发条件**：Eden区内存不足时触发 **核心算法**：**复制算法**（Copying） **过程分步**： 1. **对象分配** - 新对象首先尝试在**Eden区**分配。 - 若Eden区空间不足，触发Minor GC。 2. **标记存活对象** - 暂停用户线程（**STW**，Stop-The-World）。 - 标记Eden区和当前`From`区中的存活对象。 3. **复制存活对象** - 将存活对象复制到`To`区，并**年龄+1**。 - **分代策略**： - 若对象年龄超过阈值（默认15），晋升到**老年代**。 - 若`To`区空间不足，直接晋升到老年代。 4. **清理内存** - 清空Eden区和`From`区。 - `From`和`To`区角色交换，等待下一次GC。 --- ### **3. 老年代垃圾回收（Major GC / Full GC）** **触发条件**： - 老年代空间不足 - 调用`System.gc()`（不保证立即执行） - 空间分配担保失败（Minor GC后存活对象超过老年代剩余空间） **核心算法**： - **标记-清除**（Mark-Sweep）：标记无用对象后直接清除（可能产生内存碎片）。 - **标记-整理**（Mark-Compact）：标记后整理存活对象到连续空间（减少碎片）。 **过程分步**： 1. **初始标记**（STW） - 标记与GC Roots直接关联的对象（速度极快）。 2. **并发标记** - 遍历对象图，标记所有存活对象（与用户线程并发执行）。 3. **重新标记**（STW） - 修正并发标记期间对象状态的变化（如新增的垃圾）。 4. **清理/整理** - 清除无用对象（标记-清除）或整理内存（标记-整理）。 --- ### **4. 跨代引用处理** - **问题**：老年代对象可能引用新生代对象，需避免错误回收。 - **解决方案**： - **卡表（Card Table）**：记录老年代中引用了新生代的内存块（Card），Minor GC时只需扫描卡表关联区域。 --- ### **关键流程图总结** ``` 新对象分配 → Eden区 │ └─Eden满 → Minor GC │ ├─标记存活对象（Eden + From区） │ ├─复制到To区（年龄+1） → 年龄超阈值 → 晋升老年代 │ └─清空Eden + From区 老年代空间不足 → Major GC/Full GC │ ├─初始标记（STW） │ ├─并发标记 │ ├─重新标记（STW） │ └─清理/整理 ``` --- ### **注意事项** 1. **STW影响**：Full GC会导致长时间停顿，需优化参数（如堆大小、晋升阈值）。 2. **垃圾收集器差异**：不同收集器（如Parallel Scavenge、CMS、G1）具体流程可能不同。 如需进一步细节（如具体收集器实现），可提供补充说明！
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值