Goroutines, channels and the sync package: Go concurrency in outline

What it is

The language specification defines a go statement as starting a function call as an independent concurrent thread of control within the same address space; the caller does not wait for it. The runtime multiplexes goroutines onto operating-system threads with small, growable stacks, so a server can afford one per connection. Channels are typed conduits created with make(chan T, capacity): with capacity zero a send completes only when a receiver is ready; otherwise sends block only when the buffer is full. select waits on several channel operations at once, close signals that no more values will come, and range drains a channel until it is closed. The sync package supplies Mutex, RWMutex, WaitGroup (whose Go method, added in Go 1.25, starts and tracks a goroutine), Once and the OnceFunc/OnceValue helpers (Go 1.21); its documentation says that higher-level synchronisation is better done via channels and communication.

Why it matters

Engineers from CPython under the GIL or from Node.js have never had two code paths mutate one map at the same moment; in Go they can. The memory model defines a data race as a write to a memory location happening concurrently with another read or write of it, unless all accesses are atomic; an implementation may report the race and halt the program, and races on interface values, maps, slices and strings can lead to arbitrary memory corruption. A racing counter merely loses increments and nobody notices.

How to apply

• Choose the primitive by the shape of the problem: channels for handing work or results between stages, a mutex for a small piece of shared state, a WaitGroup for waiting until a batch has finished.
• Bound concurrency: a buffered channel used as a semaphore, or a fixed pool of worker goroutines reading from one channel, instead of one goroutine per item of an unbounded loop.
• Make every goroutine's exit condition explicit: who closes the channel, which context cancels it. A goroutine blocked forever on a channel nobody reads is a leak.
• Run tests with go test -race; the race detector documentation states that it only finds races that happen at runtime, so the concurrent paths must be exercised.
• Never copy sync values; the package documentation states that values containing its types should not be copied.

Pitfalls

Sending on a closed channel and closing a channel twice both panic; only the sender should close. A nil channel blocks forever, which is useful in select to disable a case and a bug anywhere else. WaitGroup.Add must happen before the goroutine starts, not inside it. Unbuffered channels couple sender and receiver timing; buffers hide backpressure until they fill.