How does Go's garbage collector handle memory allocation in concurrent programs?

16 Eyl 11:11

Go’s GC is a *tri‑color* concurrent collector, so it doesn’t stop the world for the whole mark‑and‑sweep cycle. When a GC cycle starts, the runtime briefly pauses all goroutines (usually a few hundred microseconds) to take a snapshot of the root set—stack frames, globals, and the current heap state. After that the “mark” phase runs concurrently with your goroutines: the collector walks the object graph while the program keeps allocating. When marking is done, there’s a second, still‑short pause to finish marking any objects that were created during the concurrent phase, then the sweep phase runs in parallel and finally a final pause releases the memory back to the allocator. In practice you’ll see a few GC pauses per second, each typically under a millisecond on modern hardware, even with thousands of goroutines. In my services I’ve tuned GC mainly by adjusting **GOGC** (the target heap‑growth ratio) and, when latency is critical, by using **GODEBUG=gctrace=1,gcpacertrace=1** to see pause times. A lower GOGC (e.g., 50) forces more frequent collections, which keeps the live set small and reduces the worst‑case pause but adds CPU overhead. Raising it (e.g., 200) cuts GC CPU but can let the heap grow a lot, leading to longer pause spikes when the collector finally runs. Also, avoid long‑living goroutine stacks that keep references to large objects—this can make the concurrent mark work harder. If you see “GC CPU 30 %” in the trace, try a modest GOGC increase; if you need sub‑millisecond tail latency, pull it down and consider pre‑allocating buffers or using object pools to reduce allocation churn. The sweet spot is usually around the default GOGC=100, with a slight tweak based on your workload’s allocation rate and latency budget.