Goroutine dump debugging

Canonical guidance

• capture evidence during the live failure window
• map blocked stacks back to owners and resources
• pair stack dumps with other diagnostics when needed

Use when

• hung services
• deadlock suspicion
• unexplained goroutine growth or blocked workers

Avoid

• reading one stack in isolation and guessing
• collecting dumps long after the system recovered
• treating goroutine count alone as the diagnosis

Preferred pattern

pprof.Lookup("goroutine").WriteTo(w, 2)

Anti-pattern

• restarting the process before collecting any runtime evidence

Explanation: This is tempting because restart restores service fastest, but it destroys the best debugging signal.

Why

• stuck concurrent systems are easiest to diagnose from live blocking state