标记-整理算法的核心瓶颈在于整理环节，而非标记阶段；其三重开销包括对象迁移成本、指针修正开销和缓存局部性破坏，尤其在大堆、高存活率、对象大小不一场景下显著拖慢GC吞吐量。
标记-整理算法的核心瓶颈不在标记阶段，而在于整理环节的开销与副作用。它虽能消除内存碎片、支持高速顺序分配，但对象移动、指针更新、缓存局部性破坏等操作会显著拖慢GC吞吐量，尤其在堆大、存活率高、对象大小不一的场景中更为突出。
整理阶段的三重开销
整理过程不是简单“搬数据”，而是牵一发而动全身：
- 对象迁移成本：每个存活对象需复制到新位置，小对象频繁搬运带来大量内存带宽压力；大对象迁移则可能阻塞赋值器线程较长时间
- 指针修正开销：所有指向被移动对象的引用（栈、寄存器、其他对象字段）都必须更新，这需要额外遍历或依赖转发指针机制，增加GC停顿时间
- 局部性破坏风险：若采用任意顺序整理（如双指针算法），原本相邻的对象可能被散落到不同缓存行甚至不同内存页，导致后续应用访问时缓存命中率骤降
关键优化方向与对应策略
优化不是追求单点极致，而是权衡吞吐量、延迟、内存占用与局部性：
- 优先滑动整理而非任意顺序：Lisp2、单次遍历等滑动类算法保持对象原有相对顺序，天然兼容CPU缓存行布局，对赋值器友好；现代JVM（如ZGC、Shenandoah）均默认采用滑动或类似思想
- 减少堆遍历次数：双指针需2次遍历，引线整理需2次且成本高；单次遍历算法通过实时计算转发地址，省去额外存储槽（如Lisp2需对象头预留1个字段），降低空间开销和遍历负担
- 适配对象大小分布：固定大小区域可用双指针高效处理；混合大小堆建议分代+分区，对大对象区启用滑动整理，对小对象区结合压缩与空闲链表管理，避免“一刀切”
工程落地中的典型陷阱
理论优化易被现实细节反噬：
- 对象头膨胀：Lisp2依赖对象头额外字段存转发地址，若运行时无法修改对象结构（如某些嵌入式或受限Java环境），该方案直接不可用
- 并发整理的复杂性：为降低STW时间而引入并发整理（如ZGC的染色指针），需额外硬件支持（如x86的地址空间隔离）或软件模拟开销，调试难度陡增
- 长寿对象干扰：长期存活对象反复被整理却极少被回收，浪费整理带宽；应结合分代假设，在老年代启用更保守的整理策略（如仅在碎片率超阈值时触发）
真正有效的优化，始于对整理行为如何影响应用实际访存模式的理解，而非仅关注GC日志里的毫秒数变化。
