标记-清除算法因不移动存活对象导致内存碎片化，引发地址查找开销上升、缓存局部性下降、根扫描边界不准及标记位存储影响地址对齐等问题。

标记-清除算法本身不直接参与内存地址计算，但它会显著影响堆中对象的物理布局和空闲块的分布，从而间接引发地址管理上的实际问题。这些问题不是算法设计初衷，而是运行时内存状态变化带来的连锁反应。

空闲内存块不连续，导致地址查找开销上升

清除阶段只是释放未标记对象所占空间，并不移动存活对象。结果是堆内存中出现大量大小不一、位置随机的空闲区域（即内存碎片）。当新对象需要分配时，分配器必须遍历空闲链表，逐一比对块大小与请求尺寸，再计算该块起始地址是否可用——这个过程涉及多次指针跳转和地址比较，时间复杂度从O(1)退化为O(n)。

• 例如：请求分配 64 字节对象，但空闲链表中前 5 个块分别是 16B、32B、8B、128B、4B；分配器需逐个检查，直到第 4 个才匹配，此时还需确认该 128B 块起始地址是否对齐、是否在合法堆范围内
• 某些实现用位图或伙伴系统优化，但本质仍是为缓解地址定位低效而增加额外元数据开销

对象地址无法预测，影响缓存局部性与引用解析

由于存活对象原地不动，其地址在整个 GC 周期前后保持不变，看似稳定。但问题在于：清除后堆中“空洞”穿插其中，使得相邻逻辑对象在物理内存上可能相距甚远。CPU 缓存预取失效率升高，访问链表或树结构时频繁发生 cache miss。

• 比如一个数组对象和它引用的元素对象，在标记-清除后可能被多个已释放的小对象隔开，导致跨页访问
• 对于需要按地址做快速类型判断或偏移计算的运行时（如某些 JIT 编译器），碎片化堆会削弱地址到元信息映射的效率

根扫描依赖栈/寄存器地址，但栈底（BOS）获取存在平台差异

标记阶段需准确识别根对象，其中栈上变量依赖栈边界。gc 库常用 __builtin_frame_address(0) 获取当前帧地址作为近似栈顶，再结合预设或探测得到的栈底（BOS）。但不同架构（x86 vs ARM）、不同编译器优化等级下，该地址可能指向函数调用帧内部而非真正栈底，造成扫描范围偏差——漏标或误标都会直接影响后续地址有效性判断。

• 若 BOS 估算偏高，扫描会遗漏深层栈帧中的有效指针
• 若 BOS 估算偏低，可能把已回收栈帧的残余值当作活跃指针，导致不该存活的对象被错误保留
• 这种地址不确定性不是算法缺陷，而是底层内存模型与抽象之间的张力体现

标记位存储位置影响对象首地址对齐与偏移计算

为标记对象存活状态，常见做法是在对象头（object header）预留标志位。但这会改变对象内存布局：原本 8 字节对齐的对象，因头部扩展可能被迫 16 字节对齐；或者采用外部位图，此时需将对象地址映射到位图索引——这一步涉及除法或位运算，且要求对象起始地址能被固定粒度（如 8B 或 16B）整除。

• 若对象分配未严格对齐，位图索引计算可能越界或错位，导致标记/清除逻辑异常
• 某些嵌入式 GC 实现将标记位复用对象头中已有字段（如哈希码低位），但需确保业务代码不破坏该位，否则地址关联的存活状态就不可信