Channels in Go: a value that bypasses the buffer, a select with no priorities, and a price paid in parking

What is actually being asked

The ladder is almost always this:

1. "What is a channel?" — testing whether you say "a pointer to a structure with a mutex" or stop at the word "pipe".
2. "How does buffered differ from unbuffered?" — testing whether you understand it is about parking, not speed.
3. "What happens sending to a closed channel? Receiving? From a nil one?" — the twelve-cell table.
4. "How does select choose a branch?" — a trap: not top to bottom.
5. "Where is the leak here?" (with code) — testing whether you know a goroutine on a blocked channel lives forever.

The lesson follows that ladder.

Base: one goroutine sent, another received

The simplest model of a channel — the one an answer is worth starting from — consists of two actions and nothing else.

There are two goroutines. One reaches the line ch <- v and sends a value. The other reaches <-ch and receives it. The value moves from the first to the second, and both carry on with their own business.

ch := make(chan int)
 
go func() { ch <- 42 }()   // one sent
v := <-ch                  // the other received

A channel here is not a variable that gets read and written but a meeting place: until somebody arrives from the other side, no value passes through it.

And here is the question this lesson is about: what happens when the send and the receive do not coincide in time? Goroutines proceed at their own pace and reach their lines whenever they do: the sender may arrive at ch <- v a second before the receiver reaches <-ch — or a minute after.

The answer is simple: whoever arrives first waits for the other. A sender with nobody to hand the value to stops and stands there until a receiver turns up; a receiver with nothing to take stands until a value turns up.

Everything else in the topic rests on that waiting. A buffer is a way to postpone the sender's wait. select is a way to wait on several channels at once. Closing is a way to tell everyone waiting that there is nothing left to wait for.

That is already enough to answer the basic interview question, "what is a channel". What follows is how a channel behaves in its other states (the buffer is full, the channel is closed, there is no channel at all), why select has no order, what the waiting costs and where goroutines leak on it.

Mechanism 1: the behaviour table — the whole topic on one screen

A channel is worth working through not from its construction but from what it does in each of its states. This is literally an interview question, and it does not stick as a list — but it does stick as a table, because the cells in it are connected.

Here is the same pair of actions from the Base, laid out across the channel's states:

It reads row by row, and every row is a separate interview question. A third operation, close, adds one more dimension to this; the full twelve-cell table is on the figure. Click the cells — the explanation underneath says why each one is what it is:

Out of twelve cells, what is worth learning is not twelve facts but two rules:

1. Only sending and closing panic, and only where the channel is absent or already closed. Three panics: send on closed, close of closed, close of nil.
2. Receiving never panics. Which is exactly what makes closing usable as a broadcast signal: every waiting reader wakes at once.

And one cell forgotten more than any other: closing does not discard what is already in the buffer. The specification says so word for word — a receive from a closed channel yields the zero value after any previously sent values have been received. The buffered values drain first with ok == true, and only then does the zero value with false begin. The task at the end of this lesson is built on that.

A nil channel is a tool, not a mistake. Since a select branch on a nil channel is never chosen, nilling a channel out is the standard way to switch a branch off:

for {
    select {
    case v, ok := <-in:
        if !ok {
            in = nil        // branch off, the select lives on
            continue
        }
        // …
    case <-ctx.Done():
        return
    }
}

Without that trick a closed channel would spin the select for nothing: a receive from it is always ready.

Mechanism 2: an unbuffered channel is a rendezvous

The table shows the main property of an unbuffered channel: a send and a receive happen at the same moment or not at all. It is not "the sender put it in, the receiver took it out later" — it is a meeting:

Hence the practical reason an unbuffered channel is chosen at all: it provides not the transfer of data but agreement on a moment. A sender that has returned from ch <- v knows the receiver is already there.

And hence, too, what surprises people when the construction is examined.

A channel is nearly always drawn as a pipe: the sender puts a value in the buffer, the receiver takes it out. In the most common case that is wrong.

If a receiver is already waiting, the value bypasses the buffer — copied straight from the sender's stack into the receiver's. The buffer takes no part.

This is not an abstraction about implementation: it is observable from the program. Had the value gone through the buffer, len(ch) would be one. It stays zero.

Hence the right answer to "then why have a buffer at all". A buffer is not for transfer speed but so the sender does not have to wait for a receiver. It does not remove blocking — it defers it by exactly its capacity.

Mechanism 3: a buffered channel is a bounded queue

A buffered channel behaves differently, and the difference fits in one sentence: it is a queue with a fixed capacity, and blocking happens only at its edges.

Hence the right answer to "what is the buffer for, then". A buffer is not for the speed of the transfer, it is so the sender does not have to wait for the receiver. It does not remove the blocking — it defers it by exactly its capacity.

Hence, too, two practical rules worth naming together. A buffer of one is almost always pointless: it removes the wait for the first value only. A very large buffer is harmful in a different way: it hides the receiver failing to keep up and turns a fast failure into slow memory growth. Two sizes make sense — the whole batch, if it is finite and known, and the expected burst, if this is a queue.

Mechanism 4: select does not read branches top to bottom

The most common code-review edit: "put case <-ctx.Done() first so cancellation fires sooner". It does nothing.

The specification: when several communications are ready, a single one that can proceed is chosen via a uniform pseudo-random selection. Branch order in the source means nothing.

When a cancelled context and ready work compete, cancellation wins exactly half the time — no more. If cancellation genuinely must take priority, it is checked in a separate select before the main one:

select {
case <-ctx.Done():
    return ctx.Err()
default:
}

Two more things about select that get asked next:

• default makes a select non-blocking. Without it a select with no ready branch waits; with it, it leaves immediately.
• select {} with no branches blocks forever. That is not a compile error but the idiom for "occupy this goroutine permanently".

Mechanism 5: where goroutines leak

The classic "find the leak" question, and the code is usually this:

func find(ctx context.Context) int {
    ch := make(chan int)          // unbuffered
    go func() { ch <- search() }()
    select {
    case v := <-ch:
        return v
    case <-ctx.Done():
        return -1                 // we left, the goroutine stayed
    }
}

On timeout the function returns — and the goroutine inside is stuck forever on ch <- search(): there is no receiver any more and no buffer.

And such a goroutine is not collected. That is the key fact: it is alive, its stack is alive, and so is everything it references. The garbage collector cannot collect blocked goroutines — it has no way to know nobody will ever wake them.

The cure is a buffer of one: the sender drops the result and leaves, even if there is no longer anyone to read it.

ch := make(chan int, 1)

And separately, on what catches this. go test -race does not find this leak — there is no race here, everything is correctly synchronized. It is caught by counting: runtime.NumGoroutine() before and after, or the goroutine profile from runtime/pprof, or goleak in tests. "The race detector will catch it" is the wrong answer, and that is exactly the difference the question tests.

Mechanism 6: what a channel guarantees about memory

This side gets forgotten and is asked at more senior levels. A channel is not only transport but a synchronization point.

• A send is synchronized before the completion of the receive: everything the sender wrote to memory before ch <- v is visible to the receiver after <-ch.
• Closing is synchronized before a receive that returned the zero value. So close(done) is a legitimate way to publish data written before the close.
• An unbuffered channel adds the reverse guarantee: the receive is synchronized before the completion of the send. Hence its second role, a rendezvous: the sender knows the receiver reached the meeting point.

The practical consequence: close(done) as a readiness signal needs neither a mutex nor atomics around the data it publishes.

Deeper: what is underneath in the runtime

Everything above described what a channel does, and that is enough to answer correctly. What follows is how it is made inside; here the claims change kind, and all of it belongs to one particular version of the runtime.

chan T is a pointer to a runtime structure. Inside it: a ring buffer (if one was requested), a mutex, and two queues of waiting goroutines — those waiting to send and those waiting to receive.

Several answers follow at once:

• A channel passed into a function is the same channel. The pointer is copied, the structure behind it is single. No *chan T is needed.
• A channel is protected by a mutex inside. "A channel is lock-free" is wrong: every operation takes the structure's mutex. That is not where its speed comes from.
• A nil channel is a pointer to nothing. No buffer, no queues: nowhere to put a value, nobody to wake. All of its behaviour follows from that.

It is worth saying out loud what a channel is not. It is not a message queue and not a way to move data faster: two goroutines through a channel are always slower than one without it. What a channel buys is synchronization, and the memory model states it outright: A send on a channel is synchronized before the completion of the corresponding receive from that channel. Everything the sender wrote before sending is guaranteed visible to the receiver after receiving.

The cost is parking, not "the channel"

And before the numbers — one distinction, without which "the goroutine blocked" sounds worse than it is.

A blocked goroutine does not mean a blocked OS thread. Parking is a scheduler operation inside the process: the goroutine comes off its P, another takes its place, the thread keeps working. The kernel neither knows nor participates. Which is why "a thousand goroutines waiting on channels" is a normal state for a program, not a thousand idle threads.

The cause is what matters here. An unbuffered channel really is more expensive, but what costs is not "the channel" — it is parking a goroutine: the sender stops, the scheduler takes it off the processor and puts another on, then back.

Measured on a thousand values passed between two goroutines:

Three times is not "channels are slow", it is a thousand parkings against zero. The cause is easy to check: make the buffer smaller than the batch and the parkings come back proportionally.

And the boundary of that number is named right here: the 3.1 came out on one machine, two cores and one version of Go. The ratio depends on how many goroutines run at once and on whether the sender and the receiver land on the same core — so what travels from here is the cause, not the number. The rule is written this way: the cost of a channel grows with the number of parkings, and it has to be measured on your own load.

How to answer in an interview

Short answer: a channel is a link between two goroutines where the send and the receive meet: while there is no receiver the sender waits, and the other way round. A buffer does not remove that waiting, it defers it by exactly its capacity. A closed channel can be read — the buffered values are drained first; sending to it or closing it twice is not allowed. And select branches are chosen uniformly at random, not top to bottom.

That is enough for a correct answer. What follows is what you add when the interviewer digs.

If the interviewer digs deeper

Answer "what is a channel" with the structure. "A pointer to a structure with a buffer, a mutex and two queues of waiters." Nearly everything else derives from that, including the behaviour of a nil channel.

Say "defers" about buffers, not "speeds up". "A buffer does not remove blocking, it defers it by its capacity; the cost of unbuffered is parking — I measured threefold on a thousand values." The second sentence turns memorized into verified.

Give the table as two rules. "Only sending and closing panic; receiving never panics, which is why closing works as a signal." Few people can recite twelve cells, and two rules reconstruct all of them.

Say "uniformly at random" about select. And add that branch order means nothing, while cancellation priority is done with a separate select and a default. That reads as experience instantly.

On the leak, name both the cause and the tool. "A blocked goroutine is not collected; -race will not find it; it is caught by counting goroutines or by the goroutine profile." Half of candidates answer "the race detector".

Next they ask

Common misconceptions

Practice

Two tasks. Answer first, then check against the real output: in both, the correct answer is taken from a script run rather than assigned.

ch := make(chan int, 2)
ch <- 1
ch <- 2
close(ch)
a, ok1 := <-ch
b, ok2 := <-ch
c, ok3 := <-ch
fmt.Println(a, ok1)
fmt.Println(b, ok2)
fmt.Println(c, ok3)
fmt.Println(len(ch), cap(ch))

1 true
2 true
0 false
0 2

0 false
0 false
0 false
0 2

1 true
2 true
0 false
0 0

1 false
2 false
0 false
2 2

Knowledge check