在现代编程语言生态中，垃圾回收器的实现方式直接影响开发者的编程模型与性能表现。传统观点认为，实现一个可靠的 GC 必然需要借助 unsafe 代码或底层运行时特权，然而近年来 Rust 社区的 Safe-GC 实验、Go 语言的运行时 GC 封装以及 Zig 的无 GC 设计，为我们展示了三条截然不同的技术路线。本文将从跨语言视角对比这三种方案的实现策略、工程权衡与适用场景。
Rust Safe-GC：追踪式 GC 的安全抽象
Rust 的 Safe-GC 库代表了一种激进的技术路线：在完全不使用 unsafe 代码的前提下，实现一个完整的标记 - 清除（mark-and-sweep）垃圾回收器。其核心设计围绕三个抽象展开：Heap、Collector 与 Gc 句柄。
Safe-GC 的工作原理可以概括为以下几个步骤。首先，所有需要 GC 管理的对象必须实现 Trace trait，该 trait 要求类型声明其持有的所有 GC 引用边。其次，分配对象时使用 Heap::alloc 方法返回 Gc 句柄，而非直接返回裸指针。第三，GC 触发时，Collector 从根集合出发，沿 GC 边递归标记可达对象，最后清除未被标记的对象并回收内存。
这种设计的侵入性体现在：开发者必须显式声明类型之间的引用关系，通过 Trace trait 将对象图结构暴露给回收器。虽然代码本身是安全的，但类型系统无法在编译期验证 Trace 实现的完整性，遗漏任何 GC 边都可能导致悬挂指针。性能方面，Safe-GC 采用保守式收集，每次 GC 需要遍历整个对象图，对于高频分配场景会产生显著暂停。
值得注意的是，Safe-GC 并不是 Rust 的标准方案。Rust 的所有权系统与借用检查器本身就能处理大多数内存安全问题，Rc 和 Arc 提供的引用计数机制足以覆盖共享所有权场景。Safe-GC 主要适用于需要嵌入脚本引擎或实现动态对象图的特殊需求。
Go 语言：运行时 GC 的透明封装
Go 语言采取了与 Rust 截然相反的策略：内置一个生产级别的追踪式 GC，但对开发者完全透明。Go 的 GC 是运行时的一部分，使用三色标记 - 清除算法，支持并发标记与增量清除，旨在将停顿时间控制在毫秒级。
从「无 unsafe 代码」的角度审视，Go 开发者无法在纯 Safe Go 中实现自定义 GC。原因在于 Go 的垃圾回收器依赖运行时对对象布局的精确了解，以及在并发标记过程中安全地更新指针的能力。这些能力只能通过 unsafe 包或运行时内部 API 获取，而官方明确警告这些接口可能随版本变化且不受兼容性保证。
然而，这并不意味着 Go 开发者无法影响 GC 行为。Go 提供了丰富的运行时调优参数，包括 GOGC（控制 GC 触发阈值）、GOMEMLIMIT（内存上限）以及 GODEBUG 环境变量。开发者可以通过减少堆分配、使用 sync.Pool 复用对象、预分配切片容量等编程模式来降低 GC 压力。这些优化完全在安全 Go 代码范围内完成，本质上是通过改变内存使用模式来适应内置 GC 的特性。
Go 的方案侵入性最低，但代价是开发者失去对回收器本身的控制权。当需要确定性停顿或极低延迟时（如硬实时游戏服务器），Go 的自适应 GC 可能无法满足需求，此时通常需要转向手动内存管理或接受一定的内存浪费。
Zig：无 GC 的显式内存管理哲学
Zig 语言选择了一条完全不同的道路：语言本身不提供任何垃圾回收器，内存管理完全由开发者控制。这种设计决策源于 Zig 的核心哲学：为零开销抽象而努力，让开发者能够精确控制程序行为。
虽然没有内置 GC，Zig 提供了丰富的 allocator 原语来支持各种内存管理模式。常见的模式包括：arena allocator（将分配限制在特定生命周期内，通过一次性释放整个区域来简化管理）、pool allocator（预分配对象块，按需分配与回收，减少碎片化）以及 TLSF（两层分离空闲列表，适合实时系统）。这些 allocator 可以组合使用，实现接近 GC 的使用体验。
社区也提供了实验性的 GC 实现，例如 zig-gc 库，实现了基础的标记 - 清除算法。由于 Zig 允许直接操作内存且没有 Rust 的所有权检查约束，实现 GC 相对更自由，但这也意味着开发者需要自行确保内存安全。
Zig 的方案在侵入性上介于 Rust Safe-GC 与 Go 之间：语言层面不强制任何 GC 行为，开发者可以根据需求选择是否引入 GC -like 机制。对于追求极致性能或需要精确控制内存布局的场景（如操作系统内核、嵌入式系统、游戏引擎），Zig 的显式管理是理想选择；而对于快速原型开发或常规应用开发，则需要开发者自行承担内存管理责任。
权衡对比与选型建议
综合以上三种方案，我们可以从以下几个维度进行对比。
侵入性方面，Rust Safe-GC 要求显式实现 Trace trait，侵入性中等；Go 完全无侵入，开发者无需关心 GC 实现；Zig 提供了最大的灵活性，但需要开发者自行设计内存管理策略。
控制权方面，Rust Safe-GC 允许开发者完全控制回收器逻辑，但实现复杂度高；Go 提供了有限的调优参数，无法自定义回收算法；Zig 赋予开发者完全控制权，但需要自行实现所需机制。
安全性方面，Rust Safe-GC 在 safe Rust 范围内实现，安全保证最强；Go 的 GC 是语言运行时的一部分，由 Go 团队维护安全性；Zig 依赖开发者的正确实现，内存安全由人工保证。
性能方面，Rust Safe-GC 作为保守式收集器，停顿时间较长，适合低频 GC 场景；Go 的并发 GC 在大多数场景下提供毫秒级停顿；Zig 的手动管理可实现最低延迟与最高吞吐量，但开发成本最高。
对于需要动态对象图且希望保持 Rust 安全保证的嵌入式脚本引擎，Rust Safe-GC 是值得探索的方向。对于常规应用开发且希望降低心智负担，Go 的内置 GC 配合适当的调优实践已足够。对于系统编程、游戏引擎或实时系统，Zig 的显式内存管理提供了最大的控制自由度。
理解这些技术路线的差异，有助于在实际项目中做出更合适的语言与架构决策。每种方案都在安全性、控制权与开发效率之间取得了不同的平衡，没有绝对的最优解，只有适合特定场景的选择。
参考资料
- Safe-GC: A garbage collection library for Rust with zero unsafe code, https://github.com/fitzgen/safe-gc
- A Guide to the Go Garbage Collector, https://go.dev/doc/gc-guide
- Zig GC: A simple mark-and-sweep garbage collector written in Zig, https://github.com/Hejsil/zig-gc