java等语言的追踪式垃圾回收器（如g1）在标记阶段不依赖运行时维护的对象图，而是直接扫描堆中对象的内存布局；其核心依据是对象头中指向类元数据的指针，结合类定义中精确的字段偏移与类型信息，定位每个引用字段的内存位置。
在G1等基于标记-清除（mark-and-sweep）策略的垃圾收集器中，“堆内存扫描”（heap memory scan）并非盲目遍历字节，而是一种语义感知的结构化解析过程。当GC从根集（如栈帧、静态变量、JNI引用等）出发，访问到一个对象（例如对象A）时，它首先读取该对象的对象头（Object Header） —— 这是每个Java对象在堆中固定布局的起始部分。
对象头中包含一个关键字段：Klass Pointer（类指针），它指向JVM内部的Klass元数据结构（在HotSpot中为InstanceKlass*）。该结构由类加载器在类初始化时构建并持久化，完整记录了该类的以下关键信息：
- 所有实例字段的数量、名称、声明顺序；
- 每个字段的类型（int、long、Object、数组等）；
- 每个字段在对象内存布局中的精确偏移量（offset）（以字节为单位），该偏移由JVM在类加载后根据字段类型和虚拟机对齐规则（如8字节对齐）静态计算得出；
- 字段是否为引用类型（is_oop_field()）——这是GC判断“此处是否需递归标记”的唯一依据。
因此，当G1扫描对象A时，实际执行流程如下（伪代码示意）：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
void G1MarkSweep::scan_object(oop obj) {
Klass* k = obj->klass(); // 从对象头获取Klass指针
InstanceKlass* ik = InstanceKlass::cast(k);
// 遍历所有实例字段（非静态字段）
for (int i = 0; i < ik->nof_instance_fields(); i++) {
FieldInfo* f = ik->field(i); // 获取第i个字段描述符
if (f->is_reference()) { // 判定是否为引用类型（如Object、数组等）
int offset = f->offset(); // 获取该字段在对象内的字节偏移
oop* ref_addr = (oop*)((char*)obj + offset); // 计算引用字段地址
oop target = *ref_addr; // 读取引用值（可能为null或指向另一对象）
if (target != nullptr && !is_marked(target)) {
mark_and_push(target); // 标记并推入待扫描队列
}
}
}
}值得注意的是：
✅ 无需运行时反射或符号表查询：所有字段信息在类加载完成时已固化为紧凑的C++结构体（FieldInfo数组），扫描过程纯属指针运算与内存读取，极高效；
✅ 与对象布局强绑定：HotSpot采用“普通对象布局（Ordinary Object Layout）”，对象头后紧跟实例字段（按宽度排序+填充对齐），确保偏移可预测；
✅ 区分引用/非引用字段是静态编译期知识：is_reference()的判定基于字段签名（如Ljava/lang/Object;或[I），而非运行时类型检查；
⚠️ 不扫描填充字节（padding）或元数据区域：GC仅依据Klass提供的有效字段列表操作，绝不会误将int字段当作对象引用处理——这从根本上避免了误标（false positive）和漏标（false negative）。
此外，虽然 remembered sets 和 card tables 等机制用于跨区域引用的快速定位（优化并发标记与混合回收），但它们并不参与单个对象内部的字段解析逻辑。堆内存扫描本身是完全同步、单线程（初始标记）、且严格依赖类元数据驱动的确定性过程——这也是现代JVM GC高可靠性和低暂停的关键底层保障。
简言之：对象头是入口，Klass是地图，字段偏移是坐标，引用标记是结果。一切始于类定义，止于内存地址的精准计算。
