hotspot jvm弃用mark word的11标志位做gc标记，因缓存污染、并发同步开销大及与锁机制冲突；现代gc统一采用独立位图映射堆内存，通过写屏障+三色标记解决并发漏标问题。

标记清除阶段不会直接通过对象头的 Mark Word 来做 GC 标记，所以不存在“Mark Word 标记位的物理读写并发冲突”这个问题。

为什么不用 Mark Word 做 GC 标记？

HotSpot JVM 早在多年以前就弃用了在对象头中复用 Mark Word 的两个比特位（即标志位为 11）来表示 GC 标记状态的做法。原因很明确：

• 缓存污染严重：频繁修改每个对象的对象头，会破坏 CPU 缓存行局部性，大幅降低标记吞吐；
• 并发安全成本高：多个 GC 线程同时修改不同对象的 Mark Word，需大量 CAS 或锁同步，反而拖慢标记速度；
• 与锁机制冲突：Mark Word 已被用于存储锁状态（偏向锁 ID、轻量级锁指针等），GC 标记和锁升级/降级可能同时竞争同一字段。

现代 JVM 实际怎么标记？

主流 GC（如 G1、ZGC、Shenandoah、Parallel GC）统一采用独立位图（Bitmap）+ 堆内存分块映射的方式：

论文常用的tex格式转换为word格式，核心是能转换数学公式（非图片），表格，图表等等

将 LaTeX（.tex）学术论文转换为 Word（.docx），支持可编辑的 OMML 公式、原生 Word 表格、嵌入图形、IEEE 双栏排版及参考文献

下载

• 为整个堆维护一块只读/可写位图（BitSet），每个 bit 对应一个对象或一个固定大小内存单元（如 64 字节对齐块）；
• 标记时，GC 线程只操作位图——设置对应 bit 为 1，完全不碰对象头；
• 位图本身按页划分，支持多线程并行写入（如 G1 使用 per-region bitmap，ZGC 使用 multi-page bitmap），天然规避对象头粒度的并发写冲突。

那 Mark Word 里 “11” 标志位还存在吗？

存在，但仅作为历史兼容保留字段，实际 GC 过程中不依赖它：

• 某些低配 GC（如 Serial、CMS 的早期版本）曾短暂使用过该标志位，但已淘汰；
• 当前 HotSpot 源码中，该字段仍保留在 Mark Word 定义里，但标记逻辑完全绕开它；
• 若你用 JOL（Java Object Layout）工具查看对象头，看到 GC 标记位为 11，大概率是调试模式下人工模拟，或极老版本 JVM 的残留行为。

真正要防的并发问题是什么？

不是 Mark Word 写冲突，而是用户线程在并发标记过程中修改引用关系导致的漏标（Floating Garbage 或 Incorrect Collection）。解决方案是：

• 三色标记 + SATB（G1）或 Brooks Pointer（ZGC）：在引用被修改前捕获快照；
• 写屏障（Write Barrier）：在赋值语句（如 obj.field = newObj）前后插入检查逻辑，把被覆盖的旧引用加入灰色集合；
• 初始标记和重新标记阶段 STW：确保根集合和脏卡页被完整扫描，兜底修正并发偏差。