终结器在早期 Go 版本中引入，以提供释放外部资源的安全网，特别是在通过 cgo 连接到 C 库时。模仿 Java 中类似的机制，runtime.SetFinalizer 将一个函数附加到对象上，该函数在垃圾回收器确定没有引用存在时执行。然而，Go 团队一直不鼓励使用它们，因为执行时机不确定，并与垃圾收集器的阶段复杂相互作用。
终结器在专用的 goroutine 中异步运行，仅在 GC 将对象标记为不可达后，创建了一个资源不必要地保留分配的窗口。当终结器通过将引用存储在全局变量或存活对象中复活其对象时，关键问题出现了。这会导致无限终结循环和资源耗尽，因此运行时必须跟踪终结器是否已经运行，并强制施加强制的“冷却”周期，以防任何后续的终结执行发生。
Go 保证在第一次** GC **周期后执行终结器，前提是程序未提前退出，且对象被发现不可达。当复活发生时，运行时从内部清扫缓冲区中删除终结器关联，需要显式的新调用 runtime.SetFinalizer 进行重新注册。这种设计确保复活的对象必须在下一个终结器可以被调度之前，至少存活一个额外的完整 GC 周期，以证明它们真的再次不可达。
type Resource struct { ptr unsafe.Pointer // C memory } func NewResource() *Resource { r := &Resource{ptr: C.malloc(1024)} // 当 r 变得不可达时，终结器运行 runtime.SetFinalizer(r, (*Resource).Finalize) return r } func (r *Resource) Finalize() { C.free(r.ptr) // 如果我们这样做：global = r，我们复活 r // 终结器现在被分离; r 需要另一个 GC 周期 // 和一次新的 SetFinalizer 调用才能再次被终结。 }
在构建实时分析管道时，我们的团队集成了一个第三方 C 库，以利用 cgo 进行硬件加速加密，使用 C 堆内存分配敏感的密钥缓冲区。我们依赖 Go 包装结构上的 runtime.SetFinalizer 来自动调用 C free() 函数，当包装被垃圾收集时。在持续的负载测试中，我们发现偶尔会发生段错误，其中 Go 代码尝试访问已经释放的 C 内存，尽管相应的 Go 对象在请求处理程序中仍然是活动的。
根本原因分析揭示我们的日志框架在终结器中被调用，捕获了 Go 包装的指针以供错误上下文使用，无意中将其复活到一个全局环形缓冲区中。由于 Go 的终结器与应用程序并发运行，该对象在其 C 内存被释放之后、请求处理程序完成使用之前被复活。这种竞争条件导致了使用已释放后访问的场景，其中复活的对象持有悬空的 C 指针，导致在高并发下服务不可预测地崩溃。
我们考虑实施一个显式的 Close() 方法，采用 io.Closer 语义，保留终结器作为泄漏检测的安全网。这种方法提供确定性的资源管理并遵循 Go 最佳实践，确保 C 内存在请求完成时立即释放。然而，这会引入在 Close() 和终结器并发运行时的双重释放风险，并且如果开发人员忘记调用 Close() 并且终结器复活对象，仍然无法防止崩溃。
另一种选择是用 uintptr 地址替换终结器，使用 sync.Map 来跟踪未完成的分配，而不阻止垃圾收集。这种方法允许显式控制对象生命周期监控，完全避免复活副作用。然而，它需要复杂的手动同步，定期扫描映射以查找过期条目，并且如果注册表自身没有仔细维护，则存在内存泄漏的风险，增加了显著的操作开销。
我们还评估了修改终结器，在释放 C 内存之前检查对象指针是否存在于任何全局缓存中，以检测复活。如果检测到则恐慌。尽管这会在测试期间立即显示错误，但并没有解决根本的资源管理问题，并会导致生产中的故障，而不是优雅降级。此外，它依赖昂贵的全局锁来检查对象状态，严重影响我们的高性能管道所需的吞吐量。
我们最终在生产代码中完全消除了终结器，强制在所有代码路径中通过 defer 语句进行显式 Close() 调用。为了防止在最后使用与 Close() 调用之间的提前 GC，我们在使用 C 内存的关键部分后添加了 runtime.KeepAlive(obj) 调用。这种策略消除了不确定行为，消除了复活风险，并与 Go 的显式资源管理理念相一致，尽管它需要重构代码库的大量部分，以确保 Close() 始终可达。
在迁移之后，段错误完全消失，GPU 内存使用变得可预测且与请求量线性相关。增加了静态分析 linter，以强制对这些对象进行 Close() 调用，及时捕获编译时的资源泄漏。该系统现在支持每秒 10万多个请求，没有与内存相关的崩溃，证明显式生命周期管理优于基于终结器的方法，在关键的 Go 服务中表现更佳。
为什么一个已经终结的对象在其终结器仍在执行时会被 GC 回收，且 runtime.KeepAlive 如何防止这种情况？
候选人常常假设终结器的存在会在终结器完成之前保持目标对象存活。实际上，一旦 GC 确定一个对象不可达，它就会立即变为可回收状态，终结器将在一个单独的 goroutine 中安排运行；如果没有其他引用存在，该对象可能会在终结器完成之前被回收。为了防止这种情况，应在对象的最后使用之后调用 runtime.KeepAlive(obj)，创建一个编译器层面的先发生边缘，延长对象的生命周期，确保 C 资源或其他依赖项在终结器执行期间保持有效。
一个 Go 对象是否可以通过对 runtime.SetFinalizer 的顺序调用注册多个终结器，如果终结器函数本身是捕获对象的闭包，会发生什么？
许多候选人错误地认为，一个对象可以形成终结器链或队列。Go 在再次调用 SetFinalizer 时显式覆盖任何现有的终结器，只保留最新的函数指针在内部运行时哈希表中。如果终结器是一个捕获对象的闭包，它创建一个循环引用，使该对象永久可达，防止终结器运行，并导致内存泄漏，因为 GC 在闭包的变量中看到了被捕获的引用。
如果一个图中的对象 A 引用对象 B 且两者都有注册的终结器，GC 如何处理终结器的执行顺序？
候选人常常期望确定性顺序，例如子对象在父对象之前或 LIFO 堆栈行为。Go 不提供顺序保证，因为 GC 同时将所有不可达对象的终结器排入一个全局队列，该队列由多个后台 goroutine 并行处理。如果 A 的终结器访问 B，而 B 的终结器已经运行并可能已释放资源， A 的终结器将遇到损坏状态或使用后释放错误，因此需要终结器绝不访问其他也有终结器的对象，或者所有清理逻辑都集中在根对象的单个终结器中。