The multi-lane intersection
You have a background worker that listens for jobs on a channel. You also have a shutdown signal on another channel. The worker needs to process jobs until the shutdown signal arrives. If you block on the job channel, you might miss the shutdown. If you block on shutdown, you stop working. You need to watch both at once.
The select statement solves this. It lets a goroutine wait on multiple channel operations simultaneously. The runtime picks the first one that becomes ready and executes that case. If multiple cases are ready, it chooses one at random.
Select is the traffic cop at a multi-lane intersection. The cop does not care which lane has a car. The cop waits for the first lane to have a vehicle ready to move. As soon as one lane is clear, the cop waves that car through. The other lanes wait their turn.
How select works
A select statement blocks until one of its cases can proceed. Each case is a channel send or receive operation. The syntax looks like a switch, but the behavior is concurrent.
The channel operands and expressions are evaluated immediately when the select statement is reached. The blocking happens after evaluation. This means if you have a function call in a case, it runs right away, not when the case is selected. Structure your code so evaluation order does not cause side effects.
When multiple cases are ready, the Go runtime picks one uniformly at random. This is intentional. It prevents starvation. If you have two fast senders, you will not always get the first one. The order is non-deterministic when both are ready. Relying on order in select is a bug waiting to happen.
Select multiplexes channels. It does not guarantee fairness beyond random selection. Trust the runtime to distribute load fairly.
Minimal example
Here is the simplest select loop: watch two channels, react to whichever sends first.
package main
import "fmt"
func main() {
// Create two unbuffered channels to simulate independent data sources
ch1 := make(chan string)
ch2 := make(chan string)
// Spawn a goroutine that sends to ch1 after a short delay
go func() {
ch1 <- "from ch1"
}()
// Spawn a goroutine that sends to ch2 immediately
go func() {
ch2 <- "from ch2"
}()
// select blocks until one of the cases can proceed
select {
case msg := <-ch1:
// This case runs if ch1 has a value ready to receive
fmt.Println("Got:", msg)
case msg := <-ch2:
// This case runs if ch2 has a value ready to receive
fmt.Println("Got:", msg)
}
}
The program launches two goroutines. ch2 sends immediately. ch1 sends later. The select sees ch2 is ready and picks it. The output is Got: from ch2. If you run this multiple times, you might see ch1 win if the scheduler delays ch2. The result depends on timing.
Select reacts to the first available signal. The order is unpredictable when both are ready.
Realistic pattern: timeouts and cancellation
Real code rarely just waits for two channels. You usually need a timeout or a way to cancel. Here is a pattern that combines select with time.After to implement a deadline.
package main
import (
"fmt"
"time"
)
// fetchResult returns a channel that will receive a string after a delay
func fetchResult() <-chan string {
ch := make(chan string, 1)
go func() {
// Simulate slow I/O
time.Sleep(2 * time.Second)
ch <- "data"
}()
return ch
}
func main() {
resultCh := fetchResult()
timeout := time.After(1 * time.Second)
// select chooses the first ready case; timeout fires first here
select {
case result := <-resultCh:
fmt.Println("Got:", result)
case <-timeout:
fmt.Println("Timeout")
}
}
The time.After function returns a channel that receives a value after the duration. The select waits for either the result or the timeout. Since the sleep is two seconds and the timeout is one second, the timeout case wins.
The time.After function creates a timer and a goroutine. If you call time.After inside a loop, you create a new timer and goroutine every iteration. Even if the select exits early, the timer goroutine keeps running until it fires. This leaks resources. In loops, use time.NewTimer and call timer.Reset to reuse the timer.
Time.After is convenient for one-off checks. Use NewTimer in loops to avoid leaks.
Pitfalls and edge cases
A select with no default case blocks until at least one case is ready. If no case can ever proceed, the goroutine hangs. If all goroutines in the program are blocked in select statements with no progress, the runtime panics with fatal error: all goroutines are asleep - deadlock!.
Adding a default case makes select non-blocking. If no case is ready, the default runs immediately. This turns select into a polling mechanism. Use this sparingly. Polling is usually a sign that the design should use a channel to signal readiness instead. If you put a default case inside a for loop without a sleep or wait, the loop runs as fast as the CPU allows. This burns 100% CPU and produces no work.
A channel that is nil blocks forever. You can use this to disable a case in a select. If you set a channel variable to nil, the corresponding case will never be chosen. This is a common pattern for dynamically enabling or disabling paths. Set the channel to nil to turn off a case. Restore the channel to re-enable it.
The compiler catches channel direction mismatches. If you try to send on a receive-only channel, you get cannot send to receive-only type <-chan int. Channel types enforce direction at compile time.
In production code, prefer context.Context over raw channels for cancellation. Pass ctx as the first argument to functions. Use select on ctx.Done() to respect cancellation. This integrates with the standard library's timeout and deadline machinery. The receiver name for context is conventionally ctx.
Nil channels disable cases. Default cases prevent blocking. Watch the evaluation order.
Decision matrix
Use select when you have multiple channels and need to react to whichever operation completes first.
Use a single channel receive when you are waiting for a specific event and no other concurrent path can interfere.
Use context.Context when you need to coordinate cancellation, deadlines, or request-scoped values across a call tree.
Use a mutex when you need to protect shared mutable state that multiple goroutines access simultaneously.
Use a default case when you need a non-blocking check, but be careful to avoid busy-wait loops.
Select multiplexes channels. Context manages lifecycles. Pick the tool that matches the problem.