Go ਮੈਮੋਰੀ ਅਤੇ ਗਾਰਬੇਜ ਕਲੈਕਸ਼ਨ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਬੰਧਿਤ ਕਰਦਾ ਹੈ?

Question

Accepted Answer

Go **ਸਵੈਚਲਿਤ ਰੂਪ ਵਿੱਚ ਮੈਮੋਰੀ ਦੌ ਪ੍ਰਬੰਧਨ** ਇੱਕ ਗਾਰਬੇਜ ਕਲੈਕਟਰ ਦੇ ਨਾਲ ਕਰਦਾ ਹੈ، ਜੋ ਤੁਹਾਨੂੰ ਦਸਤੀ allocation/freeing ਤੋਂ ਮੁਕਤ ਕਰਦਾ ਹੈ। ਇਸ ਦਾ GC ਇੱਕ **concurrent, low-latency, non-generational mark-and-sweep** ਕਲੈਕਟਰ ਹੈ ਜੋ 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 **escape analysis** ਨੂੰ compile time ਉੱਤੇ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦਾ ਹੈ: ਮੁੱਲ ਜੋ ਆਪਣੇ function ਨੂੰ outlive ਨਹੀਂ ਕਰਦੇ ਉਹ ਸਸਤੇ, ਸਵੈਚਲਿਤ-freed **stack** ਉੱਤੇ ਰਹਿੰਦੇ ਹਨ؛ ਜਿਨ੍ਹਾਂ ਦੇ references escape ਹਨ ਉਹ **heap** ਉੱਤੇ ਜਾਂਦੇ ਹਨ (ਜਿੱਥੇ GC ਉਨ੍ਹਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ)। Stack allocation ਜਨਮਵਾਰੀ ਮੁਫਤ ਹੈ, ਇਸ ਲਈ heap escapes ਨੂੰ ਘੱਟ ਕਰਨਾ GC ਕੰਮ ਨੂੰ ਘੱਟ ਕਰਦਾ ਹੈ।

## The 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 ਜਾਣ-ਬੁੱਝ ਕੇ **low pause times** ਨੂੰ raw throughput ਦੇ ਉੱਪਰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ — GC ਆਪਣੇ program ਦੇ ਨਾਲ concurrently ਬਹੁਤਾ ਕੰਮ ਕਰਦਾ ਹੈ, "stop-the-world" pauses ਨੂੰ ਬਹੁਤ ਛੋਟਾ ਰੱਖਦਾ ਹੈ। ਇਹ Go ਨੂੰ latency-sensitive servers ਲਈ ਮਜ਼ਬੂਤ ਬਣਾਉਂਦਾ ਹੈ।

## Tuning the 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 ਨੂੰ ਘੱਟ ਕਰਨਾ (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 ਦਾ ਸਵੈਚਲਿਤ ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ ਉਤਪਾਦਕਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਦੀ ਇੱਕ ਵੱਡੀ ਜੀਤ ਹੈ (ਕੋਈ ਦਸਤੀ free ਨਹੀਂ, ਕੋਈ dangling pointers ਨਹੀਂ), ਪਰ ਇਹ ਸਮਝਣਾ ਕਿ *ਕਿਵੇਂ* ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ ਪ੍ਰਦਰਸ਼ਨ-ਜ਼ੀ ਅਤੇ 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 ਹਾਲੇ ਵੀ occur ਕਰਦੇ ਹਨ** lingering references ਤੋਂ (ਖ਼ਾਸ ਕਰਕੇ goroutine leaks) ਇਹ ਬਲੂੰ-perform Go services ਨੂੰ ਚਲਾਉਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ਇਹ ਡੂੰਘਾ, ਵਿਹਾਰਕ ਗਿਆਨ ਹੈ ਜੋ ਸੀਨੀਅਰ Go developers ਨੂੰ ਵਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ-sensitive roles ਲਈ ਇੱਕ ਆਮ ਉੱਚੀ interview topic ਹੈ।