在计算机科学领域，内存重排序（memory reordering）与垃圾回收（GC）向来被视为两个独立的问题。然而，一篇发表于2019年的技术文章提出了一个令人耳目一新的观点：抢占（Preemption）本质上就是内存重排序的“垃圾回收”。这一类比迅速引发了开发者社区的热议，它揭示了操作系统调度机制在多核编程中扮演的隐性角色，也为长期困扰并发程序员的乱序执行问题提供了一种全新的思考框架。
内存重排序：隐形的“内存泄漏”
在传统视角下，内存重排序是CPU和编译器为了提升性能而采取的黑盒优化——指令执行顺序可能被改写，写操作的可见性可能被延迟。对多线程程序而言，这就像内存中“飘散”着无法预测的幽灵数据：一个线程对共享变量的写入，在另一个线程看来可能顺序颠倒、甚至暂时不可见。开发者被迫使用内存屏障（memory barrier）或原子操作来手动“打扫”这些乱序垃圾，类似于手动调用 free() 管理内存。
然而，手动管理内存屏障的难度不亚于手动管理内存。稍有不慎，就会引入诡异的并发bug，且难复现、难调试。2019年那篇文章的核心洞察是：抢占式调度恰好在这一层面扮演了自动回收的角色。
抢占：隐含的“内存屏障”
抢占，即操作系统在任意时刻中断一个线程的执行，切换到另一个线程。这一过程看似简单，却隐藏着关键保证：在上下文切换发生时，当前线程的所有写操作必须对后续执行的其他线程可见。因为操作系统需要保存和恢复寄存器、页表等状态，CPU必须确保写缓冲（store buffer）被刷入缓存一致性协议中，从而在物理上强制了内存操作的顺序化。
换言之，每次抢占都相当于一次全量的、隐式的内存屏障——它“回收”了所有尚未提交的内存重排序操作。正如垃圾回收器自动释放不再使用的对象，抢占自动清理了乱序执行遗留的“可见性垃圾”。开发者无需手工插入屏障，调度器以一定的时间粒度（通常为几毫秒到十几毫秒）自动完成这项工作。
类比的价值与边界
将抢占比作GC并非完美，但极具启发性。在GC的世界里，程序员可以不关心内存释放的时机，只需信任回收器最终会处理。类似地，如果程序在足够短的时间片内运行，抢占的存在可以掩盖大部分重排序问题——前提是线程间的交互频率低于调度频率。这正是许多“意外正确”的并发程序的内在原因。
但这一类比也有明显的局限。首先，GC保证最终回收所有不可达对象，而抢占并不保证所有重排序都被“清理”——在两次抢占之间、同一线程内部的读写依然可能乱序。其次，在多核非对称调度环境下，不同核心上的线程可能同时被抢占，显式的内存屏障仍是保证跨核心一致性的唯一可靠手段。更重要的是，抢占作为GC是有“延迟”的——如果两个线程的交互发生在同一时间片内，乱序问题依然存在。
对并发编程的启示
这一观点并非否定显式内存屏障的价值，而是提醒开发者认识到：操作系统的调度机制本身已经提供了某种程度的顺序保证。在低竞争、高频率调度的场景下，通过锁、条件变量等同步原语（它们内部隐含了调度点），程序往往能正确运行而不需要额外的屏障。这解释了为什么许多“正确但未加屏障”的代码在实际中并未崩溃。
当然，依赖这种隐式保证是危险的——它既不可移植，也无法在高性能场景下提供确定性。但理解抢占对重排序的“回收”作用，可以帮助开发者更理性地设计同步策略：在需要严格顺序的点上明确使用原子操作，在可容忍短暂不一致的路径上放松约束，让调度器自动完成“垃圾回收”。
正如内存管理从手动走向自动，内存重排序的管理也正在经历同样的演化。只是这一次，GC已经默默运行在操作系统的调度器里，只是我们从未意识到它的存在。