Go belleği nasıl yönetir ve çöp toplama nasıl çalışır?

Question

Accepted Answer

Go, bir çöp toplayıcı ile belleği **otomatik olarak yönetir**, sizi manuel ayırma/serbest bırakmadan kurtarır. GC'si, duraklatma sürelerini en aza indirmek için tasarlanmış bir **eş zamanlı, düşük gecikme, nesil-olmayan mark-and-sweep** toplayıcıdır — Go'yu gecikmeye duyarlı hizmetler için uygun kılan temel bir sebep.

## Yığın vs heap ve escape analizi

```go
// the compiler decides where each value lives via ESCAPE ANALYSIS
func noEscape() int {
    x := 42        // stays on the STACK — doesn't escape, freed when function returns (cheap)
    return x
}
func escapes() *int {
    x := 42        // ESCAPES to the HEAP — its pointer outlives the function (GC-managed)
    return &x
}
```

Go'nun derleyicisi derleme zamanında **escape analizi** gerçekleştirir: fonksiyonlarından daha uzun yaşamayan değerler ucuz, otomatik olarak serbest bırakılan **yığında** kalır; referansları kaçan değerler **heap'e** gider (GC'nin yönettiği yer). Yığın ayırması temelde ücretsizdir, bu nedenle heap kaçışlarını en aza indirmek GC işini azaltır.

## Çöp toplayıcı: eş zamanlı mark-and-sweep

```text
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)
```

Go, "durakla-dünya" duraklatmalarını çok kısa tutarak, programınızla eş zamanlı olarak işin çoğunu yaparak — ham verimlilik yerine **düşük duraklatma sürelerini** kasıtlı olarak önceliklendiriyor. Bu, Go'yu gecikmeye duyarlı sunucular için güçlü kılıyor.

## GC'yi ayarlama

```bash
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
```

## GC baskısını azaltma (performans tekniği)

```go
// 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
```

Daha az ayırma = daha az GC işi. `sync.Pool` (nesne yeniden kullanımı), ön ayırma ve kaçışları en aza indirmek sıcak yollarda GC baskısını azaltmanın ana yollarıdır.

## Bellek sızıntıları yine de oluşur

```text
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
```

## Neden önemli

Go'nun otomatik bellek yönetimi büyük bir üretkenlik ve güvenlik kazanımıdır (manuel free yok, asılı pointer yok), ancak *nasıl* çalıştığını anlamak performans açısından kritik ve gecikmeye duyarlı uygulamalar için değerlidir — Go genellikle bunun için seçilir.

Temel içgörüler: **escape analizi** yığın vs heap ayırmasını belirler (yığın ücretsizdir; heap kaçışlarını en aza indirmek GC işini azaltır) ve Go'nun **eş zamanlı, düşük gecikme GC'si** verim yerine kısa duraklatmaları önceliklendiriyor (sunucular için idealdir, verim-odaklı toplayıcılardan farklı).

GC baskısını nasıl azaltacağınızı (`sync.Pool`, ön ayırma, sıcak döngülerde daha az ayırma), nasıl ayarlayacağınızı (`GOGC`, `GOMEMLIMIT`) ve **sızıntıların yine de oluşabildiğini** lingering referanslardan (özellikle goroutine sızıntıları) tanıyabiliyor olmak yüksek performanslı Go hizmetlerini çalıştırmak için önemlidir.

Bu, kıdemli Go geliştiricilerini ayırt eden ve performansa duyarlı roller için yaygın bir ileri mülakat konusu olan derin, pratik bilgidir.