A Go automatikusan kezeli a memóriát egy garbage collector-ral, felszabadítva az manuális allokációtól és felszabadítástól. A GC egy párhuzamos, alacsony latenciájú, nem-generációs mark-and-sweep collector, amely a szünet időtartamok minimalizálására van tervezve — ez egy kulcsfontosságú oka annak, hogy a Go jól alkalmas a késleltetésre érzékeny szolgáltatásokhoz.
{
x :=
x
}
* {
x :=
&x
}
A Go fordítóprogram escape analysis-t végez fordítási időben: azok az értékek, amelyek nem élnek túl a függvényt, az olcsó, automatikusan felszabadított stacken maradnak; azok az értékek, amelyeknek a referenciái kimenekülnek, a heapen kerülnek (ahol a GC kezeli őket). A stack allokáció gyakorlatilag ingyenes, ezért a heap escape-ek minimalizálása csökkenti a GC munkát.
Go's GC characteristics:
✓ MARK-AND-SWEEP — marks reachable objects (from roots), sweeps the rest
✓ CONCURRENT — runs mostly alongside your program (not stop-the-world)
✓ LOW LATENCY — optimized for short pauses (typically sub-millisecond), not throughput
✓ NON-GENERATIONAL — unlike the JVM, treats all objects uniformly (simpler)
A Go szándékosan az alacsony szünet időtartamokat helyezi előtérbe a nyers átviteli teljesítménnyel szemben — a GC a legtöbb munkát párhuzamosan végzi a programmal, nagyon rövid "stop-the-world" szüneteket tartva. Ez erős pozícióba helyezi a Go-t a késleltetésre érzékeny szerverek esetén.
GOGC=100 # default: trigger GC when heap grows 100% since the last collection
# higher GOGC → less frequent GC (more memory, less CPU)
# lower GOGC → more frequent GC (less memory, more CPU)
GOMEMLIMIT=2GiB # a soft memory limit (Go 1.19+) — GC works harder near it
// 1. reuse objects with sync.Pool to reduce allocations
var bufPool = sync.Pool{New: func() any { return new(bytes.Buffer) }}
buf := bufPool.Get().(*bytes.Buffer)
defer bufPool.Put(buf)
// 2. preallocate slices with known capacity (avoid repeated growth/realloc)
data := make([]int, 0, 1000)
// 3. minimize heap escapes; avoid unnecessary pointers/allocations in hot loops
Kevesebb allokáció = kevesebb GC munka. A sync.Pool (objektum újrafelhasználás), az előallokáció és az escape-ek minimalizálása az elsődleges módok a GC terhelésének csökkentésére a kritikus kódutakban.
GC frees only UNREACHABLE objects. Leaks come from lingering REFERENCES:
✗ goroutine leaks (a blocked goroutine keeps its referenced memory alive)
✗ growing global maps/slices, unclosed resources, forgotten subscriptions
A Go automatikus memóriagazdálkodása egy nagy termelékenységi és biztonsági nyereség (nincs manuális felszabadítás, nincs lebegő mutató), de annak megértése, hogy hogyan működik, értékes a teljesítménykritikus és késleltetésre érzékeny alkalmazásokhoz — amelyekhez a Go-t gyakran választják.
Fontosabb felismerések: az escape analysis határozza meg a stack vs heap allokációt (a stack ingyenes; a heap escape-ek minimalizálása csökkenti a GC munkát), és a Go párhuzamos, alacsony latenciájú GC-je előnyben részesíti a rövid szüneteket az átviteli teljesítménnyel szemben (ideális szerverekhez, az átviteli teljesítményre fókuszáló collector-okkal ellentétben).
Annak ismerete, hogy hogyan lehet csökkenteni a GC terhelését (sync.Pool, előallokáció, kevesebb allokáció a kritikus ciklusokban), hangolni (GOGC, GOMEMLIMIT), és felismerni, hogy a szivárgások továbbra is előfordulnak a maradandó referenciáktól (különösen goroutine szivárgások) fontos a nagy teljesítményű Go szolgáltatások üzemeltetéséhez.
Ez mélyreható, praktikus tudás, amely megkülönbözteti az idősebb Go fejlesztőket, és egy gyakori haladó interjútema a teljesítményre érzékeny szerepekhez.