编译器不控制标记清除的扫描步长，该步长由GC运行时根据堆分块大小、并发策略及缓存行对齐等内部参数自主决定；内联仅影响代码结构与对象生命周期，不修改GC遍历逻辑或内存组织方式。
编译器不会对标记清除（mark-sweep）扫描步长做任何改动——因为标记清除是垃圾回收器（GC）的行为，不是编译器的职责。编译器和 GC 属于不同层次的运行时组件：前者在程序构建阶段工作，后者在程序运行时管理堆内存。
编译器的极致内联优化不触及 GC 算法
内联（inlining）是将函数调用替换为函数体的过程，目的是减少调用开销、暴露更多优化机会（如常量传播、死代码消除）。即使对对象构造、字段访问或生命周期相关的代码做激进内联，它也只影响生成的机器码结构和栈帧布局，不会修改：
- 堆内存的组织方式（如对象头格式、指针对齐）
- GC 的遍历逻辑（如从根集出发的标记顺序、对象图遍历策略）
- 扫描步长（即 GC 线程在堆中移动时每次跳过的字节数或对象数）
扫描步长由 GC 实现决定，与编译结果无关
扫描步长通常是 GC 内部实现细节，取决于：
- 堆内存分块（chunk/page）大小（如 4KB、64KB）
- 是否启用并发/增量标记（影响步长粒度以控制停顿）
- 硬件缓存行对齐要求（例如按 64 字节边界对齐以提升遍历效率）
- 对象分配模式（如 TLAB 分配可能让同线程对象局部聚集，但 GC 仍按统一策略扫描）
这些参数在 GC 初始化时设定，运行中由 GC 线程自主控制，编译器生成的代码无法插入指令去“调整步长”。
可能引起混淆的边界情况
某些高级语言运行时（如 V8、GraalVM）将编译器与 GC 深度协同，但协同方式是间接的：
- 编译器可插入写屏障（write barrier）调用，通知 GC 对象引用变更——这影响标记精度，不改变扫描步长
- 通过逃逸分析消除堆分配，减少待扫描对象数量——降低 GC 工作量，而非修改扫描节奏
- 生成带元信息的代码（如栈映射表），帮助 GC 准确识别根对象——提升标记起点可靠性，与步长无关
所以，若看到某文档提到“内联影响扫描步长”，大概率是表述偏差，实际想说的是：内联改变了对象生命周期或引用模式，从而间接影响 GC 的标记范围或频率，而非直接操控 GC 的扫描步长机制。
