Go ले मेमोरी र ग्याबेज कलेक्सन कसरी व्यवस्थापन गर्छ?

Question

Accepted Answer

Go **स्वचालित रूपमा मेमोरी व्यवस्थापन** गर्छ ग्याबेज कलेक्टरसँग, तपाईंलाई म्यानुअल allocation/freeing बाट मुक्त गरी। यसको GC एक **concurrent, low-latency, non-generational mark-and-sweep** कलेक्टर हो जुन pause times मिनिमाइज गर्न डिजाइन गरिएको — Go लाई latency-sensitive services को लागि उपयुक्त बनाउने मुख्य कारण।

## Stack vs 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** गर्छ: values जो आफ्नो function को जीवन काल भन्दा लामो नहुन्छन् सस्तो, स्वचालित रूपमा-freed **stack** मा रहन्छन्; values जसको references escape हुन्छ **heap** मा जान्छ (जहाँ GC ले तिनीहरूलाई व्यवस्थापन गर्छ)। Stack allocation अनिवार्यतः निःशुल्क छ, त्यसैले heap escapes मिनिमाइज गर्न GC काम कम गर्छ।

## ग्याबेज कलेक्टर: 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 जानबूझकर **low pause times** लाई raw throughput भन्दा प्राथमिकता दिन्छ — GC ले अधिकांश काम तपाईंको प्रोग्रामसँग समवर्ती रूपमा गर्छ, "stop-the-world" pauses अत्यन्त छोटो राख्छ। यसले Go लाई latency-sensitive servers को लागि बलियो बनाउछ।

## GC को ट्यूनिङ

```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 कम गर्ने (प्रदर्शन प्रविधि)

```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 कम गर्ने।

## मेमोरी 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 को स्वचालित मेमोरी व्यवस्थापन एक प्रमुख उत्पादकता र सुरक्षा लाभ हो (कोन मानुअल free छैन, कोन dangling pointers छैन), तर यो कसरी काम गर्छ भनी बुझ्न performance-critical र latency-sensitive applications को लागि मूल्यवान छ — जसको लागि Go अक्सर चुनिन्छ।

मुख्य अन्तर्दृष्टि: **escape analysis** ले stack vs heap allocation निर्धारण गर्छ (stack निःशुल्क छ; heap escapes मिनिमाइज गर्न GC काम कम गर्छ), र Go को **concurrent, low-latency GC** throughput भन्दा छोटो pauses लाई प्राथमिकता दिन्छ (servers को लागि आदर्श, throughput-focused collectors को विपरीत)।

GC pressure कसरी कम गर्ने (`sync.Pool`, preallocation, hot loops मा कम allocations), यसलाई ट्यून गर्ने (`GOGC`, `GOMEMLIMIT`), र यो बुझ्न कि **leaks अझै पनि हुन्छन्** lingering references बाट (विशेष गरी goroutine leaks) high-performance Go services सञ्चालन गर्नको लागि महत्त्वपूर्ण छ।

यो गहिरो, व्यावहारिक ज्ञान हो जुन senior Go developers लाई छुट्याउने र performance-sensitive roles को लागि सामान्य advanced interview topic हो।