标记-整理算法加剧多核缓存一致性开销，因跨核非局部写触发mesi高频切换与总线拥塞；指针重定向破坏空间局部性，导致l1/l2预取失效、带宽利用率低于15%；伪共享与无效化放大核间争用，l3 invalid请求占比达37%；缺乏硬件协同优化指令，整理周期引发数百纳秒不可预测停顿。
标记-整理算法在频繁改写内存时，会直接加剧多核系统中的缓存一致性开销，引发显著的核间缓存缺失惩罚。这不是单纯的L1或L2未命中问题，而是由大量跨核、跨缓存行、非局部性的写操作，触发MESI协议高频状态切换与总线流量激增所导致的系统级延迟。
指针重定向打破空间局部性，强制跨核同步
整理阶段需遍历存活对象并批量更新其内部指针，这些指针散落在堆内存各处，目标地址又随滑动策略动态变化。结果是：同一核心执行的写操作，往往命中不同物理页、不同NUMA节点甚至不同缓存行——L2缓存无法有效预取，更无法合并访问。当多个核心并行参与（如并发标记或辅助重定向），它们各自写入的地址彼此无序，极易造成同一缓存行在不同核心的私有缓存中反复处于Shared或Invalid状态，每次写都需广播Invalidate消息，消耗大量互连带宽。
写操作不可预测，使缓存替换与预取机制双双失效
不同于程序正常执行中可被硬件预取器识别的顺序访存模式，指针重定向是一次性的“写风暴”：它不按函数调用栈展开，也不遵循数据依赖链，而是由GC扫描顺序驱动。这种随机地址写入导致：
- L1/L2缓存行被频繁驱逐，且多数仅写入1–2个字段（如8字节指针），却要整行换入换出，带宽利用率低于15%
- 现代CPU的硬件预取器（如Intel’s DCU prefetcher）对非顺序写完全不响应，L2无法提前加载后续目标行
- 若启用转发指针（如Lisp 2算法），还需额外读取对象头，引入二次L2未命中，进一步拉长写延迟
伪共享与无效化放大核间争用
即使对象本身被对齐到缓存行边界，其引用字段仍常与相邻元数据（如GC标志位、哈希码、锁状态）共存于同一行。重定向写入一个指针，可能意外污染同缓存行内其他核心正在读写的变量，触发不必要的Invalidation。实测显示，在4核服务器上运行G1式整理器时，L3缓存的Invalid请求占比可达总缓存事务的37%，远超应用负载常态（通常＜8%）。
缺乏硬件协同，软件层难以掩盖惩罚
当前x86/ARM架构未提供面向GC写模式的缓存提示指令。普通store一律走标准write-allocate流程，无法跳过L1、绕过L2或标记为“单次低重用”。编译器也无法静态推断重定向地址，故无法插入prefetchw、clwb或clflushopt等优化。这意味着所有写延迟都暴露给应用线程——尤其在低延迟场景（如高频交易或实时推理）中，一次整理周期可能引入数百纳秒的不可预测停顿。
