Finalizers were introduced in early Go releases to offer a safety net for releasing external resources, particularly when bridging to C libraries via cgo. Modeled after similar mechanisms in Java, runtime.SetFinalizer attaches a function to an object that executes once the garbage collector determines no references exist. However, the Go team has consistently discouraged their use due to non-deterministic execution timing and complex interaction with the garbage collector's phases.
A finalizer runs asynchronously in a dedicated goroutine only after the GC marks an object as unreachable, creating a window where resources remain allocated longer than necessary. The critical issue arises when a finalizer resurrects its object by storing a reference in a global variable or a living object, making it reachable again. To prevent infinite finalization loops and resource exhaustion, the runtime must track that the finalizer has already run and enforce a mandatory "cooldown" period before any subsequent finalization can occur.
Go guarantees a finalizer executes exactly once after the first GC cycle where the object is found unreachable, provided the program does not exit prematurely. When resurrection occurs, the runtime removes the finalizer association from the internal sweep buffer, requiring an explicit new call to runtime.SetFinalizer to re-register. This design ensures that resurrected objects must survive at least one additional complete GC cycle to prove they are genuinely unreachable again before the next finalizer can be scheduled.
type Resource struct { ptr unsafe.Pointer // C memory } func NewResource() *Resource { r := &Resource{ptr: C.malloc(1024)} // Finalizer runs when r becomes unreachable runtime.SetFinalizer(r, (*Resource).Finalize) return r } func (r *Resource) Finalize() { C.free(r.ptr) // If we did: global = r, we resurrect r // The finalizer is now detached; r needs another GC cycle // and a new SetFinalizer call to be finalized again. }
While building a real-time analytics pipeline, our team integrated a third-party C library for hardware-accelerated encryption using cgo, allocating sensitive key buffers in C heap memory. We relied on runtime.SetFinalizer on Go wrapper structs to automatically call the C free() function when wrappers were garbage collected. During sustained load testing, we observed intermittent segmentation faults where Go code attempted to access C memory that had already been released, despite the corresponding Go objects still being active in request handlers.
Root cause analysis revealed that our logging framework, invoked within the finalizer, captured a pointer to the Go wrapper for error context, inadvertently resurrecting it into a global ring buffer. Because Go's finalizer runs concurrently with the application, the object was resurrected after its C memory was freed, but before the request handler finished using it. This race condition created a use-after-free scenario where resurrected objects held dangling C pointers, crashing the service unpredictably under high concurrency.
We considered implementing an explicit Close() method with io.Closer semantics, keeping the finalizer only as a leak detection safety net. This approach offers deterministic resource management and follows Go best practices, ensuring C memory frees immediately when the request completes. However, it introduces the risk of double-free if both Close() and the finalizer run concurrently, and still fails to prevent crashes if developers forget to call Close() and the finalizer resurrects the object.
Another option involved replacing finalizers with a custom registry using uintptr addresses in a sync.Map to track outstanding allocations without preventing garbage collection. This method allows explicit control over object lifecycle monitoring and avoids resurrection side effects entirely. Nevertheless, it requires complex manual synchronization, periodic scanning of the map for stale entries, and risks memory leaks if the registry itself isn't meticulously maintained, adding significant operational overhead.
We also evaluated modifying finalizers to detect resurrection by checking if the object pointer existed in any global cache before freeing C memory, panicking if detected. While this would surface bugs immediately during testing, it does not solve the underlying resource management issue and would cause production outages instead of graceful degradation. Furthermore, it relies on expensive global locks to check object state, severely impacting the throughput required for our high-performance pipeline.
We ultimately eliminated finalizers entirely from production code, mandating explicit Close() calls enforced via defer statements in all code paths. To prevent premature GC between the last use and the Close() call, we added runtime.KeepAlive(obj) invocations after the critical sections using the C memory. This strategy removed non-deterministic behavior, eliminated the resurrection risk, and aligned with Go's explicit resource management philosophy, though it required refactoring substantial portions of the codebase to ensure Close() was always reachable.
Following the migration, segmentation faults disappeared entirely, and GPU memory usage became predictable and linear with request volume. Static analysis linters were added to enforce Close() calls on these objects, catching resource leaks at compile time. The system now sustains 100k+ requests per second without memory-related crashes, demonstrating that explicit lifecycle management outperforms finalizer-based approaches in mission-critical Go services.
Why might a finalized object be reclaimed by the GC while its finalizer is still executing, and how does runtime.KeepAlive prevent this?
Candidates often assume that the existence of a finalizer keeps the target object alive until the finalizer completes. In reality, once the GC determines an object is unreachable, it becomes eligible for collection immediately, and the finalizer is scheduled to run in a separate goroutine; the object may be reclaimed before the finalizer finishes if no other references exist. To prevent this, runtime.KeepAlive(obj) should be called after the last use of the object, creating a compiler-level happens-before edge that extends the object's lifetime until that point, ensuring C resources or other dependencies remain valid throughout the finalizer's execution.
Can a single Go object have multiple finalizers registered via sequential calls to runtime.SetFinalizer, and what happens if the finalizer function itself is a closure capturing the object?
Many candidates incorrectly believe that multiple finalizers can form a chain or queue on one object. Go explicitly overwrites any existing finalizer when SetFinalizer is called again, keeping only the most recent function pointer in the internal runtime hash table. If the finalizer is a closure capturing the object, it creates a circular reference that keeps the object permanently reachable, preventing the finalizer from ever running and causing a memory leak, as the GC sees the captured reference in the closure's variables.
How does the GC handle the execution order of finalizers for a graph of objects where A references B and both have finalizers registered?
Candidates frequently expect deterministic ordering, such as child-before-parent or LIFO stack behavior. Go provides no ordering guarantees because the GC enqueues finalizers for all unreachable objects simultaneously into a global queue processed by multiple background goroutines in parallel. If A's finalizer accesses B, and B's finalizer has already run and potentially freed resources, A's finalizer will encounter corrupted state or use-after-free errors, necessitating that finalizers never access other objects that also have finalizers, or that all cleanup logic be centralized in a single finalizer for the root object.