16 — Goroutines

func gomaxprocs() {
    // Default = NumCPU. Don't change it unless you have a specific reason.

    // Reasons to REDUCE GOMAXPROCS:
    //   - In containers with CPU limits, set GOMAXPROCS = the limit
    //     (Go reads the host's CPU count, not the cgroup limit — this
    //     over-allocates threads. Use automaxprocs or set it manually.)
    //   - In a shared environment where you want to leave cores for other
    //     processes.

    // Reasons to INCREASE GOMAXPROCS (rare):
    //   - I/O-bound workload with many goroutines blocking on syscalls.
    //     More Ps allow more syscalls to run concurrently. But each P
    //     can spawn an M (OS thread), so this increases thread count.

    // ⚠️ In Kubernetes/Docker with CPU limits:
    //   Go 1.22+ respects cgroup CPU limits automatically (GOMAXPROCS
    //   = the cgroup quota). Pre-1.22, use go.uber.org/automaxprocs or
    //   set GOMAXPROCS explicitly.
    runtime.GOMAXPROCS(4)  // cap at 4 Ps

    // Query without changing:
    n := runtime.GOMAXPROCS(0)
    fmt.Println("Ps:", n)
}

💡 Tips & Tricks

• Idiom: always pass context.Context to goroutines and select on <-ctx.Done() — this gives every goroutine an exit path, preventing leaks. A goroutine that can block forever with no exit is a leak waiting to happen.
• Idiom: use sync.WaitGroup to wait for a known set of goroutines — wg.Add(1) before go f(), defer wg.Done() inside, wg.Wait() to block. Never Add inside the goroutine (race with Wait).
• Idiom: use a worker pool for bounded concurrency — unbounded go f() in a loop can create millions of goroutines, exhausting memory and overwhelming downstream resources (DB connections, API rate limits).
• Debug: go tool pprof http://localhost:6060/debug/pprof/goroutine shows all live goroutines and their stack traces — leaked goroutines appear stuck on a channel send/receive with no <-ctx.Done() path.
• Safety: always recover in goroutines that handle external input — a single bad request causing a panic shouldn't crash the server. Log the panic + stack trace for debugging.
• Debug: go.uber.org/goleak.VerifyTestMain(m) in tests — fails if goroutines leak after the test suite. Catches leaks in CI before they hit production.

⚠️ Edge Cases & Gotchas

• Main exiting kills all goroutines: main returning terminates the program immediately — goroutines are stopped without running deferred functions. Use WaitGroup/channels to wait.
• Goroutine leak: a goroutine blocked forever with no exit path consumes memory forever. Use context/done channels and select to ensure exit paths.
• Closure capturing loop variables (pre-1.22): for i := 0; ... { go func() { use(i) }() } — all goroutines see the final i. Pass as argument or use Go 1.22+.
• No goroutine ID: Go deliberately doesn't expose goroutine IDs (no goroutine.ID()) to discourage goroutine-local state. Use context for request-scoped values.
• Panic in a goroutine crashes the program: unrecovered panics terminate the whole process. Recover in goroutines that handle external input.
• Goroutines aren't free: ~2KB stack minimum + scheduler overhead. Millions of goroutines doing trivial work waste resources — use a worker pool.
• GOMAXPROCS default = CPU count: usually correct. In containers with CPU limits (pre-1.22), set it explicitly or use automaxprocs — Go reads the host's CPU count, not the cgroup limit.
• runtime.LockOSThread: binds a goroutine to an OS thread — needed for some C libraries (CGO) or runtime-specific APIs. Rare; don't use without a specific reason.
• Goroutine scheduling is preemptive (Go 1.14+): a goroutine can be preempted even without blocking (async preemption). Long CPU loops don't starve other goroutines.
• Starting goroutines in a loop without bounds: for _, item := range huge { go process(item) } creates len(huge) goroutines at once — exhausts memory. Use a worker pool.

🧠 Quick Quiz

func main() {
    for i := 0; i < 3; i++ {
        go func() {
            time.Sleep(100 * time.Millisecond)
            fmt.Print(i, " ")
        }()
    }
    time.Sleep(time.Second)
}