Go memory और garbage collection को कैसे प्रबंधित करता है?

Question

Accepted Answer

Go एक garbage collector के साथ **स्वचालित रूप से memory प्रबंधित** करता है, जो आपको manual allocation/freeing से मुक्त करता है। इसका GC एक **concurrent, low-latency, non-generational mark-and-sweep** collector है जो pause times को न्यूनतम करने के लिए design किया गया है — एक मुख्य कारण कि 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** करता है: वे values जो अपने function से अधिक नहीं टिकतीं, सस्ते, स्वचालित-रूप-से-मुक्त **stack** पर रहती हैं; वे values जिनके 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 जानबूझकर raw throughput पर **कम pause times** को प्राथमिकता देता है — GC अधिकांश काम आपके program के साथ समानांतर रूप से करता है, "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 तकनीक)

```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 का स्वचालित memory प्रबंधन एक बड़ी productivity और सुरक्षा जीत है (कोई manual free नहीं, कोई dangling pointers नहीं), लेकिन यह *कैसे* काम करता है यह समझना performance-critical और latency-sensitive applications के लिए मूल्यवान है — जिनके लिए Go अक्सर चुना जाता है।

मुख्य अंतर्दृष्टियाँ: **escape analysis** stack बनाम heap allocation निर्धारित करता है (stack मुफ़्त है; heap escapes को न्यूनतम करना GC काम कम करता है), और Go का **concurrent, low-latency GC** throughput पर छोटे pauses को प्राथमिकता देता है (servers के लिए आदर्श, throughput-केंद्रित collectors के विपरीत)।

GC pressure कैसे कम करें (`sync.Pool`, preallocation, hot loops में कम allocations), इसे tune करें (`GOGC`, `GOMEMLIMIT`), और यह पहचानना कि lingering references (खासकर goroutine leaks) से **leaks फिर भी होते हैं** — उच्च-performance Go services चलाने के लिए महत्वपूर्ण है।

यह गहरा, व्यावहारिक ज्ञान है जो senior Go developers को अलग करता है और performance-sensitive भूमिकाओं के लिए एक आम advanced interview विषय है।