Channels: synchronization points, bounded queues, and the deadlocks between them

Unbuffered is a rendezvous, buffered is a queue

An unbuffered channel (make(chan T)) has no storage: a send blocks until a receiver is ready, and the value is handed directly from one goroutine’s stack to the other’s. That makes it a synchronization point — when ch <- v returns, you know a receiver has the value, and the send is guaranteed to happen-before the receive completes. A buffered channel (make(chan T, n)) is a bounded FIFO queue: sends complete immediately while there is capacity, block when full; receives block when empty. The semantics differ in kind, not degree: an unbuffered channel transfers and synchronizes; a buffered channel mostly just transfers, telling you nothing about when the other side ran.

The capacity is a tuning knob with a sharp edge. Capacity 0 couples producer and consumer beat-for-beat. A small buffer (the size of a real burst) absorbs jitter and decouples their schedules. An “infinite” buffer (make(chan T, 1_000_000)) is how you convert visible backpressure into invisible memory growth — the producer never feels the consumer falling behind until the process OOMs. Senior rule: choose 0 unless you can say which measured burst the buffer absorbs, and treat a full buffer as signal (the consumer is too slow), not as an obstacle to bypass with a bigger number.

The channel axioms

Four behaviors define every channel bug you will ever debug:

1. Send to a nil channel blocks forever. Same for receive. A var ch chan int never made — or a map lookup that returned the zero value — produces a goroutine parked permanently. Deliberately useful inside select: setting a case’s channel to nil disables that case.
2. Receive from a closed channel returns immediately with the element type’s zero value; the two-value form v, ok := <-ch reports ok == false. A for range ch loop exits when the channel is closed and drained — which is why range over a channel nobody closes hangs forever.
3. Send to a closed channel panics. Always, immediately, unrecoverable in the sense that it means a protocol violation: two parties believed they owned the channel.
4. Close of a closed (or nil) channel panics. Close is a one-shot broadcast, not a cleanup you sprinkle defensively.

Together these four axioms define the ownership rule and explain every mysterious deadlock or panic you’ll encounter: a nil channel silently absorbs, a closed one silently drains, and a second writer silently corrupts — three different failure modes, all invisible without the axioms. The sender closes, never the receiver, and exactly one party closes. Close means “no more values will ever arrive” — it is a message from the producer. With multiple producers, none of them can safely close; the idiom is a sync.WaitGroup over the producers and one supervising goroutine that calls close after wg.Wait().

// Fan-out / fan-in with correct close discipline and cancellation.
func process(ctx context.Context, rows <-chan Row) <-chan Result {
	out := make(chan Result)
	var wg sync.WaitGroup
	for i := 0; i < 8; i++ { // fan-out: 8 workers share one input channel
		wg.Add(1)
		go func() {
			defer wg.Done()
			for r := range rows { // exits when rows is closed and drained
				select {
				case out <- transform(r):
				case <-ctx.Done(): // unblocks the send if downstream is gone
					return
				}
			}
		}()
	}
	go func() { // exactly one closer, after ALL senders are done
		wg.Wait()
		close(out)
	}()
	return out // fan-in: the consumer ranges over a single merged stream
}

select: composing channels, and the default escape hatch

select waits on several channel operations and runs one that is ready, choosing uniformly at random among ready cases — randomness is deliberate, preventing starvation of a always-also-ready case. With a default clause it becomes non-blocking: try the operation, fall through if it would block. That is the building block for try-send patterns — shed load instead of queuing it:

select {
case events <- e: // delivered
default:
	droppedTotal.Inc() // buffer full: drop and count, don't block the hot path
}

The honest tradeoff: default converts blocking into data loss, which is right for metrics and wrong for money. The middle option is a timeout case (case <-time.After(d) — or a reusable time.Timer in hot loops, since time.After allocates a timer that lives until it fires).

Cancellation flows down the pipeline

A pipeline is only as robust as its exit story. The standard contract: every stage takes a context.Context, and every send sits inside a select with case <-ctx.Done(). Cancellation flows downward from the caller; close flows forward with the data; and goroutines unblock no matter which side disappears. Skip the select on send and you recreate the Hook: a downstream stage that stops reading leaves every upstream sender parked forever — the leak from the previous lesson, manufactured wholesale. The runtime only declares deadlock! when every goroutine is parked; in a real server with one live HTTP listener, your deadlocked pipeline just sits there silently, indistinguishable from idle except in the goroutine profile.