Two channels carry direction: jobs flows producer to workers, results flows workers to consumer. The worker uses for j := range jobs which exits cleanly when jobs is closed; that is what the close(jobs) after the producer loop does. A sync.WaitGroup tracks how many worker goroutines are still running so the consumer can close results only when all workers have finished. The buffered channels (make(chan int, 10)) decouple producer and consumer enough to overlap, but pick the buffer size based on actual workload, not by reflex. The whole pattern is O(jobs / workers) wall time at the cost of one goroutine per worker plus two channels.

Closing a channel signals 'no more values will be sent'. Receivers ranging over the channel keep reading until the buffer is drained, then exit the loop. Sending on a closed channel panics, so the rule is: only the SENDER closes, never the receiver. When multiple senders exist, coordinate them with a sync.WaitGroup and have a single goroutine close the channel after wg.Wait() returns (the pattern in accordion 1). Closing an unbuffered channel also unblocks any receiver that was waiting, returning the zero value plus ok = false from the comma-ok form.

When you do not need return values, a sync.WaitGroup plus a goroutine per item is the simplest possible parallel-foreach. wg.Add(1) BEFORE spawning, defer wg.Done() inside, wg.Wait() at the end. The local copy item := it is essential on Go 1.21 and earlier because the loop variable was reused across iterations; without the copy, every goroutine would see whatever the loop variable held at the time it started. Go 1.22 fixed the loop-variable semantics, but the explicit copy is still a safe habit. Avoid spawning unbounded goroutines this way over user input; for that, use the worker-pool pattern in accordion 1.