How does Go manage memory and garbage collection?

Question

Accepted Answer

Go **automatically manages memory** with a garbage collector, freeing you from manual allocation/freeing. Its GC is a **concurrent, low-latency, non-generational mark-and-sweep** collector designed to minimize pause times — a key reason Go suits latency-sensitive services.

## Stack vs heap and 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's compiler performs **escape analysis** at compile time: values that don't outlive their function stay on the cheap, automatically-freed **stack**; values whose references escape go on the **heap** (where the GC manages them). Stack allocation is essentially free, so minimizing heap escapes reduces GC work.

## 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 deliberately prioritizes **low pause times** over raw throughput — the GC does most work concurrently with your program, keeping "stop-the-world" pauses very short. This makes Go strong for 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
```

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

Fewer allocations = less GC work. `sync.Pool` (object reuse), preallocation, and minimizing escapes are the main ways to reduce GC pressure in hot paths.

## Memory leaks still happen

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

## Why it matters

Go's automatic memory management is a major productivity and safety win (no manual free, no dangling pointers), but understanding *how* it works is valuable for performance-critical and latency-sensitive applications — which Go is often chosen for.

Key insights: **escape analysis** determines stack vs heap allocation (stack is free; minimizing heap escapes reduces GC work), and Go's **concurrent, low-latency GC** prioritizes short pauses over throughput (ideal for servers, unlike throughput-focused collectors).

Knowing how to reduce GC pressure (`sync.Pool`, preallocation, fewer allocations in hot loops), tune it (`GOGC`, `GOMEMLIMIT`), and recognize that **leaks still occur** from lingering references (especially goroutine leaks) is important for operating high-performance Go services.

This is deep, practical knowledge that distinguishes senior Go developers and is a common advanced interview topic for performance-sensitive roles.