Runtime

Go 16 Sep 2026 4 min read

Go Runtime Finalizers Delay Object Reclamation

A Go object with a finalizer is not reclaimed when the garbage collector first determines that it is unreachable. The runtime must retain the object for the finalizer call, and reclamation can occur only after a later collection finds the object unreachable again. That behavior makes runtime.SetFinalizer materially different from ordinary garbage collection. It adds an asynchronous lifecycle phase between loss of application reachability and memory reclamation. Finalization temporarily restores reachability runtime.SetFinalizer(obj, f) associates f with obj. When the collector detects an unreachable object with that association, it clears the association and arranges a call to f(obj).

Golang Runtime

Go 16 Sep 2026 4 min read

Go Map Iteration Order Is Not Stable

A range over a Go map can visit the same entries in a different order on consecutive iterations. The language specification leaves map iteration order unspecified and gives no guarantee that a later pass over an unchanged map will repeat an earlier sequence. That contract is stronger than saying that maps are merely unsorted. An unsorted container could still expose a stable insertion-dependent or storage-dependent sequence. A Go program cannot assign such meaning to map traversal.

Golang Maps

Go 16 Sep 2026 4 min read

Go Defer Saves Call Arguments Before Return

A Go defer statement evaluates its function value and call parameters when execution reaches the statement, even though the deferred function runs only as the surrounding function returns. Mutations between those two moments do not retroactively change already saved argument values. This split between evaluation and invocation is part of the language semantics rather than an optimization detail. Each executed defer records a call with values established at that point. Return processing later invokes recorded calls in reverse registration order.

Golang Defer