golang-concurrency

Every goroutine needs a clear exit path: pass a context.Context and include a ctx.Done() case in every select, or use a done channel. Pair spawns with sync.WaitGroup or errgroup so callers can wait, and add go.uber.org/goleak to TestMain to catch leaks in tests.

Use errgroup when goroutines return errors, need cancellation of siblings on first failure, or need bounded concurrency via SetLimit. Use sync.WaitGroup only for simple fire-and-wait work with no error propagation; on Go 1.25+, wg.Go simplifies that case.

Use channels to transfer ownership of data between goroutines, and sync.Mutex or sync.RWMutex to protect shared struct fields. For simple counters and flags prefer typed atomics like atomic.Int64, and reserve sync.Map for write-once/read-many workloads.

Only the sender (producer) closes a channel; closing from the receiver panics if the sender writes after close. If a consumer needs to stop early, signal the producer through a separate done channel or context cancellation and let the producer close the data channel.

Each time.After call allocates a new timer, causing repeated allocation churn in hot loops. Create one time.NewTimer outside the loop and call Reset after each event; on Go versions before 1.23, drain the channel if Stop reports a pending value.

sync.Map is optimized for write-once/read-many patterns or disjoint key sets. For write-heavy workloads with overlapping keys, a plain map guarded by sync.RWMutex is faster, and unsynchronized concurrent map access causes a hard crash rather than a recoverable race.