Chapter 4: Select

4.1 Select Syntax and Semantics

The select statement looks syntactically similar to switch, but operates fundamentally differently. Where switch chooses based on values, select chooses based on which channel operation can proceed.

Basic Syntax

// Illustrative snippet — not a complete program
select {
case v := <-ch1:
    // Executes if receive from ch1 succeeds
    fmt.Println("received from ch1:", v)

case ch2 <- value:
    // Executes if send to ch2 succeeds
    fmt.Println("sent to ch2")

case v, ok := <-ch3:
    // Receive with comma-ok (detects closure)
    if !ok {
        fmt.Println("ch3 closed")
    }
}

Structure:

// Illustrative snippet — not a complete program
select {                    // select keyword (no condition)
case <-ch1:                 // Receive, discard value
case v := <-ch2:            // Receive into new variable
case v, ok := <-ch3:        // Receive with closure detection
case ch4 <- value:          // Send
default:                    // No case ready? Run this (Sec 4.3)
}

Each case must be a channel operation—send or receive. Nothing else is permitted:

// Illustrative snippet — not a complete program
// ✓ VALID: Channel operations
case v := <-ch:           // Receive
case ch <- value:         // Send
case v, ok := <-ch:       // Receive with comma-ok
case <-ch:                // Receive, discard value

// ✗ INVALID: Non-channel operations
case x > 5:               // Compile error: not a channel op
case doWork():            // Compile error: missing <- operator
case v := compute():      // Compile error: not a channel receive

How Select Executes

When execution reaches a select statement, this sequence occurs:

1. EVALUATE
   All channel expressions and send values (once, in source order)
            │
            ▼
2. WAIT FOR A READY CASE
   Which cases can proceed?
            │
   ┌────────┴────────┬──────────────┐
   ▼                 ▼              ▼
 None              One          Multiple
   │                 │              │
 [Block          [Execute     [Random pick,
  until           that case]   then execute]
  ready]*
            │
            ▼
3. EXECUTE AND EXIT
   Selected case’s statements run (other cases remain pending)
   Select completes (does not loop)

*Unless default case exists—Section 4.3

Phase 1: Evaluate All Case Expressions

Before waiting, select evaluates all channel expressions and send values once, in source order. This is critical to understand: all expressions evaluate, even for cases that won’t be selected.

package main

import "fmt"

var count int

func incrementAndReturn(n int) int {
    count++
    fmt.Printf("Call %d: count now %d\n", n, count)
    return count * 10
}

func main() {
    ch1 := make(chan int, 1)
    ch2 := make(chan int, 1)

    select {
    case ch1 <- incrementAndReturn(1):
        fmt.Println("Sent to ch1")
    case ch2 <- incrementAndReturn(2):
        fmt.Println("Sent to ch2")
    }

    fmt.Printf("Final count: %d\n", count)
}

Both incrementAndReturn(1) and incrementAndReturn(2) execute before select chooses which case to run. The “Sent to…” line varies between runs (random selection), but the final count is always 2—both expressions always evaluate.

// Illustrative snippet — not a complete program
// ✗ BAD: fetchResult executes during Phase 1—
// delays readiness check AND runs even if done fires first
// (Pseudocode—real db.Query returns (*Rows, error))
select {
case resultCh <- fetchResult("SELECT..."):
    // fetchResult runs BEFORE select checks readiness
case <-done:
    return  // Can’t fire until fetchResult finishes
}

Mitigation—compute before select:

// Illustrative snippet — not a complete program
// ✓ BETTER: Narrow the cancellation window
select {
case <-done:
    return
default:
}

// Skipped if done was already closed; still a small race window
result := fetchResult("SELECT...")
select {
case resultCh <- result:
case <-done:
    return
}

This narrows but doesn’t eliminate the window—for truly cancellation-aware operations, pass a context (Chapter 13). Most code falls into “doesn’t matter”—when computation is cheap (<100µs) and has no side effects. Don’t complicate unless profiling shows otherwise.

Phase 2: Wait for a Ready Case

After evaluation, select checks which cases can proceed:

• Receive case is ready when: sender waiting, buffered value available, or channel closed
• Send case is ready when: receiver waiting (unbuffered) or buffer has space (buffered). Note: sending to a closed channel panics—never include a closed channel in a send case

If no cases are ready: select blocks (goroutine yields CPU) until at least one becomes ready
If one case is ready: That case executes
If multiple cases are ready: One is chosen uniformly at random

Phase 3: Execute and Exit

Only the selected case’s statements run. Goroutines blocked waiting to communicate on non-selected channels remain blocked—select does not unblock them. After the selected case completes, select exits—it does not loop.

Example: Waiting on Two Channels

package main

import (
    "fmt"
    "time"
)

func main() {
    ch1 := make(chan string)
    ch2 := make(chan string)

    go func() {
        time.Sleep(100 * time.Millisecond)
        ch1 <- "from ch1"
    }()

    go func() {
        time.Sleep(50 * time.Millisecond)
        ch2 <- "from ch2"
    }()

    select {
    case msg := <-ch1:
        fmt.Println("ch1:", msg)
    case msg := <-ch2:
        fmt.Println("ch2:", msg)
    }

    fmt.Println("Select completed")
}

Timeline:

Time ─────────────────────────────────────────→
      0ms            50ms              100ms

ch2:                [ready]──────────────────
                    sender arrives

ch1:                               [ready]───
                                   sender arrives

select: [waiting]───[ch2 executes]
                     └─→ select exits

The ch2 case executes first (becomes ready at 50ms). Select completes immediately—it doesn’t wait for ch1.

To continuously handle multiple channels, wrap select in a for loop—the standard concurrent event loop in Go. Section 4.2 covers this in depth:

// Illustrative snippet — not a complete program
for {
    select {
    case task := <-tasks:
        process(task)
    case <-done:
        return  // Exit loop and function
    }
}

Random Selection When Multiple Ready

If multiple cases can proceed, select chooses one uniformly at random:

package main

import "fmt"

func main() {
    ch1 := make(chan int, 1)  // Buffered: sends don’t block
    ch2 := make(chan int, 1)

    ch1 <- 1  // Both channels have values ready
    ch2 <- 2

    select {
    case v := <-ch1:
        fmt.Println("ch1:", v)
    case v := <-ch2:
        fmt.Println("ch2:", v)
    }
}

Run it repeatedly and you get roughly half ch1 and half ch2. Over 400 runs on this machine the split was 211 / 189 — the two cases really are equally likely, which is the point of the next paragraph.

Why Not Just Pick the First Ready Case?

Random selection prevents starvation. If select always favored the first syntactic case, later cases might never execute when earlier ones are constantly ready:

// Illustrative snippet — not a complete program
for {
    select {
    case <-frequent:  // If deterministic: always wins
    case <-rare:      // This would starve
    }
}

Random selection makes starvation extremely unlikely—each ready case has an equal probability of being chosen on any given iteration. Section 4.5 covers techniques for when you need priority.

Blocking Until Ready

Without a default case (Section 4.3), select blocks until at least one case can proceed:

package main

import "fmt"

func main() {
    ch := make(chan int)

    // No sender exists—blocks forever, runtime detects deadlock
    select {
    case v := <-ch:
        fmt.Println("Received:", v)
    }
}

When blocked, Go parks the goroutine entirely—no CPU is consumed. This is fundamentally different from the busy-loop a closed channel creates (covered below).

Mixing Send and Receive Cases

A single select can include both send and receive operations:

package main

import (
    "fmt"
    "time"
)

func main() {
    in := make(chan int)
    out := make(chan int)

    go func() { in <- 42 }()
    go func() { <-out }()

    // Sleep for demo only—not reliable synchronization
    time.Sleep(10 * time.Millisecond)

    select {
    case v := <-in:
        fmt.Println("Received:", v)
    case out <- 99:
        fmt.Println("Sent: 99")
    }
}

Both cases are ready—random selection chooses which executes. As with the earlier two-channel example, the non-selected goroutine leaks. Mixed send+receive selects like this are less common—most selects are receive-only, with control channels (like done) providing shutdown signals.

Closed and Nil Channels in Select

Two channel states require special attention:

Closed channels are always ready. A receive case for a closed channel never blocks—it returns immediately. For unbuffered channels, this means the zero value with ok == false. (Buffered channels drain remaining values first—Chapter 5.)

// Illustrative snippet — not a complete program
ch := make(chan int)
close(ch)

select {
case v := <-ch:
    fmt.Println(v) // Prints 0 (ok would be false, but we never check)
}

Use comma-ok to detect closure:

// Illustrative snippet — not a complete program
select {
case v, ok := <-ch:
    if !ok {
        fmt.Println("channel closed")
        return
    }
    process(v)
}

// Illustrative snippet — not a complete program
ch := make(chan int)
close(ch)

for {
    select {
    case v := <-ch:
        fmt.Println(v)  // Prints 0 forever!
    }
}

How bad is this? Let’s measure:

package main

import (
    "fmt"
    "time"
)

func main() {
    ch := make(chan int)
    close(ch)

    count := 0
    start := time.Now()

    for time.Since(start) < time.Second {
        select {
        case <-ch:
            count++
        }
    }

    fmt.Printf("Received %d times in 1 second\n", count)
}

Tens of millions of wasted iterations per second—consuming 100% of a CPU core while accomplishing nothing useful.

Solution: Use comma-ok to detect closure and exit or set the channel to nil:

// Illustrative snippet — not a complete program
for {
    select {
    case v, ok := <-ch:
        if !ok {
            return  // Exit on closure
            // Or: ch = nil (disables case—Sec 4.6)
        }
        process(v)
    }
}

Nil channels are never ready. A case with a nil channel is ignored—never selected:

// Illustrative snippet — not a complete program
var ch chan int  // nil

select {
case v := <-ch:
    fmt.Println(v)  // Never executes
case <-time.After(time.Second):
    fmt.Println("timeout")  // This executes
}

This enables dynamic case control—Section 4.6 covers strategic use of nil channels.

Empty Select

A select with no cases blocks indefinitely:

// Illustrative snippet — not a complete program
select {}  // Blocks forever

Use case: Keep main alive for long-running goroutines:

// Illustrative snippet — not a complete program
func main() {
    go runServer()
    select {}  // Block until killed externally
}

Caveat: if runServer() returns or panics and no other goroutines remain, the runtime detects a deadlock and crashes. Production code typically blocks on a signal channel for graceful shutdown (Chapter 15), but empty select serves when you simply need “run forever until killed.”

Select Is Not Switch

Despite similar syntax, select and switch differ fundamentally:

Common Mistakes

Section Summary

Next: Section 4.2 explores multiplexing patterns—using select in loops to continuously handle multiple channels, coordinating with done channels, and managing channel closure.

4.2 Multiplexing Multiple Channels

Section 4.1 showed that select executes exactly once—it waits for one case to become ready, executes it, and exits. But real concurrent programs need to handle channel events continuously: processing tasks until shutdown, receiving from multiple producers, or coordinating long-running work.

The solution is wrapping select in a for loop—the for-select pattern. This section covers the essential multiplexing patterns you’ll use throughout your Go career.

Why For-Select?

Consider this single-use worker:

// Illustrative snippet — not a complete program
func workerOnce(tasks <-chan Task, done <-chan struct{}) {
    select {
    case task := <-tasks:
        process(task)  // Processes ONE task, then returns
    case <-done:
        return
    }
}

To handle tasks continuously, wrap select in a for loop:

// Illustrative snippet — not a complete program
func worker(tasks <-chan Task, done <-chan struct{}) {
    for {
        select {
        case task := <-tasks:
            process(task)  // Processes task, loops back
        case <-done:
            return  // Exit when signaled
        }
    }
}

Now the worker processes tasks continuously until shutdown.

       ┌────────────────────────────────────┐
       │                                    │
       ▼                                    │
    ┌──────┐    ┌───────────────┐    ┌──────┴───┐
    │ for  │───►│    select     │───►│  handle  │
    └──────┘    │  (blocking)   │    │   case   │
                └───────────────┘    └──────────┘
                                          │
                                          ▼
                                ┌──────────────────┐
                                │  return (on exit │
                                │  condition)      │
                                └──────────────────┘

Each iteration: wait → execute → repeat until exit

This pattern appears everywhere in Go: servers, workers, stream processors, coordinators.

Done Channels for Cancellation

A done channel signals goroutines to stop. The pattern: include a case <-done that exits when signaled.

// Illustrative snippet — not a complete program
// Simplified: doesn’t handle tasks closure—see below
func worker(id int, tasks <-chan Task, done <-chan struct{}) {
    for {
        select {
        case task := <-tasks:
            fmt.Printf("Worker %d: processing task\n", id)
            process(task)
        case <-done:
            fmt.Printf("Worker %d: shutdown\n", id)
            return
        }
    }
}

Why chan struct{}?

The done channel carries no data—only the signal matters:

• struct{} has zero size
• Intent is clear: “signaling, not data”
• Close (don’t send) to broadcast

Why Close Instead of Send?

Closing broadcasts to all receivers. Sending reaches only one:

// Illustrative snippet — not a complete program
// ✗ WRONG: Only one worker receives signal
done <- struct{}{}  // One worker stops, others continue

// ✓ CORRECT: All workers receive signal
close(done)  // All workers stop

Send (reaches one):
  done <- struct{}{}

  Worker 1: [receives, stops]
  Worker 2: [still running]  ← Didn’t get signal
  Worker 3: [still running]  ← Didn’t get signal

Close (broadcasts to all):
  close(done)

  Worker 1: [unblocks, stops]
  Worker 2: [unblocks, stops]
  Worker 3: [unblocks, stops]

Closing is the ONLY way to notify all goroutines at once.

Handling Channel Closure in Loops

Recall from Section 4.1 that receiving from a closed channel always succeeds with the zero value. In a for-select loop, this creates a busy loop—the closed case fires every iteration:

// Illustrative snippet — not a complete program
// ✗ CRITICAL BUG: Busy loop when channel closes
func consume(ch <-chan int) {
    for {
        select {
        case v := <-ch:
            fmt.Println(v)  // After close: 0 forever!
        }
    }
}

The closed channel returns 0 every iteration—a critical production bug with 100% CPU usage and no useful progress.

Solution: Detect Closure and Exit

Use comma-ok to detect closure:

// Illustrative snippet — not a complete program
func consume(ch <-chan int, done <-chan struct{}) {
    for {
        select {
        case v, ok := <-ch:
            if !ok {
                fmt.Println("Channel closed, exiting")
                return
            }
            fmt.Println("Received:", v)
        case <-done:
            return
        }
    }
}

When ok is false, the channel has closed—exit the loop.

Cancellable Sends with Nested Select

When a worker sends results but must also respect cancellation, use a select inside the for-select case body:

// Illustrative snippet — not a complete program
// Inside a for-select case handler:
result := process(task)

select {
case results <- result:
    // Sent successfully
case <-done:
    // Cancelled—abandon result
    return
}

Why this matters: Without the nested select, the send blocks forever if the receiver has shut down:

// Illustrative snippet — not a complete program
// ✗ PROBLEM: Goroutine leak
result := process(task)
results <- result  // Blocks forever if no receiver

WITHOUT NESTED SELECT: GOROUTINE LEAK

  Worker                        Receiver
    │                              │
    │  [processing task]           │
    │                              │
    │    ← done closes ──────────► │ exits
    │                            (gone!)
    │  result ready
    │
    ├── results <- result
    │   BLOCKS FOREVER ← goroutine leak!


WITH NESTED SELECT: CLEAN EXIT

  Worker                        Receiver
    │                              │
    │  [processing task]           │
    │                              │
    │    ← done closes ──────────► │ exits
    │                            (gone!)
    │  result ready
    │
    ├── select {
    │     case results <- ...  (blocked)
    │     case <-done:        ✓ exits!
    │   }
    ├── clean return

This pattern prevents one of the most common goroutine leaks in production Go code.

Complete Example: Worker with Graceful Shutdown

Combining patterns—for-select, done channel, closure handling, and nested select:

// Illustrative snippet — not a complete program
func worker(id int, tasks <-chan Task,
    results chan<- Result,
    done <-chan struct{}) {
    for {
        select {
        case task, ok := <-tasks:
            if !ok {
                fmt.Printf("Worker %d: tasks closed\n", id)
                return
            }

            result := process(task)

            // Nested select: respect shutdown during send
            select {
            case results <- result:
                // Sent successfully
            case <-done:
                fmt.Printf("Worker %d: cancelled\n", id)
                return
            }

        case <-done:
            fmt.Printf("Worker %d: shutdown\n", id)
            return
        }
    }
}

Key points:

• Outer select waits for task or shutdown
• Comma-ok detects task channel closure
• Inner select allows abandoning result send if shutdown occurs
• Multiple exit paths all lead to clean return
• Limitation: once process(task) starts, cancellation takes effect only after it returns. For interruptible processing, see context.Context in Chapter 13

Coordinating Shutdown with WaitGroup

Production code combines done channels with WaitGroups for clean termination. Here’s a simplified worker (without result sending) to focus on shutdown coordination:

package main

import (
    "fmt"
    "sync"
)

func main() {
    tasks := make(chan int, 10)  // Buffered: holds queued work
    done := make(chan struct{})
    var wg sync.WaitGroup

    // Start workers
    for i := 1; i <= 3; i++ {
        wg.Go(func() {
            simpleWorker(i, tasks, done)
        })
    }

    // Queue work
    for i := 1; i <= 10; i++ {
        tasks <- i
    }

    // Shutdown strategy (choose one):
    close(tasks)    // Graceful: workers drain buffer, then exit
    // close(done)  // Workers exit, remaining tasks may be lost

    wg.Wait()
    fmt.Println("All workers finished")
}

func simpleWorker(id int, tasks <-chan int, done <-chan struct{}) {
    for {
        select {
        case task, ok := <-tasks:
            if !ok {
                fmt.Printf("Worker %d: tasks closed\n", id)
                return
            }
            fmt.Printf("Worker %d: task %d\n", id, task)
        case <-done:
            fmt.Printf("Worker %d: immediate shutdown\n", id)
            return
        }
    }
}

Shutdown Strategies Comparison

Notice that the work is not shared evenly: one worker took eight of the ten tasks. Three goroutines receiving from one buffered channel do not take turns—whichever is scheduled when a value is available gets it, and a worker already running is the cheapest one to hand the next task to. Over 150 runs the busiest worker took between 2 and 9 of the 10 tasks, and a clean round-robin never occurred once. If you need even distribution, you have to build it; the channel will not give it to you.

Choose based on requirements: graceful completion vs. immediate termination.

Exiting For-Select Loops

The break statement inside select breaks only from the select, not the enclosing loop:

// Illustrative snippet — not a complete program
// ✗ WRONG: break exits select, loop continues
for {
    select {
    case task := <-tasks:
        process(task)
    case <-done:
        break  // Only exits select!
    }
}
// After done closes, loop continues forever

Demonstrating the Break Bug

This bug is subtle but severe. Let’s see what actually happens:

package main

import "fmt"

func main() {
    done := make(chan struct{})
    close(done)  // Signal “stop” immediately

    count := 0
    for {
        select {
        case <-done:
            fmt.Println("Received done signal")
            break  // Only breaks select, not for!
        }
        count++
        if count > 5 {
            fmt.Println("Loop ran 5+ times after 'break'!")
            return
        }
    }
}

The done case executes every iteration because break only exits the select, not the for loop. The loop continues indefinitely, creating a busy loop at 100% CPU.

Three Correct Approaches

Approach 1: Return (preferred when exiting function)

// Illustrative snippet — not a complete program
func worker(tasks <-chan Task, done <-chan struct{}) {
    for {
        select {
        case task := <-tasks:
            process(task)
        case <-done:
            return  // Exits function entirely
        }
    }
}

Approach 2: Labeled Break (when cleanup needed after loop)

// Illustrative snippet — not a complete program
func worker(tasks <-chan Task, done <-chan struct{}) {
loop:
    for {
        select {
        case task := <-tasks:
            process(task)
        case <-done:
            break loop  // Exits the labeled for loop
        }
    }

    cleanup()  // Runs after loop exits
}

Approach 3: Boolean Flag (for multiple exit conditions)

// Illustrative snippet — not a complete program
func worker(ch <-chan int, done <-chan struct{}) {
    count := 0
    running := true

    for running {
        select {
        case v, ok := <-ch:
            if !ok {
                running = false
                break  // leaves the select, not the loop —
                       // the flag above is what ends it
            }
            count++
            process(v)
            if count >= 100 {
                running = false
            }
        case <-done:
            running = false
        }
    }

    fmt.Printf("Processed %d items\n", count)
}

Recommendation: Use return when possible—it’s the clearest. Use labeled break when cleanup code must run after the loop. Avoid boolean flags unless you have genuinely complex exit conditions—they add state that can obscure the actual exit logic.

When to Use Each Pattern

When for range is sufficient:

// Illustrative snippet — not a complete program
// ✓ Good: No cancellation needed
func processAll(jobs <-chan int) {
    for job := range jobs {  // Exits when jobs closes
        process(job)
    }
}

When for-select is required:

// Illustrative snippet — not a complete program
// ✓ Required: Need cancellation
func processUntilDone(jobs <-chan int, done <-chan struct{}) {
    for {
        select {
        case job, ok := <-jobs:
            if !ok {
                return
            }
            process(job)
        case <-done:
            return  // Exit before jobs closes
        }
    }
}

Common Mistakes

Section Summary

Next: Section 4.3 covers non-blocking operations—using the default case to poll channels without blocking, when this is useful, and the critical warning about CPU-spinning loops.

4.3 Non-Blocking Operations: The Default Case

Sections 4.1 and 4.2 showed select blocking until at least one case is ready. But sometimes you need to check a channel without committing to wait—poll once and move on if nothing is available.

The default case enables this: it executes when no other case is ready, making select non-blocking.

// Illustrative snippet — not a complete program
select {
case v := <-ch:
    fmt.Println("received:", v)
default:
    fmt.Println("no value ready")
}

If ch has a value, the receive executes. If not, default executes immediately—no blocking.

Execution Rules

How select evaluates when default is present:

1. Evaluate all channel expressions (same as Section 4.1)
2. Check which cases are ready
3. If any case is ready: Select one randomly, execute it (default ignored)
4. If NO case is ready: Execute default immediately

Without default:

  select {              No case ready?
  case <-ch1: ...       → BLOCK until one becomes ready
  case <-ch2: ...          (goroutine yields CPU)
  }

With default:

  select {              No case ready?
  case <-ch1: ...       → Execute default immediately
  case <-ch2: ...          (no blocking, no waiting)
  default: ...
  }

Default makes select NON-BLOCKING.

Non-Blocking Receive (Try-Receive)

Check if a channel has a value without waiting:

// Illustrative snippet — not a complete program
func tryReceive(ch <-chan int) (int, bool) {
    select {
    case v := <-ch:
        return v, true   // Got value
    default:
        return 0, false  // No value ready
    }
}

// Usage
if value, ok := tryReceive(ch); ok {
    process(value)
} else {
    // No value right now—do something else
}

Note: If the channel is closed, case v := <-ch fires immediately with the zero value—so tryReceive returns (0, true), indistinguishable from receiving a real zero. To detect closure, use v, ok := <-ch inside the case and check ok.

Use cases:

• Check for cancellation before starting expensive work
• Drain a channel of pending values
• Poll for optional updates

Complete example: periodic cancellation check

// Illustrative snippet — not a complete program
func processLargeDataset(data []Item, done <-chan struct{}) error {
    for i, item := range data {
        // Check cancellation every 100 items
        if i%100 == 0 {
            select {
            case <-done:
                return errors.New("cancelled")
            default:
                // Not cancelled, continue
            }
        }

        process(item)
    }
    return nil
}

This checks once per batch—not in a tight loop—then proceeds based on the result. Note that this is a point-in-time snapshot: cancellation that arrives during process(item) won’t be caught until the next check. For truly cancellation-aware operations, pass a context.Context (Chapter 13).

Non-Blocking Send (Try-Send)

Attempt to send without blocking if no receiver is ready:

// Illustrative snippet — not a complete program
func trySend(ch chan<- int, value int) bool {
    select {
    case ch <- value:
        return true   // Sent successfully
    default:
        return false  // Would block
    }
}

// Usage
if trySend(results, result) {
    // Delivered
} else {
    // Receiver not ready
}

Example of acceptable dropping:

// Illustrative snippet — not a complete program
// Debug/metrics—dropping is fine under load
func recordMetric(metrics chan<- Metric, m Metric) {
    select {
    case metrics <- m:
    default:
        // Collector backed up—drop this point
    }
}

Example where dropping is WRONG:

// Illustrative snippet — not a complete program
// ✗ NEVER do this with critical data
func saveOrder(orders chan<- Order, o Order) {
    select {
    case orders <- o:
    default:
        // Customer’s order just disappeared!
    }
}

For critical data, use buffered channels (Chapter 5) or blocking sends with timeouts (Section 4.4) instead.

The CPU-Spinning Trap

This is where default becomes dangerous. Consider this seemingly reasonable code:

// Illustrative snippet — not a complete program
// ✗ CATASTROPHIC BUG: 100% CPU doing nothing
func worker(tasks <-chan Task, done <-chan struct{}) {
    for {
        select {
        case task := <-tasks:
            process(task)
        case <-done:
            return
        default:
            // “Keep checking for work”
        }
    }
}

What actually happens: Each iteration, neither tasks nor done is ready, so default runs—and the loop immediately retries. Millions of times per second, at maximum CPU speed, accomplishing nothing.

This is a busy loop—the goroutine consumes 100% of a CPU core checking channels that are empty, accomplishing no useful work.

CPU Usage
  100% ████████████████████████████████████████████
    │   ████████████████████████████████████████████
    │   ████████ DOING NOTHING USEFUL ████████████
    │   ████████████████████████████████████████████
    └──────────────────────────────────────────────
        Time →

The goroutine spins at maximum speed, consuming an
entire CPU core while accomplishing nothing. One of
the worst bugs you can introduce in production Go.

Demonstrating the Problem

Here’s code that shows how fast the spinning occurs:

package main

import (
    "fmt"
    "time"
)

// ⚠️ DEMONSTRATION ONLY—DO NOT USE IN PRODUCTION
// This intentionally creates a CPU-spinning loop
func main() {
    ch := make(chan int)
    count := 0
    start := time.Now()

    // Spin for 1 second
    for time.Since(start) < time.Second {
        select {
        case <-ch:
            // Never executes
        default:
            count++
        }
    }

    fmt.Printf("Spun %d times in 1 second\n", count)
}

Tens of millions of empty checks every second—all wasted CPU cycles. The exact count varies by hardware, but the result is always the same: an entire core burning for nothing.

The Fix: Remove Default

The correct pattern is to let select block:

// Illustrative snippet — not a complete program
// ✓ CORRECT: Blocks until work arrives
func worker(tasks <-chan Task, done <-chan struct{}) {
    for {
        select {
        case task := <-tasks:
            process(task)
        case <-done:
            return
        }
        // No default—blocks until ready
    }
}

Blocking is the correct, efficient behavior.

When Default IS Appropriate

Despite the danger, default has legitimate uses. The key distinction: single check vs. continuous loop.

Pattern 1: One-Time Non-Blocking Check

Check channel state once, then proceed:

// Illustrative snippet — not a complete program
func checkForShutdown(done <-chan struct{}) bool {
    select {
    case <-done:
        return true
    default:
        return false
    }
}

// Usage: check before expensive work
func process(done <-chan struct{}) error {
    if checkForShutdown(done) {
        return errors.New("already cancelled")
    }

    return expensiveComputation()
}

This catches cancellation that has already happened. If you need to detect cancellation during the computation, use the periodic check pattern above or pass a context.Context (Chapter 13).

Pattern 2: Draining a Channel

Remove all pending values without blocking:

// Illustrative snippet — not a complete program
func drain(ch <-chan int) []int {
    var values []int
    for {
        select {
        case v, ok := <-ch:
            if !ok {
                return values  // Channel closed
            }
            values = append(values, v)
        default:
            return values  // Nothing buffered—stop
        }
    }
}

This loops with default, but exits immediately via return when the buffer is empty or the channel is closed. The comma-ok check is critical—without it, a closed channel returns zero values instantly on every iteration, causing an infinite loop (closed channels are always ready—Section 4.1).

Works correctly for:

• Buffered channels: drains buffer until empty
• Closed channels: drains remaining buffered values, then detects closure via comma-ok
• Channels where senders have finished (but channel is still open)

Does NOT work for:

• Unbuffered channels with active senders (no buffer to drain—values arrive one at a time)
• Channels that continue receiving values indefinitely

Pattern 3: Try-Send for Optional Notifications

Send if someone is listening, skip if not:

// Illustrative snippet — not a complete program
func notifyProgress(progress chan<- int, percent int) {
    select {
    case progress <- percent:
        // Listener received update
    default:
        // Channel not ready—skip
    }
}

Progress updates are optional—if no one is listening, we don’t want to block.

Dropping a notification when nobody is listening is the mildest form of backpressure: the producer refuses to slow down and sheds the excess instead. That is the right call for progress updates and metrics, and the wrong one for work you must not lose. Chapter 17 takes the trade-off seriously—rate limiting, load shedding, and how to choose between dropping, blocking, and buffering.

When NOT to Use Default

Antipattern: Polling with Sleep

// Illustrative snippet — not a complete program
// ✗ WASTEFUL: Polling every 100ms
for {
    select {
    case v := <-ch:
        process(v)
    case <-done:
        return
    default:
        time.Sleep(100 * time.Millisecond)
    }
}

Why this is wasteful:

• Value arrives at time T
• Default executes at time T, sleeps until T+100ms
• Value sits in channel unprocessed for up to 100ms
• Adds unnecessary latency

Better: use ticker for periodic work:

// Illustrative snippet — not a complete program
// ✓ CORRECT: Blocking select with ticker
ticker := time.NewTicker(100 * time.Millisecond)
defer ticker.Stop()

for {
    select {
    case v := <-ch:
        process(v)  // Instant response
    case <-ticker.C:
        doPeriodicWork()
    case <-done:
        return
    }
}

If you just need to wait for channel values (no periodic work), the fix is even simpler: remove default entirely and let select block. The ticker is only necessary when you genuinely need periodic actions alongside channel operations.

Antipattern: Using Default to “Avoid Deadlock”

// Illustrative snippet — not a complete program
// ✗ WRONG: Silently drops data
select {
case ch <- value:
    // sent
default:
    // “Prevents deadlock”—but loses data!
}

If you’re adding default to prevent deadlock, you have a design problem. The deadlock was a symptom—default masks it without solving the underlying issue. Fix the design—ensure receivers exist, use buffering, or apply backpressure—don’t silently discard data.

Default with Closed and Nil Channels

Closed channels are always ready (Section 4.1), so the receive case executes, not default:

// Illustrative snippet — not a complete program
ch := make(chan int)
close(ch)

select {
case v := <-ch:
    fmt.Println("Received:", v)  // Runs (v = 0)
default:
    fmt.Println("Not ready")     // Never runs
}

Use comma-ok to distinguish closed from data:

// Illustrative snippet — not a complete program
select {
case v, ok := <-ch:
    if !ok {
        fmt.Println("Channel closed")
    } else {
        fmt.Println("Received:", v)
    }
default:
    fmt.Println("Channel not ready")
}

Nil channels are ignored (Section 4.1). If all channel cases involve nil channels, default executes:

// Illustrative snippet — not a complete program
var ch chan int  // nil

select {
case v := <-ch:
    fmt.Println(v)       // Never—nil ignored
default:
    fmt.Println("default")  // Always executes
}

Decision Guide

Question 1: Is this in a loop?
             │
      ┌──────┴──────┐
      ▼             ▼
     Yes           No
      │             │
      │             ▼
      │             OK
      │       (try-send, try-receive,
      │        one-time checks)
      │
      ▼
Question 2: Does default exit immediately?
             │
      ┌──────┴──────┐
      ▼             ▼
     Yes           No
      │             │
      ▼             ▼
   OK (drain    DON’T USE
   pattern—    (infinite
   returns)     CPU spin!)

When in doubt: DON’T use default.
Blocking is almost always correct.

Practical Example: Async Logger

A legitimate use combining patterns—non-blocking send with bounded buffer:

// Illustrative snippet — not a complete program
import (
    "fmt"
    "io"
    "sync"
)

type AsyncLogger struct {
    out  io.Writer
    logs chan string
    done chan struct{}
    wg   sync.WaitGroup
}

func NewAsyncLogger(out io.Writer, bufSize int) *AsyncLogger {
    l := &AsyncLogger{
        out:  out,
        logs: make(chan string, bufSize),
        done: make(chan struct{}),
    }
    l.wg.Add(1)
    go l.run()
    return l
}

func (l *AsyncLogger) Log(msg string) {
    select {
    case l.logs <- msg:
        // Queued for async writing
    default:
        // Buffer full—drop, don’t block caller
    }
}

func (l *AsyncLogger) run() {
    defer l.wg.Done()
    for {
        select {
        case msg := <-l.logs:
            fmt.Fprintln(l.out, msg)
        case <-l.done:
            l.drainAndExit()
            return
        }
    }
}

func (l *AsyncLogger) drainAndExit() {
    for {
        select {
        case msg := <-l.logs:
            fmt.Fprintln(l.out, msg)
        default:
            return  // Buffer empty, exit
        }
    }
}

// Close signals shutdown and waits for all
// buffered messages to be written.
func (l *AsyncLogger) Close() {
    close(l.done)
    l.wg.Wait()  // Block until drain completes
}

Design points:

• Log() uses non-blocking send—callers never block on slow I/O
• Main loop has no default—blocks efficiently waiting for logs
• Shutdown drain uses default to detect empty buffer and exit (bounded operation)
• Close() waits for the goroutine via sync.WaitGroup—no buffered messages are lost
• Caveat: Calling Log() after Close() silently drops messages. A production version would guard with a sync.Mutex or atomic.Bool to reject late writes

Common Mistakes

Section Summary

Next: Section 4.4 covers timeout patterns—using time.After() and time.NewTimer() to implement deadlines correctly, avoiding timer leaks, and choosing the right timeout mechanism.

4.4 Timeouts: time.After() and time.NewTimer()

Sections 4.1–4.3 showed how to multiplex channel operations—waiting on multiple channels, handling shutdown, and performing non-blocking checks. But one critical question remains: how long should you wait?

Without timeout:
  result := <-slowOperation()
  // Blocks forever if operation hangs
  // Goroutine leaks, resources locked, system stalls

With timeout:
  select {
  case result := <-slowOperation():
      // Got result
  case <-time.After(5 * time.Second):
      // Gave up—can clean up, retry, or report error
  }

Timeouts convert “wait forever” into “bounded wait.”

Unbounded waits create unresponsive systems. A slow database query shouldn’t block your service indefinitely. A disappeared client shouldn’t leak a goroutine forever. Timeouts are essential for:

• API calls: Don’t wait forever for a slow backend
• User requests: Respond within acceptable latency
• Resource acquisition: Don’t hold connections indefinitely
• Graceful shutdown: Give workers time to finish, then force stop

Go’s time package provides four mechanisms for timeouts and periodic events in select:

• time.After(duration)—Simple one-shot timeout; leaks memory in loops on Go ≤ 1.22
• time.NewTimer(duration)—Stoppable, resettable; preferred for loops
• time.NewTicker(duration)—Automatic repeated firing at regular intervals
• time.AfterFunc(duration, f)—Callback-based; runs f in a new goroutine after delay

This section covers all four, with special emphasis on the timer leak trap that catches most Go developers at least once.

time.After(): Simple Timeouts

time.After(d) returns a channel that receives the current time after duration d elapses:

// Illustrative snippet — not a complete program
func After(d time.Duration) <-chan time.Time

Minimal example:

// Illustrative snippet — not a complete program
// computeResult() returns a channel immediately;
// the actual work runs in a separate goroutine.
select {
case result := <-computeResult():
    fmt.Println("Got result:", result)
case <-time.After(3 * time.Second):
    fmt.Println("Computation took too long")
}

If computeResult() completes within 3 seconds, we get the result. Otherwise, we time out.

Time ──────────────────────────────────────────────────→
     0s                              3s

Case 1: Work completes before timeout
  result: ──────[arrives]─────→
  timeout:                     ────────[3s]──────→
                                       (ignored)
  Outcome: Got result

Case 2: Work exceeds timeout
  result: ─────────────────────────────[still working...]
  timeout:                     ────────[3s]─────→
                                       (fires)
  Outcome: Timeout after 3 seconds

Whichever becomes ready first executes; the other is ignored.

Complete Example

// Illustrative snippet — not a complete program
func fetchWithTimeout(url string) (string, error) {
    result := make(chan string, 1)  // Buffered

    go func() {
        data := fetch(url)
        result <- data
    }()

    select {
    case data := <-result:
        return data, nil
    case <-time.After(5 * time.Second):
        return "", errors.New("request timeout")
    }
}

The Trap: time.After() in Loops Leaked Memory (Go ≤ 1.22)

Consider this seemingly reasonable code:

// Illustrative snippet — not a complete program
// ✗ Go ≤ 1.22: memory leak. 1.23+: churn, not a leak
for {
    select {
    case msg := <-messages:
        process(msg)
    case <-time.After(1 * time.Minute):
        fmt.Println("No message for 1 minute")
    }
}

What happens (on Go ≤ 1.22):

1. Iteration 1: Creates Timer1 (expires in 60s). Message arrives at 1s → select returns, but Timer1 is still waiting.
2. Iteration 2: Creates Timer2 (expires in 60s). Message arrives at 2s → Timer1 and Timer2 both still waiting.
3. After 1,000 iterations: 1,000 abandoned timers sitting in the runtime’s timer heap, consuming memory until they eventually fire.

Each abandoned timer remains in the runtime’s timer heap, consuming memory until it eventually fires.

Memory
  ▲
  │                     ╱╱╱╱╱╱╱╱╱╱
  │                ╱╱╱╱╱
  │           ╱╱╱╱╱          Thousands of
  │      ╱╱╱╱╱               abandoned timers
  │  ╱╱╱╱                    accumulating
  │╱╱
  └─────────────────────────────────────→ Time

Each loop iteration creates a timer.
If messages arrive before timeout, timers never fire.
They accumulate in memory—gradual leak.

When Do Timers Get Garbage Collected?

On Go ≤ 1.22, a timer is garbage collected when:

1. It fires (sends to its channel), AND
2. No references to the Timer object remain

In the leak scenario, timers are created but select returns before they fire. They’re still in the runtime timer heap. They fire eventually (after 60s in the example), then get garbage collected. But meanwhile, thousands accumulate.

On Go 1.23+, unreferenced timers are collected immediately—so this accumulation no longer occurs. However, the per-iteration allocation overhead remains, and time.NewTimer() with Reset() is still the more efficient pattern.

Production Impact

The bug in production:

// Illustrative snippet — not a complete program
// ✗ THE BUG (Go ≤ 1.22)
for {
    select {
    case req := <-requests:
        handleRequest(req)
    case <-time.After(30 * time.Second):
        checkIdleTimeout()
    }
}

Impact calculation (Go ≤ 1.22):

• 1,000 timers created per second
• Each lives for 30 seconds (even though requests complete in 50ms)
• Steady state: ~30,000 concurrent timers in memory
• Each timer: ~250 bytes overhead (approximate; varies by platform)
• Memory: ~7.5 MB of steady-state overhead from abandoned timers
• GC pressure from scanning a timer heap with 30,000 entries
• 86,400,000 total timer allocations per day—significant GC churn

Typical symptoms: elevated GC pause times, increased memory footprint, and degraded tail latency under load. With longer timeouts (e.g., 5 minutes at 10K req/s), the steady-state count reaches millions of concurrent timers.

Always use time.NewTimer() in loops—even on Go 1.23+, it avoids per-iteration allocation overhead.

time.NewTimer(): The Correct Solution for Loops

time.NewTimer() creates a timer you can stop and reset:

// Illustrative snippet — not a complete program
timer := time.NewTimer(5 * time.Second)

// Later:
timer.Stop()                    // Cancel the timer
timer.Reset(10 * time.Second)   // Restart with new duration

The Timer type:

// Illustrative snippet — not a complete program
type Timer struct {
    C <-chan time.Time  // Receives when timer fires
}

func (t *Timer) Stop() bool
func (t *Timer) Reset(d Duration) bool

Understanding Stop() Return Values

On Go 1.23+, Stop() returns false in exactly two cases, and in neither of them is there anything to drain:

• The value was already received from timer.C
• The timer was already stopped

A timer that has fired but whose value nobody took still returns true—it is stoppable, and the value is gone. That is the case people most often expect to be false, and it is the one Go 1.23 changed.

On Go ≤ 1.22 the first case was different: a fired-but-unreceived timer returned false and left its value parked in the buffered channel, where it had to be drained before Reset(). A timer that was merely already stopped returned false with an empty channel—so draining unconditionally would block forever. Telling those two falses apart is the entire reason the drain was written as a non-blocking select with a default.

Correct Loop Pattern

// Illustrative snippet — not a complete program
// ✓ CORRECT (Go 1.23+): one timer, reused each iteration
func processMessages(messages <-chan Message, done <-chan struct{}) {
    timer := time.NewTimer(1 * time.Minute)
    defer timer.Stop()

    for {
        select {
        case msg := <-messages:
            process(msg)

            // Go 1.23+: stop, then reset. No drain needed —
            // see “The Drain, and Why Go 1.23 Retired It”.
            timer.Stop()
            timer.Reset(1 * time.Minute)

        case <-timer.C:
            fmt.Println("No message for 1 minute")
            // already fired and received — just reset
            timer.Reset(1 * time.Minute)

        case <-done:
            return
        }
    }
}

How this works:

• Create timer once before loop
• When a message arrives: stop the timer, then reset it for the next iteration—no drain on Go 1.23+
• When timer fires: handle timeout, reset
• Only one timer object exists throughout

The Drain, and Why Go 1.23 Retired It

On the toolchain this book targets, the stop-drain-reset dance is no longer required: timer.Stop() followed by timer.Reset(d) is correct and complete. The pattern is worth understanding anyway, because you will meet it in every codebase written before Go 1.23 and in any module that still has to build on one.

What it defended against was a real bug—spurious timeouts. Here is the code that produced it:

// Illustrative snippet — not a complete program
// ✗ WITHOUT drain: spurious timeout — on Go ≤ 1.22 only.
// On Go 1.23+ this function waits the full 100ms.
func demonstrateSpuriousTimeout() {
    timer := time.NewTimer(100 * time.Millisecond)
    time.Sleep(200 * time.Millisecond)

    timer.Stop()  // ≤1.22: false. 1.23+: true
    timer.Reset(100 * time.Millisecond)

    // ≤1.22 only: old value still in timer.C
    select {
    case <-timer.C:
        // ≤1.22: fires at once on the stale value
        fmt.Println("Spurious timeout!")
    }
}

What happened, on Go ≤ 1.22:

1. Timer created for 100ms
2. We sleep for 200ms—timer fires at 100ms, and because timer channels were buffered, the value sits in timer.C
3. Stop() returns false: already fired
4. Reset() reschedules the timer for 100ms from now
5. But the old value is still in timer.C
6. Select immediately receives the stale value—spurious timeout

What happens on Go 1.23+:

1. Steps 1–2 are the same, except the channel is now unbuffered, so the fired value was never parked anywhere—nothing received it
2. Stop() returns true. This is the step most often misremembered: a timer whose value nobody took is still stoppable. Stop returns false only when the value was actually received, or when the timer was already stopped
3. Reset() reschedules as before
4. There is no stale value to receive, so the select waits the full 100ms—the correct behavior, with no drain

The fix—drain before reset:

// Illustrative snippet — not a complete program
// ✓ WITH drain: Clean reset
if !timer.Stop() {
    select {
    case <-timer.C:  // Remove stale value
    default:         // Don’t block if drained
    }
}
timer.Reset(100 * time.Millisecond)

Simpler Alternative (Lower Throughput)

For simpler code when allocation overhead isn’t a concern. Prefer the Reset() pattern above for production loops.

// Illustrative snippet — not a complete program
for {
    timer := time.NewTimer(timeout)

    select {
    case msg := <-messages:
        timer.Stop()  // Prevent leak
        process(msg)
    case <-timer.C:
        handleTimeout()
    case <-done:
        timer.Stop()
        return
    }
}

Simpler than Reset() but allocates a new timer each iteration. Use Reset() for high-throughput loops.

When time.After() IS Acceptable

Even on Go ≤ 1.22 where the leak was real, time.After() is appropriate in several cases:

Case 1: Single Timeout (Not in Loop)

// Illustrative snippet — not a complete program
// ✓ GOOD: One-time timeout
select {
case result := <-doWork():
    return result
case <-time.After(5 * time.Second):
    return errors.New("timeout")
}

This executes once. The timer fires or the work completes—either way, no leak.

Case 2: The Timeout Fires Most of the Time

// Illustrative snippet — not a complete program
// ✓ ACCEPTABLE: Timeout fires regularly
for {
    select {
    case msg := <-infrequentMessages:
        handle(msg)  // Rare—once per minute
    case <-time.After(10 * time.Second):
        checkSystemHealth()
    }
}

If events arrive less frequently than the timeout, most iterations execute the timeout case. Timers fire and are cleaned up—minimal accumulation.

Bounded-overhead rule: time.After() has bounded overhead when the timeout fires more often than events arrive. The maximum concurrent timer count is approximately event_rate × timeout_duration.

• Events every 30s, timeout 10s → Bounded (at most 1–2 abandoned timers)
• Events every 1s, timeout 10s → Leak (on Go ≤ 1.22: ~10 concurrent timers per period)

Simple rule: Unless you can clearly articulate why time.After() is safe in your specific case (one-shot usage, or timeout fires more often than events), use time.NewTimer() with defer timer.Stop(). Short durations reduce the accumulation window but don’t eliminate it—safety depends on the event-to-timeout ratio, not the absolute duration.

time.NewTicker(): For Periodic Events

Timers fire once. For periodic events, use time.NewTicker():

// Illustrative snippet — not a complete program
ticker := time.NewTicker(1 * time.Second)
defer ticker.Stop()

for {
    select {
    case <-ticker.C:
        doPeriodicWork()
    case <-done:
        return
    }
}

Ticker vs Timer:

Common mistake: Using Timer with manual reset for periodic work:

// Illustrative snippet — not a complete program
// ✗ COMPLEX: Manual reset for periodic work
// (simplified—real code needs done channel and defer Stop())
timer := time.NewTimer(interval)
for {
    select {
    case <-timer.C:
        doWork()
        timer.Reset(interval)
    }
}

// ✓ SIMPLER: Use Ticker
ticker := time.NewTicker(interval)
defer ticker.Stop()
for {
    select {
    case <-ticker.C:
        doWork()  // Automatic periodic firing
    }
}

Timer Mechanism Decision Table

Timeout Doesn’t Cancel Work

// Illustrative snippet — not a complete program
select {
case result := <-doWork():
    return result
case <-time.After(5 * time.Second):
    return errors.New("timeout")
    // doWork() goroutine is STILL RUNNING
}

What you might expect:
  Caller: “timeout!” → Worker: “stopping...”  ✗ WRONG

What actually happens:
  Caller: “timeout!” → Caller moves on
  Worker: [still running] → [still running] → [finishes]

The worker has NO IDEA the caller timed out.
It continues consuming CPU, memory, network, database...

Timeouts bound WAIT time, not WORK time.
For actual cancellation: context.Context (Chapter 13)

Time ─────────────────────────────────────────────────→
     0s        2s         5s                    10s
      │         │          │                      │
Caller│─────────┼──────────│
      │ waiting │ TIMEOUT! │
      │         │ returns  │
      │         ▼          │
      │    [caller done]   │
      │                    │                      │
Worker│════════════════════╪══════════════════════│
      │    still working   │   still working...   │ done
      │                    │   (wasted work)      │

The timeout unblocks the caller but doesn’t stop the worker.

For actual cancellation, you need cooperative cancellation with done channels or context.Context (Chapter 13).

// Illustrative snippet — not a complete program
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

result, err := doWork(ctx)  // Checks ctx.Done()

Pattern: First Response Wins with Timeout

Query multiple sources, use first response or timeout:

// Illustrative snippet — not a complete program
func queryFastest(
    endpoints []string,
    timeout time.Duration,
) (Response, error) {
    responses := make(chan Response, len(endpoints))

    for _, endpoint := range endpoints {
        go func() {
            resp := query(endpoint)
            responses <- resp
        }()
    }

    timer := time.NewTimer(timeout)
    defer timer.Stop()

    select {
    case resp := <-responses:
        return resp, nil
    case <-timer.C:
        return Response{}, errors.New("all timed out")
    }
}

Endpoint A ────[150ms]────→ response ──→ sent to buffer

Endpoint B ────[80ms]──→ response ──→ WINNER (returned)

Endpoint C ────[200ms]──────────→ response ──→ to buffer

Select returns at 80ms with B’s response.
A and C complete later, send to buffer (not received).
Buffered channel prevents goroutine leak.

Pattern: Timeout with Cancellation

Combine timeout with done channel for full control:

// Illustrative snippet — not a complete program
func fetchWithTimeoutAndCancel(
    url string,
    timeout time.Duration,
    done <-chan struct{},
) ([]byte, error) {

    result := make(chan []byte, 1)
    errCh := make(chan error, 1)

    go func() {
        data, err := fetch(url)
        if err != nil {
            errCh <- err
            return
        }
        result <- data
    }()

    timer := time.NewTimer(timeout)
    defer timer.Stop()

    select {
    case data := <-result:
        return data, nil
    case err := <-errCh:
        return nil, err
    case <-timer.C:
        return nil, fmt.Errorf("timeout after %v", timeout)
    case <-done:
        return nil, errors.New("cancelled")
    }
}

Four exit conditions: success, error, timeout, or explicit cancellation.

Pattern: Inactivity Timeout

Reset the timer on each event—timeout only after period of inactivity:

// Illustrative snippet — not a complete program
func monitorActivity(events <-chan Event, done <-chan struct{}) {
    inactivity := 30 * time.Second
    timer := time.NewTimer(inactivity)
    defer timer.Stop()

    for {
        select {
        case event := <-events:
            handleEvent(event)

            // Reset inactivity timer
            // Go 1.23+: stop, then reset. No drain needed —
            // see “The Drain, and Why Go 1.23 Retired It”.
            timer.Stop()
            timer.Reset(inactivity)

        case <-timer.C:
            fmt.Println("No activity for 30s")
            return

        case <-done:
            return
        }
    }
}

Use cases:

• Connection keepalive—close if no data for N seconds
• User session timeout—logout after inactivity
• Watchdog—restart if no heartbeat received

Pattern: Overall Operation Deadline

Set a deadline for entire operation, not per step:

// Illustrative snippet — not a complete program
func processAll(
    items <-chan Item,
    maxDuration time.Duration,
) error {
    deadline := time.NewTimer(maxDuration)
    defer deadline.Stop()

    for {
        select {
        case item, ok := <-items:
            if !ok {
                return nil  // Channel closed
            }
            process(item)

        case <-deadline.C:
            return fmt.Errorf("exceeded %v deadline", maxDuration)
        }
    }
}

The timer runs continuously—no reset needed. If processing takes too long overall, the deadline fires.

Pattern: Heartbeat with Health Monitoring

Workers send periodic “I’m alive” signals. Supervisors monitor them and take action if workers become unresponsive:

// Illustrative snippet — not a complete program
// Worker side: sends periodic heartbeats
func workerWithHeartbeat(
    tasks <-chan Task,
    heartbeat chan<- time.Time,
    done <-chan struct{},
) {
    ticker := time.NewTicker(500 * time.Millisecond)
    defer ticker.Stop()

    for {
        select {
        case task := <-tasks:
            process(task)

        case t := <-ticker.C:
            // Non-blocking heartbeat send
            select {
            case heartbeat <- t:
            default:
            }

        case <-done:
            return
        }
    }
}

// Supervisor side: monitors worker health
func supervisor(
    heartbeat <-chan time.Time,
    shutdown chan<- struct{},  // close to signal worker to stop
) {
    timeout := 2 * time.Second
    timer := time.NewTimer(timeout)
    defer timer.Stop()

    for {
        select {
        case <-heartbeat:
            // Worker alive—reset watchdog
            // Go 1.23+: stop, then reset. No drain needed —
            // see “The Drain, and Why Go 1.23 Retired It”.
            timer.Stop()
            timer.Reset(timeout)

        case <-timer.C:
            // No heartbeat—worker unresponsive
            log.Println("Worker unresponsive")
            close(shutdown)  // close is valid on send-only channels
            return
        }
    }
}

Why this pattern matters:

• Detect hung workers (stuck in infinite loop, deadlocked, waiting on I/O forever)
• Used in production for watchdog timers, health checks, distributed systems

When to use:

• Long-running workers with many short tasks (heartbeats fire between tasks)
• Distributed systems health monitoring
• Any scenario where you need to detect and recover from worker failure

When NOT needed:

• Simple request-response patterns (timeout on the request itself is sufficient)
• Short-lived goroutines that complete quickly

time.AfterFunc(): Callback-Based Timeouts

For triggering an action after a delay without blocking:

// Illustrative snippet — not a complete program
func startOperationWithDeadline(op Operation, deadline time.Duration) {
    done := make(chan struct{})

    // After deadline, signal cancellation
    timer := time.AfterFunc(deadline, func() {
        fmt.Println("Deadline exceeded")
        close(done)
    })
    defer timer.Stop()

    result := op.Run(done)
    handleResult(result)
}

AfterFunc runs the callback in its own goroutine when the timer fires. Unlike After(), you can stop it before it fires with timer.Stop().

// Illustrative snippet — not a complete program
var once sync.Once

timer := time.AfterFunc(deadline, func() {
    // ⚠️ Runs in a NEW goroutine
    // Use sync.Once to prevent double-close panic
    once.Do(func() { close(done) })
})

When to use AfterFunc vs select with timer:

Comparing time.After() vs time.NewTimer()

Common Mistakes

Section Summary

Next: Section 4.5 covers random selection behavior—what happens when multiple cases are ready simultaneously, why Go chooses randomly, and patterns for when you need priority or fairness.

4.5 Random Selection and Priority Patterns

Section 4.1 mentioned that when multiple select cases are ready simultaneously, Go chooses one uniformly at random. This isn’t an implementation detail—it’s a deliberate design decision with important implications.

This section explores why Go uses random selection, when it causes problems, and patterns for implementing priority when you need it.

Random Selection in Action

When multiple cases can proceed, Go selects uniformly at random:

// Illustrative snippet — not a complete program
func demonstrateRandomness() {
    ch1 := make(chan int, 100)
    ch2 := make(chan int, 100)

    // Fill both channels—both always ready
    // 100 iterations so count equals percentage
    for i := 0; i < 100; i++ {
        ch1 <- i
        ch2 <- i
    }

    ch1Count := 0
    ch2Count := 0

    for i := 0; i < 100; i++ {
        select {
        case <-ch1:
            ch1Count++
        case <-ch2:
            ch2Count++
        }
    }

    fmt.Printf("ch1: %d selections (%d%%)\n",
        ch1Count, ch1Count)
    fmt.Printf("ch2: %d selections (%d%%)\n",
        ch2Count, ch2Count)
}

Both cases are ready every iteration. Over 100 iterations, each gets roughly 50%—the distribution is uniform. Case order in source code does not affect selection.

  select {
      case <-ch1:  ──┐
      case <-ch2:  ──┼── All ready? Random pick
      case <-ch3:  ──┘
  }

  If ch1, ch2, ch3 all have values:
    • NOT "first case wins"
    • NOT "last case wins"
    • Each has ~33% chance of being selected

  This is by design—it prevents starvation.
          

Why Random Selection?

Go’s random selection prevents starvation—a situation where one channel never gets serviced because another is always chosen first.

  If select favored first syntactic case (hypothetical):

    select {
    case msg := <-highVolume:   // Always has data
        process(msg)            // Always chosen!
    case <-done:                // Never checked
        return                  // STARVATION
    }

  With random selection (actual Go):

    select {
    case msg := <-highVolume:   // 50% when both ready
        process(msg)
    case <-done:                // 50% when both ready
        return                  // Gets fair chance
    }

  Random selection ensures ALL ready cases get serviced.
          

Fairness Across Producers

Consider aggregating data from multiple sources:

// Illustrative snippet — not a complete program
func aggregate(source1, source2, source3 <-chan Data) <-chan Data {
    out := make(chan Data)

    go func() {
        defer close(out)

        for {
            select {
            case d := <-source1:
                out <- d
            case d := <-source2:
                out <- d
            case d := <-source3:
                out <- d
            }
        }
    }()

    return out
}

If all three sources produce data continuously, random selection ensures each gets approximately equal representation in the output—no source starves.

Real-World Example: Load Balancing

Random selection is desirable for distributing work fairly:

// Illustrative snippet — not a complete program
// Load balancing across backend servers
func handleRequests(
    requests <-chan Request,
    server1, server2, server3 chan<- Request,
) {
    for req := range requests {
        // All servers ready?
        // Random selection distributes evenly
        select {
        case server1 <- req:
        case server2 <- req:
        case server3 <- req:
        }
    }
}

// Over 10,000 requests with all servers ready:
// Server 1: ~3,333 requests (33%)
// Server 2: ~3,334 requests (33%)
// Server 3: ~3,333 requests (33%)
//
// If select favored first case,
// server1 would get ALL 10,000!

This shows why random selection is often exactly what you want—fair distribution without explicit load balancing logic.

Most Code Doesn’t Need Priority

Before exploring priority patterns, understand: random selection is correct for 90% of select statements.

Priority patterns add complexity and potential bugs. Add them only when you have concrete requirements that random selection violates:

• Measured SLO violations (shutdown takes >1s when it should take <100ms)
• Proven starvation (queue depths growing unbounded)
• Business requirement (critical updates must apply within N milliseconds)

Don’t add priority “just in case” or “for performance.” Random selection is fast, fair, and simple. Start with plain select, measure, then optimize if needed.

The rest of this section covers priority patterns for when you genuinely need them.

When Random Selection Causes Problems

Random selection provides fairness, but sometimes you need priority:

Problem 1: Shutdown Signals Get Delayed

// Illustrative snippet — not a complete program
// ✗ PROBLEM: done might not be selected promptly
for {
    select {
    case task := <-tasks:  // High volume
        process(task)
    case <-done:
        return  // May take many
                // iterations to select
    }
}

If tasks always has work and done is closed, each iteration has only a 50% chance of selecting done. On average the worker processes about one extra task before noticing shutdown, but unlucky runs could see several.

  Scenario: 100 buffered tasks, done closes,
  each task takes 10ms

  Without priority (random selection):
    Iter 1: 50% done, 50% task → task wins → 10ms
    Iter 2: 50% done, 50% task → task wins → 10ms
    Iter 3: 50% done, 50% task → done wins → exit

    Average: ~1 task after done closes (10ms)
    Worst case (rare): ~7 tasks (70ms, <1%)

  With priority:
    done checked first every iteration
    Average: 0-1 tasks after done closes (0-10ms)
          

Problem 2: High-Priority Work Delayed

// Illustrative snippet — not a complete program
// ✗ PROBLEM: Critical config might wait
select {
case data := <-dataStream:    // Continuous
    process(data)
case cfg := <-configUpdates:  // Rare but
    applyConfig(cfg)          // time-critical
}

A time-critical configuration change (security patch, rate-limit adjustment) might sit in configUpdates while data items are processed first—violating an SLO that requires config applied within N milliseconds.

Problem 3: Error Handling Priority

// Illustrative snippet — not a complete program
// ✗ PROBLEM: Might return result
// when error exists
select {
case err := <-errors:
    return nil, err      // Should check first
case result := <-results:
    return result, nil
}

If both channels have values, you might return a result when an error should take precedence.

Pattern: Priority with Nested Select

The standard pattern for priority: check the high-priority channel first with a non-blocking select, then fall back to blocking select.

The Problem (Without Priority)

// Illustrative snippet — not a complete program
// ✗ Random selection delays shutdown
func workerNoPriority(tasks <-chan Task, done <-chan struct{}) int {
    processed := 0
    for {
        select {
        case task := <-tasks:
            process(task)  // Takes 10ms
            processed++
        case <-done:
            return processed
        }
    }
}

// Scenario: Tasks arriving constantly,
// done closes
//
// Iteration N: Both ready
//   → 50% chance done, 50% chance task
// Average: ~1 extra task before exiting
// Unlucky runs: several extra tasks

The Solution (With Priority)

// Illustrative snippet — not a complete program
// ✓ Check done first every iteration
func workerWithPriority(tasks <-chan Task, done <-chan struct{}) int {
    processed := 0
    for {
        // Priority check (non-blocking)
        select {
        case <-done:
            return processed
        default:
            // Not done, continue
        }

        // Main select: handle work or done
        select {
        case task := <-tasks:
            process(task)
            processed++
        case <-done:
            return processed
        }
    }
}

// Now: done is checked at START of every
// iteration
// Result: Typically 0-1 tasks after done
// closes (0-10ms delay)

// Illustrative snippet — not a complete program
// ✗ BUG: Can't exit while waiting
for {
    select {
    case <-done:
        return
    default:
    }

    select {
    case task := <-tasks:  // Blocks here
        process(task)      // done not checked!
    // ← done case missing!
    }
}

Visual Timeline

  Scenario A: done already closed

    First select: done is ready → executes → return
    Main select: never reached
    Result: IMMEDIATE exit (0 extra tasks)

  ─────────────────────────────────────────────

  Scenario B: done closes while processing

    Time ──────────────────────────────────────►

    Iter 1 │ First: default  │ Main: task wins
    Iter 2 │ First: default  │ Main: task wins
           │                 │ ← done closes here
    Iter 3 │ First: done!    │ (never reached)
           │ return          │

    Result: Exit on NEXT iteration after done
    At most 1 extra task processed
          

Demonstrating Priority Impact

package main

import "fmt"

func noPriority(tasks <-chan int, done <-chan struct{}) int {
    count := 0
    for {
        select {
        case <-tasks:
            count++
        case <-done:
            return count
        }
    }
}

func withPriority(tasks <-chan int, done <-chan struct{}) int {
    count := 0
    for {
        select {
        case <-done:
            return count
        default:
        }
        select {
        case <-tasks:
            count++
        case <-done:
            return count
        }
    }
}

func main() {
    done := make(chan struct{})
    close(done) // Closed before workers start

    // Separate channels for each test
    // One trial is a coin flip: noPriority often returns after zero
    // tasks, which looks identical to the priority version. Average
    // over many trials so the difference is actually visible.
    const trials = 1000
    totalWithout, totalWith := 0, 0

    for t := 0; t < trials; t++ {
        ch1 := make(chan int, 100)
        ch2 := make(chan int, 100)
        for i := 0; i < 100; i++ {
            ch1 <- i
            ch2 <- i
        }
        totalWithout += noPriority(ch1, done)
        totalWith += withPriority(ch2, done)
    }

    fmt.Printf("Without priority: %.2f tasks per trial\n",
        float64(totalWithout)/float64(trials))
    fmt.Printf("With priority:    %.2f tasks per trial\n",
        float64(totalWith)/float64(trials))
}

The priority pattern provides immediate shutdown response.

Pattern: Drain High-Priority First

To completely drain a high-priority channel before checking others:

// Illustrative snippet — not a complete program
func processWithStrictPriority(
    urgent <-chan Task,
    normal <-chan Task,
    done <-chan struct{},
) {
    for {
        // Drain ALL urgent tasks first
        draining := true
        for draining {
            select {
            case task := <-urgent:
                handleUrgent(task)
            case <-done:
                return
            default:
                draining = false
            }
        }

        // Now check all channels
        select {
        case task := <-urgent:
            handleUrgent(task)
        case task := <-normal:
            handleNormal(task)
        case <-done:
            return
        }
    }
}

Behavior:

1. Inner loop drains urgent until empty
2. default triggers exit when urgent is empty
3. Outer select checks all channels (urgent still included—new urgent work gets priority)
4. Cycle repeats

Pattern: Separate Workers for Priority Levels

Instead of complex select logic, use dedicated goroutines:

// Illustrative snippet — not a complete program
func main() {
    critical := make(chan Task)
    normal := make(chan Task)
    done := make(chan struct{})
    incoming := make(chan Task)

    // Router: distribute by priority.
    // Lifecycle: the inner selects exit on done, but a router
    // parked on "range incoming" is NOT woken by close(done) —
    // the caller must close(incoming) to retire it. Until then
    // close(critical/normal) is unreachable.
    go func() {
        for task := range incoming {
            if task.Priority == HighPriority {
                select {
                case critical <- task:
                case <-done:
                    return
                }
            } else {
                select {
                case normal <- task:
                case <-done:
                    return
                }
            }
        }
        close(critical)
        close(normal)
    }()

    // More workers for critical (5:2 ratio)
    var wg sync.WaitGroup
    for i := 0; i < 5; i++ {
        wg.Go(func() {
            worker(critical, done)
        })
    }

    for i := 0; i < 2; i++ {
        wg.Go(func() {
            worker(normal, done)
        })
    }

    // ... send tasks to incoming ...

    close(done)
    wg.Wait()
}

func worker(tasks <-chan Task, done <-chan struct{}) {
    for {
        select {
        case task, ok := <-tasks:
            if !ok {
                return
            }
            process(task)
        case <-done:
            return
        }
    }
}

Advantages:

• Simple, straightforward code
• Priority via resource allocation (more workers = higher throughput)
• No complex select patterns
• Easier to reason about and tune

Disadvantages:

• More goroutines
• Doesn’t guarantee strict ordering
• Resource allocation is static (though worker pools can help)

This is often the cleanest solution when priority is about throughput rather than strict ordering.

When NOT to Fight Random Selection

Sometimes developers add complex priority logic when it’s not needed:

Case 1: Low-Volume, Long-Running Tasks

// Illustrative snippet — not a complete program
// Usually GOOD ENOUGH for this workload
for {
    select {
    case task := <-tasks:
        process(task)  // Takes 100ms
    case <-done:
        return
    }
}

Why random selection is fine here: Processing takes 100ms per task. Shutdown arrives, both cases ready. 50% chance done executes immediately, 50% chance one more task (100ms), then done executes. Worst case delay: ~100ms (one extra task). For graceful shutdown, 100ms extra is usually acceptable.

Case 2: Acceptable Delay or Approximate Fairness

// Illustrative snippet — not a complete program
// Config updates can wait a few iterations
select {
case data := <-stream:
    process(data)
case cfg := <-config:
    apply(cfg)
}

If applying a non-critical config update a few iterations late (maybe 50ms) is acceptable, random selection works. Similarly, if you need approximate fairness across multiple sources rather than strict ordering, plain select gives roughly equal distribution over thousands of iterations—no complexity needed.

Rule of thumb: Add priority patterns only when you have a concrete requirement that random selection violates. Don’t add complexity speculatively.

Comparing Priority Approaches

Common Mistakes

Decision Guide

  Q1: Is random selection causing actual problems?
               │
        ┌──────┴──────┐
        ▼             ▼
       Yes           No
        │             │
        │             ▼
        │      Use plain select
        │      (simplest, usually sufficient)
        │
        ▼
  Q2: What kind of priority?
        │
   ┌────┼──────────────┐
   ▼    ▼              ▼
 Check-first  Strict    Different
 (shutdown,   ordering  throughput
  signals)    needed    needs
   │          │          │
   ▼          ▼          ▼
 Nested    Drain     Separate
 select    pattern    workers
           (careful!)

  Start simple. Add complexity only when needed.
          

Next: Section 4.6 covers nil channels in select—using nil to dynamically enable and disable select cases, implementing state machines, and coordinating complex channel lifecycles.

4.6 Nil Channels: Dynamic Case Control

Section 3.4 introduced nil channels—channels with zero value that block forever on send or receive. In isolation, this seems like a bug to avoid. But inside select, nil channels become a powerful feature: a nil channel case is completely ignored.

This enables dynamic control over which select cases are active. You can “turn off” a case by setting its channel to nil, and “turn on” a case by assigning a real channel. This section covers the mechanics and patterns that make this useful.

Nil Channel Behavior in Select

A case with a nil channel is never selected—it’s as if that case doesn’t exist:

// Illustrative snippet — not a complete program
var ch chan int  // nil

select {
case v := <-ch:
    fmt.Println("received:", v)  // Never executes
case <-time.After(time.Second):
    fmt.Println("timeout")  // Always executes
}

The receive case is ignored because ch is nil. Only the timeout case is considered.

Demonstrating the Difference

package main

import "fmt"

func main() {
    // Closed channel: always ready, returns zero
    closed := make(chan int)
    close(closed)

    // Nil channel: ignored in select
    var nilCh chan int

    // Test closed channel
    select {
    case v := <-closed:
        fmt.Println("closed returned:", v)
    default:
        fmt.Println("default")
    }

    // Test nil channel
    select {
    case v := <-nilCh:
        fmt.Println("nil returned:", v)
    default:
        fmt.Println("default")
    }
}

The closed channel case executes (returning zero). The nil channel case is ignored, so default executes.

Critical Distinction: Closed vs Nil in Loops

This distinction is crucial for correctness in for-select loops:

  Closed channel in select loop:
    → Case is ALWAYS READY
    → Executes every iteration
    → Returns zero value repeatedly
    → Result: BUSY LOOP (100% CPU, no useful work)

  for {
      select {
      case v := <-closedCh:  // Ready every iteration!
          process(v)         // Processes 0, 0, 0, ...
      }                      // tens of millions/sec
  }

  ─────────────────────────────────────────────

  Nil channel in select loop:
    → Case is IGNORED
    → Never executes
    → Other cases still work
    → Result: Clean disable of that case

  for {
      select {
      case v := <-nilCh:     // Ignored completely
          process(v)         // Never reached
      case v := <-otherCh:   // Still works normally
          handle(v)
      }
  }

  Setting channel to nil DISABLES that case cleanly.
          

This is why nil channels matter: When a channel closes in a loop, you need to disable that case. Setting it to nil is the solution.

Pattern: Merge Multiple Channels Until All Close

The canonical use of nil channels: receive from multiple channels until all have closed.

The Problem

Without nil channels, a closed channel creates a busy loop:

// Illustrative snippet — not a complete program
// ✗ BUG: Busy loop when channel closes
func mergeBroken(ch1, ch2 <-chan int) <-chan int {
    out := make(chan int)

    go func() {
        defer close(out)

        for {
            select {
            case v := <-ch1:
                out <- v  // After ch1 closes:
                          // sends 0 forever!
            case v := <-ch2:
                out <- v  // After ch2 closes:
                          // sends 0 forever!
            }
        }
    }()

    return out
}

When ch1 closes, <-ch1 returns 0 immediately every iteration—infinite zeros flood the output.

The Solution

Detect closure, set channel to nil, exit when all are nil:

// Illustrative snippet — not a complete program
// ✓ CORRECT: Nil channels disable closed cases
func merge(ch1, ch2 <-chan int) <-chan int {
    out := make(chan int)

    go func() {
        defer close(out)

        for ch1 != nil || ch2 != nil {
            select {
            case v, ok := <-ch1:
                if !ok {
                    ch1 = nil  // Disable this case
                    continue   // Don't send zero!
                }
                out <- v

            case v, ok := <-ch2:
                if !ok {
                    ch2 = nil  // Disable this case
                    continue   // Don't send zero!
                }
                out <- v
            }
        }
    }()

    return out
}

Key elements:

1. Comma-ok detects closure (ok == false)
2. Set to nil disables the case in future iterations
3. Continue skips sending the zero value
4. Loop condition exits when all channels are nil

Production note: If the consumer stops reading from out, the goroutine blocks on out <- v forever. In production, add a done channel or use context to cancel the merge.

Execution Trace

Let’s trace through concrete execution:

// Illustrative snippet — not a complete program
ch1 := make(chan int)
ch2 := make(chan int)

go func() {
    ch1 <- 1
    ch1 <- 2
    close(ch1)
}()

go func() {
    ch2 <- 10
    ch2 <- 20
    ch2 <- 30
    close(ch2)
}()

merged := merge(ch1, ch2)
for v := range merged {
    fmt.Println(v)
}

  Iteration 1: ch1=<open>, ch2=<open>
    Both cases considered
    select randomly chooses ch2
    receives: v=10, ok=true
    sends to out: 10

  Iteration 2: ch1=<open>, ch2=<open>
    select randomly chooses ch1
    receives: v=1, ok=true
    sends to out: 1

  Iteration 3: ch1=<open>, ch2=<open>
    select chooses ch1
    receives: v=2, ok=true
    sends to out: 2

  Iteration 4: ch1=<open>, ch2=<open>
    select chooses ch1
    receives: v=0, ok=false (CLOSED!)
    sets: ch1 = nil
    continue (skip send)

  Iteration 5: ch1=nil, ch2=<open>
    ch1 case IGNORED (nil)
    Only ch2 case considered
    receives: v=20, ok=true
    sends to out: 20

  Iteration 6: ch1=nil, ch2=<open>
    receives from ch2: v=30, ok=true
    sends to out: 30

  Iteration 7: ch1=nil, ch2=<open>
    receives from ch2: v=0, ok=false (CLOSED!)
    sets: ch2 = nil
    continue (skip send)

  Loop check: ch1=nil, ch2=nil
    Condition "ch1 != nil || ch2 != nil" is FALSE
    Loop exits → defer close(out)

  Output (order may vary): 10, 1, 2, 20, 30
          

The key insight: once a channel is set to nil, that case disappears from consideration. The loop continues processing the remaining channel until it too closes.

Critical Mistake: Forgetting Continue After Nil

// Illustrative snippet — not a complete program
// ✗ SEVERE BUG: Sends spurious zero value
select {
case v, ok := <-ch:
    if !ok {
        ch = nil
        // Falls through to send!
    }
    out <- v  // ✗ Sends 0 when closed!
}

What goes wrong:

1. Channel closes
2. Receive gets v=0, ok=false
3. Set ch = nil (correct)
4. Then send 0 to output (WRONG!)
5. Downstream receives spurious zero

Concrete Impact Example

// Illustrative snippet — not a complete program
// ✗ WITHOUT continue: False reading
// Merging temperature sensor readings
func mergeBuggy(a, b <-chan float64) <-chan float64 {
    out := make(chan float64)
    go func() {
        defer close(out)
        for a != nil || b != nil {
            select {
            case v, ok := <-a:
                if !ok {
                    a = nil
                }
                out <- v  // ← Sends 0.0!
            case v, ok := <-b:
                if !ok {
                    b = nil
                }
                out <- v
            }
        }
    }()
    return out
}

// Downstream consumer sees:
// 20.5, 21.0, 0.0, 18.0, 18.5, 0.0
//            ^^^              ^^^
// FALSE READINGS! Not real temps
//
// In production:
// - Triggers low-temperature alarms
// - Corrupts analytics/averages
// - Misleads dashboard users

The fix—always continue:

// Illustrative snippet — not a complete program
// ✓ CORRECT: Skip send on closure
// (inside a for-select loop)
select {
case v, ok := <-ch:
    if !ok {
        ch = nil
        continue  // ← Essential! Skip send
    }
    out <- v  // Only reached for real data
}

This is one of the most common nil channel bugs. Make it a habit: nil and continue go together.

Understanding Nil Assignment Scope

// Illustrative snippet — not a complete program
func merge(ch1, ch2 <-chan int) <-chan int {
    // ch1 and ch2 are COPIES of channel
    // values (handles)

    go func() {
        // ...
        ch1 = nil  // Modifies local copy only
        // Caller's channel is unchanged
        // ...
    }()

    return out
}

// Usage
myCh := make(chan int)
merge(myCh, otherCh)
// myCh is still a valid channel—not nil

Pattern: N-Way Merge

The nil channel approach works well for a fixed number of channels (2–3). For merging an arbitrary number, use one goroutine per input channel:

// Illustrative snippet — not a complete program
import "sync"

func mergeN(channels ...<-chan int) <-chan int {
    out := make(chan int)
    var wg sync.WaitGroup

    for _, ch := range channels {
        wg.Go(func() {
            for v := range ch {
                out <- v
            }
        })
    }

    go func() {
        wg.Wait()
        close(out)
    }()

    return out
}

// Illustrative snippet — not a complete program
cases := make([]reflect.SelectCase, len(channels))
for i, ch := range channels {
    cases[i] = reflect.SelectCase{
        Dir:  reflect.SelectRecv,
        Chan: reflect.ValueOf(ch),
    }
}

chosen, value, ok := reflect.Select(cases)

Pattern: State Machine with Nil Channels

Use nil channels to encode state—which operations are valid in each state:

// Illustrative snippet — not a complete program
type Worker struct {
    tasks   chan Task
    pause   chan struct{}
    resume  chan struct{}
    done    chan struct{}
}

func (w *Worker) Run() {
    // Active when running
    var tasksCh <-chan Task = w.tasks

    for {
        select {
        case task := <-tasksCh:
            // Only when tasksCh != nil
            process(task)

        case <-w.pause:
            fmt.Println("Pausing...")
            tasksCh = nil  // Disable tasks

        case <-w.resume:
            fmt.Println("Resuming...")
            tasksCh = w.tasks  // Re-enable

        case <-w.done:
            return
        }
    }
}

  ┌─────────────┐  <-pause  ┌─────────────┐
  │   Running   │──────────▶│   Paused    │
  │ tasksCh=ch  │◀──────────│ tasksCh=nil │
  └──────┬──────┘  <-resume └──────┬──────┘
         │                         │
         └──────────<-done─────────┘
                       │
                       ▼
                     exit

  Running: tasks case is active, processes work
  Paused:  tasks case is IGNORED, worker idles

  No boolean flags needed—channel state IS the state.
          

Advantages of channel-based state:

• No explicit state variable or mutex
• State is implicit in channel values
• Select automatically handles valid transitions
• Invalid operations (task while paused) simply don’t execute

Pattern: Conditional Send with Nil Channel

Send only when a condition is true:

// Illustrative snippet — not a complete program
func processWithOptionalOutput(
    input <-chan Data,
    output chan<- Result,
    enableOutput bool,
    done <-chan struct{},
) {
    var outCh chan<- Result
    if enableOutput {
        outCh = output
    }
    // If false, outCh remains nil

    for {
        select {
        case data := <-input:
            result := process(data)

            // Ignored if outCh is nil
            select {
            case outCh <- result:
                // Sent result
            case <-done:
                return
            default:
                // nil: skip by design
                // full/no receiver: dropped!
            }

        case <-done:
            return
        }
    }
}

When enableOutput is false, outCh is nil, and the send case is always ignored. No explicit if enableOutput check needed inside the loop.

Pattern: Coordinated Forwarder

Forward values from input to output with proper closure handling: