In Go, how can a stored callback closure keep a large captured []byte alive for the process's lifetime?

## What actually holds the memory A closure is a function value plus references to the variables its body mentions. Reachability follows those references: as long as the function value is reachable, so is every variable it captured, and so is everything those variables point to. A closure sitting in a long-lived table is therefore a garbage-collection root for its captured state. This is entirely a language-level fact — no runtime interior needed. The captured variable outlives the frame that declared it, by design, because that is what makes returning a closure safe. The cost is that it also outlives the *work* that created it if nothing drops the closure. ## The two shapes that retain far more than intended **Capturing a container to use one field.** A scheduler registers a retry callback: ```go func (s *Scheduler) register(req *Request) { s.onRetry[req.ID] = func() { s.retry(req.ID) } } ``` The literal mentions `req`, so the whole `*Request` — headers, decoded body, whatever else it holds — stays reachable while the entry lives, even though only `req.ID` is used. Copying the id out first fixes it: ```go id := req.ID s.onRetry[id] = func() { s.retry(id) } ``` Now the closure references an `int` (or a string), and the request can be collected as soon as the request handling ends. **Capturing a slice of a much bigger array.** Slicing does not copy. A `[]byte` taken from a 100 MB read is a window onto that same backing array, so a closure that captures the window retains all 100 MB. If the closure needs the window for a long time, copy it: `hdr := append([]byte(nil), buf[:32]...)` gives a small array of its own, and the big one becomes collectible. The same reasoning applies to a substring of a huge string, a small map derived from a big one by reference, and any struct field pointing back into bulk data. ## Capture is per variable, and that is the lever A closure does not retain the whole enclosing frame or every local in scope — only the variables its body actually references. That is precisely why the fixes above work: they change *which variables the body mentions*, and everything else becomes unreachable at the usual time. Two habits follow. 1. **Introduce the narrow variable immediately before the literal.** One line, obvious intent, and reviewable. 2. **Prefer parameters over capture for long-lived callbacks.** A closure built by a helper whose parameter list names exactly what it needs makes retention visible in a signature instead of hidden in a body. A third habit, easy to forget: because capture is by variable, you can also release from the outside. If the enclosing code sets the captured variable to nil after registration, the closure and the enclosing code are looking at the same variable, so the big object really does become collectible — at the price of the closure now seeing nil. Use it only where the closure genuinely no longer needs the value. ## Then check the registry itself Narrowing the capture reduces how much each entry holds; it does not help if the table grows without bound. Ask three questions of any structure holding closures: * **Is there a delete?** A callback map keyed by request id with no deletion on completion, cancellation and error is a leak whatever the closures capture. * **Is the slot cleared, not just skipped?** Marking an entry done while leaving the function value in the slice keeps it reachable. Set it to nil or drop the element. * **Is registration bounded?** A daemon that registers per attempt and retries forever accumulates entries as fast as it retries. ## Diagnosing it Start from a heap profile taken during steady state and look at `inuse_space`, not `alloc_space`: the question is what is still live, not what was ever allocated. Two heap profiles taken minutes apart, diffed, show the growing class. The retained type usually points straight at the container being held — request structs, byte slices, decoded documents — while the *reason* it is held is the closure, which is why the allocation site alone can be misleading. Pair it with a count of entries in the registry: if entries are flat and live bytes climb, each closure is holding too much; if entries climb, the registry never deletes. ## Reviewing for it The review question is short: for every function literal that is stored rather than called immediately, what does its body name, and who drops it? A callback that captures one small identifier and is deleted on completion has none of these problems. A callback that captures the whole context of the operation that created it and lives in a package-level map is a slow leak waiting for enough traffic. ## What not to say Do not claim the closure copies what it needs, or that the captured variables are freed when the enclosing function returns — both are the opposite of Go's rule. And do not answer this with a story about where the compiler decides to put the variable; the retention is caused by reachability from a long-lived value, and that is true regardless of any placement decision.