Go કેવી રીતે મેમોરી અને ગાર્બેજ કલેક્શન પ્રબંધિત કરે છે?

Question

Accepted Answer

Go **આપોઆપ મેમોરી વ્યવસ્થાપન** કરે છે ગાર્બેજ કલેક્ટર સાથે, તમને મેનુઅલ alloc/freeing થી મુક્ત કરે છે. તેનો GC એક **concurrent, low-latency, non-generational mark-and-sweep** કલેક્ટર છે જે pause times ને ન્યૂનતમ કરવા માટે ડિઝાઇન કરવામાં આવ્યો છે — એક મુખ્ય કારણ કે Go latency-sensitive સેવાઓ માટે યોગ્ય છે.

## 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** કરે છે: મૂલ્યો જે તેમના ફંક્શન કરતાં લાંબા સમય સુધી જીવતા નથી તે સસ્તા, આપોઆપ-મુક્ત **stack** પર રહે છે; મૂલ્યો જેમના સંદર્ભો 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** ને કાચા throughput પર પ્રાધાન્ય આપે છે — GC મોટાભાગે કાર્ય તમારા પ્રોગ્રામ સાથે સમવર્તી રીતે કરે છે, "stop-the-world" pauses ને ખૂબ જ ટૂંકો રાખે છે. આ latency-sensitive સર્વરો માટે Go ને મજબૂત બનાવે છે.

## 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 દબાણ ઘટાવવું (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 દબાણ ઘટાવવાની મુખ્ય રીતો છે.

## મેમોરી 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 win છે (કોઈ મેનુअલ free નથી, કોઈ dangling pointers નથી), પરંતુ તેનું કેવી રીતે કામ કરે છે તે સમજવું performance-critical અને latency-sensitive એપ્લીકેશનો માટે મૂલ્યવાન છે — જેના માટે Go ઘણીવાર પસંદ કરવામાં આવે છે.

મુખ્ય insights: **escape analysis** stack વર્સસ heap allocation નક્કી કરે છે (stack મુક્ત છે; heap escapes ને ન્યૂનતમ કરવું GC કાર્ય ઘટાવે છે), અને Go ની **concurrent, low-latency GC** throughput કરતાં short pauses ને પ્રાધાન્ય આપે છે (સર્વરો માટે આદર્શ, throughput-focused collectors ની વિપરીત).

GC દબાણ ઘટાવવા માટે કેવી રીતે કાર્ય કરવું (`sync.Pool`, preallocation, hot loops માં ઓછા allocations), તેનું સમાયોજન કરવું (`GOGC`, `GOMEMLIMIT`), અને એ જાણવું કે **leaks હજી પણ થાય છે** lingering references (خاસ કરીને goroutine leaks) થી એ high-performance Go સેવાઓ ચલાવવા માટે મહત્વપૂર્ણ છે.

યે ખોવાય તેવું, વ્યવહારુ જ્ઞાન છે જે વરિષ્ઠ Go developers ને અલગ પાડે છે અને performance-sensitive roles માટે સામાન્ય advanced interview topic છે.