GOMAXPROCS

Canonical guidance

• leave GOMAXPROCS at the runtime default unless data says otherwise
• use it to tune throughput or CPU sharing, not to fix race or scheduling bugs
• re-measure after changing it

Use when

• CPU-bound workloads
• constrained container environments
• runtime investigation under production-like load

Avoid

• pinning a magic value from folklore
• using GOMAXPROCS=1 to hide concurrency bugs
• discussing scheduler tuning before measuring

Preferred pattern

• benchmark or trace with the default, then compare a small set of explicit values if needed

Anti-pattern

• changing GOMAXPROCS in library code

Explanation: This is tempting because local tuning can look effective, but library-level scheduler control surprises callers and rarely generalizes.

Why

• GOMAXPROCS is an environment-wide runtime policy knob