Go میموری اور garbage collection کو کیسے منظم کرتا ہے؟

Question

Accepted Answer

Go **خودکار طور پر میموری کو منظم** کرتا ہے garbage collector کے ساتھ، جو آپ کو دستی allocation/freeing سے آزاد کرتا ہے۔ اس کا GC ایک **concurrent، low-latency، non-generational mark-and-sweep** collector ہے جو pause times کو کم کرنے کے لیے ڈیزائن کیا گیا ہے — Go کو latency-sensitive services کے لیے موزوں بنانے کا ایک اہم سبب۔

## Stack بمقابلہ heap اور escape analysis

```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 کا compiler compile time پر **escape analysis** کرتا ہے: اقدار جو اپنے function سے زیادہ عمر نہیں رکھتیں وہ سستے، خود بخود free ہونے والے **stack** پر رہتی ہیں؛ اقدار جن کے references escape ہو جاتے ہیں وہ **heap** پر جاتی ہیں (جہاں GC انہیں منظم کرتا ہے)۔ Stack allocation بنیادی طور پر مفت ہے، تو heap escapes کو کم کرنا GC کے کام کو کم کرتا ہے۔

## Garbage collector: concurrent 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 عام throughput پر **low pause times** کو ترجیح دیتا ہے — GC اپنے زیادہ تر کام آپ کے پروگرام کے ساتھ concurrently کرتا ہے، "stop-the-world" pauses کو بہت مختصر رکھتا ہے۔ یہ Go کو latency-sensitive servers کے لیے مضبوط بناتا ہے۔

## GC کو tune کریں

```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 pressure کو کم کریں (performance technique)

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

کم allocations = کم GC کام۔ `sync.Pool` (object reuse)، preallocation، اور escapes کو کم کرنا hot paths میں GC pressure کو کم کرنے کے بنیادی طریقے ہیں۔

## Memory leaks اب بھی ہو سکتے ہیں

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

## یہ کیوں اہم ہے

Go کا خودکار میموری انتظام ایک بڑی productivity اور safety کی جیت ہے (کوئی دستی free نہیں، کوئی dangling pointers نہیں)، لیکن یہ سمجھنا کہ *یہ* کیسے کام کرتا ہے performance-critical اور latency-sensitive applications کے لیے قیمتی ہے — جن کے لیے Go اکثر منتخب ہوتا ہے۔

کلیدی insights: **escape analysis** stack بمقابلہ heap allocation کا تعین کرتا ہے (stack مفت ہے؛ heap escapes کو کم کرنا GC کے کام کو کم کرتا ہے)، اور Go کا **concurrent، low-latency GC** throughput پر short pauses کو ترجیح دیتا ہے (servers کے لیے مثالی، throughput-focused collectors کے برعکس)۔

GC pressure کو کم کرنا (`sync.Pool`, preallocation, hot loops میں کم allocations)، اسے tune کرنا (`GOGC`, `GOMEMLIMIT`)، اور یہ سمجھنا کہ **leaks اب بھی** lingering references سے ہو سکتے ہیں (خاص طور پر goroutine leaks) high-performance Go services کو چلانے کے لیے اہم ہے۔

یہ گہری، عملی معلومات ہے جو senior Go developers کو الگ کرتی ہے اور performance-sensitive roles کے لیے ایک عام advanced interview topic ہے۔