Understanding Memory Management in Go

Go gives you a garbage collector so you do not have to think about malloc and free. That is the pitch, and for most code it holds. But "you do not have to think about memory" quietly becomes "you do not get to control your tail latency" the moment your service is under real load.

The stack is your friend

Not every allocation hits the heap. Go's compiler runs escape analysis to decide whether a value can live on the stack - cleaned up for free when the function returns - or must escape to the heap, where the collector has to track it. You can see its decisions with go build -gcflags='-m'. A surprising amount of optimization work is just convincing the compiler that a value does not need to escape.

The garbage collector trades CPU for pause time

Go's GC is concurrent and tuned to keep stop-the-world pauses tiny, but it is not free. It runs more often as your allocation rate climbs. The single most effective lever most teams never touch is GOGC - raise it and you trade memory headroom for fewer collections, which on an allocation-heavy service can meaningfully cut CPU.

Pool what you churn

When profiling points at allocation pressure in a hot path - decoding requests, building buffers - sync.Pool lets you reuse objects across calls instead of minting and discarding them. It is not a default; it is a targeted fix for a measured problem. Reach for it after the profiler, never before.

The mental model that serves you best: the GC is excellent, but the cheapest allocation is the one you never make. Profile first with pprof, then reduce churn where it actually hurts.