Chapter 2: Channels in Go - How Goroutines Talk to Each Other

Introduction

• A web scraper needs workers to report results back to a central collector
• A pipeline processor must pass data from one stage to the next
• A rate limiter needs to coordinate access to a shared resource
• A graceful shutdown system must signal all workers to stop

Core Concepts

The Problem with Shared Memory

Go blog diagram 1

Thread A reads counter: 5
Thread B reads counter: 5
Thread A calculates: 5 + 1 = 6
Thread B calculates: 5 + 1 = 6
Thread A writes: 6
Thread B writes: 6

Final value: 6 (should be 7!)

Go's Communication Philosophy

Go blog diagram 2

"Don't communicate by sharing memory; share memory by communicating."

What Is a Channel?

go
// Create a channel that carries integers
ch := make(chan int)

// Send a value into the channel
ch <- 42

// Receive a value from the channel
value := <-ch

• Typed: A chan int can only carry integers. Type safety is enforced at compile time.
• Thread-safe: Channel operations are atomic. No locks needed.
• Blocking by default: Sends wait for receivers; receives wait for senders.

• ch <- value Arrow points into the channel (send)
• value := <-ch Arrow points out of the channel (receive)

Detailed Explanation: Unbuffered Channels

Go blog diagram 3

How Unbuffered Channels Work

go
// Filename: basic_channel.go
package main

import "fmt"

func main() {
    // Create an unbuffered channel for strings
    messages := make(chan string)

    // Start a goroutine that sends a message
    go func() {
        messages <- "Hello from goroutine!"
        // Sender blocks here until main() receives
    }()

    // Receive the message in the main goroutine
    // This blocks until the sender sends
    msg := <-messages
    fmt.Println(msg)
}

1. Main goroutine creates the channel
2. Main goroutine starts an anonymous goroutine
3. Main goroutine reaches <-messages and blocks (nothing to receive yet)
4. Anonymous goroutine reaches messages <- and unblocks (main is waiting)
5. Value transfers from sender to receiver
6. Both goroutines continue

The Blocking Nature: A Feature, Not a Bug

go
// Filename: blocking_demo.go
package main

import (
    "fmt"
    "time"
)

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

    go func() {
        fmt.Println("Goroutine: Starting work...")
        time.Sleep(2 * time.Second)
        ch <- "Work complete!"
        fmt.Println("Goroutine: Message sent!")
    }()

    fmt.Println("Main: Waiting for result...")
    msg := <-ch  // Blocks until message arrives
    fmt.Println("Main: Received:", msg)
}

Main: Waiting for result...
Goroutine: Starting work...
Goroutine: Message sent!
Main: Received: Work complete!

• Main doesn't busy-wait or poll. It simply blocks until data arrives.
• The ordering is guaranteed: main receives after the goroutine sends.
• No time.Sleep hacks needed for synchronization.

Visualizing the Handoff

Sender:     [waiting with value] -----> [transfer] -----> [continues]
                                            |
Receiver:   [waiting for value] <----- [transfer] -----> [has value, continues]

Detailed Explanation: Buffered Channels

Go blog diagram 4

When Blocking Hurts

go
// Unbuffered: Logger blocks if consumer is slow
logCh := make(chan string)
logCh <- "Event happened"  // Blocks until someone reads this!

go
// Buffered: Can hold 100 messages before blocking
logCh := make(chan string, 100)
logCh <- "Event 1"  // Doesn't block (buffer has room)
logCh <- "Event 2"  // Doesn't block (buffer has room)
// ... up to 100 messages ...
logCh <- "Event 101"  // NOW it blocks (buffer full)

Creating and Using Buffered Channels

go
// Filename: buffered_channel.go
package main

import "fmt"

func main() {
    // Create a channel that can buffer 3 values
    ch := make(chan int, 3)

    // These sends don't block buffer has room
    ch <- 1
    ch <- 2
    ch <- 3

    fmt.Println("Sent 3 values without blocking")

    // If we tried ch <- 4 here, it would block
    // because the buffer is full

    // Receive values
    fmt.Println(<-ch)  // 1
    fmt.Println(<-ch)  // 2
    fmt.Println(<-ch)  // 3
}

Sent 3 values without blocking
1
2
3

Buffer Dynamics

Buffer capacity: 3
State: [empty] [empty] [empty]

Send 10: [10] [empty] [empty]        no blocking
Send 20: [10] [20] [empty]           no blocking
Send 30: [10] [20] [30]              no blocking
Send 40:                              BLOCKS (buffer full)

Receive: returns 10, buffer becomes [20] [30] [empty]
Send 40: [20] [30] [40]              now succeeds

When to Use Buffered vs Unbuffered

Closing Channels

Go blog diagram 5

Why Close Channels?

go
close(ch)  // Signal: "No more values coming"

1. Sending to a closed channel panics
2. Receiving from a closed channel immediately returns the zero value
3. You can check if a channel is closed using the comma-ok idiom

The Comma-OK Idiom

go
value, ok := <-ch
// ok is true if value was received normally
// ok is false if channel is closed and empty

go
// Filename: channel_close.go
package main

import "fmt"

func main() {
    ch := make(chan int, 3)
    ch <- 1
    ch <- 2
    ch <- 3
    close(ch)

    // Receive with comma-ok
    for {
        value, ok := <-ch
        if !ok {
            fmt.Println("Channel closed!")
            break
        }
        fmt.Println("Received:", value)
    }
}

Received: 1
Received: 2
Received: 3
Channel closed!

Ranging Over Channels

go
// Filename: channel_range.go
package main

import "fmt"

func producer(ch chan int) {
    for i := 1; i <= 5; i++ {
        ch <- i
    }
    close(ch)  // Signal completion
}

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

    // Range automatically stops when channel closes
    for num := range ch {
        fmt.Println("Received:", num)
    }

    fmt.Println("Done receiving")
}

Received: 1
Received: 2
Received: 3
Received: 4
Received: 5
Done receiving

Who Should Close?

• The sender knows when there are no more values
• Closing a channel twice panics
• Sending on a closed channel panics

Select: Multiplexing Channels

Go blog diagram 6

The Problem of Multiple Sources

• Work results from several workers
• A timeout signal
• A cancellation signal

The Select Statement

go
select {
case msg1 := <-ch1:
    fmt.Println("Received from ch1:", msg1)
case msg2 := <-ch2:
    fmt.Println("Received from ch2:", msg2)
case ch3 <- value:
    fmt.Println("Sent to ch3")
}

Example: First Response Wins

go
// Filename: select_example.go
package main

import (
    "fmt"
    "time"
)

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

    // Simulate two services with different response times
    go func() {
        time.Sleep(1 * time.Second)
        ch1 <- "Response from Service A"
    }()

    go func() {
        time.Sleep(2 * time.Second)
        ch2 <- "Response from Service B"
    }()

    // Receive both responses
    for i := 0; i < 2; i++ {
        select {
        case msg := <-ch1:
            fmt.Println(msg)
        case msg := <-ch2:
            fmt.Println(msg)
        }
    }
}

Response from Service A
Response from Service B

Implementing Timeouts

go
select {
case result := <-workCh:
    fmt.Println("Got result:", result)
case <-time.After(3 * time.Second):
    fmt.Println("Timeout: no result in 3 seconds")
}

Non-Blocking Operations with Default

go
select {
case msg := <-ch:
    fmt.Println("Received:", msg)
default:
    fmt.Println("No message available right now")
}

Channel Direction

Restricting Channel Operations

go
// Send-only channel parameter
func sender(ch chan<- int) {
    ch <- 42
    // <-ch would be a compile error
}

// Receive-only channel parameter
func receiver(ch <-chan int) {
    value := <-ch
    // ch <- 42 would be a compile error
}

Why Direction Matters

1. Documentation: Function signature clearly shows intent
2. Compile-time safety: Bugs caught before runtime
3. Design clarity: Enforces clean channel usage patterns

Conversion Rules

go
ch := make(chan int)

var sendOnly chan<- int = ch  // OK
var recvOnly <-chan int = ch  // OK

Code Examples: Real-World Patterns

Go blog diagram 7

Worker Pool Pattern

go
// Filename: worker_pool.go
package main

import (
    "fmt"
    "sync"
    "time"
)

type Job struct {
    ID   int
    Data string
}

type Result struct {
    JobID  int
    Output string
}

// worker processes jobs and sends results.
// jobs is receive-only; results is send-only.
func worker(id int, jobs <-chan Job, results chan<- Result, wg *sync.WaitGroup) {
    defer wg.Done()

    for job := range jobs {
        // Simulate processing
        time.Sleep(500 * time.Millisecond)

        results <- Result{
            JobID:  job.ID,
            Output: fmt.Sprintf("Worker %d processed: %s", id, job.Data),
        }
    }
}

func main() {
    const numJobs = 5
    const numWorkers = 3

    jobs := make(chan Job, numJobs)
    results := make(chan Result, numJobs)

    var wg sync.WaitGroup

    // Start workers
    for w := 1; w <= numWorkers; w++ {
        wg.Add(1)
        go worker(w, jobs, results, &wg)
    }

    // Send jobs
    for j := 1; j <= numJobs; j++ {
        jobs <- Job{ID: j, Data: fmt.Sprintf("Task-%d", j)}
    }
    close(jobs)  // Signal no more jobs

    // Wait for workers and close results
    go func() {
        wg.Wait()
        close(results)
    }()

    // Collect results
    for result := range results {
        fmt.Println(result.Output)
    }
}

• Bounded concurrency: Exactly 3 workers, regardless of job count
• Clean shutdown: Closing jobs signals workers to exit
• No goroutine leaks: WaitGroup ensures we wait for completion

Timeout Pattern

go
func fetchWithTimeout(url string) (string, error) {
    resultCh := make(chan string, 1)
    errCh := make(chan error, 1)

    go func() {
        // Simulate HTTP fetch
        time.Sleep(2 * time.Second)
        resultCh <- "Response data"
    }()

    select {
    case result := <-resultCh:
        return result, nil
    case err := <-errCh:
        return "", err
    case <-time.After(1 * time.Second):
        return "", fmt.Errorf("timeout after 1 second")
    }
}

Done Channel for Cancellation

go
func worker(done <-chan struct{}, work <-chan int) {
    for {
        select {
        case <-done:
            fmt.Println("Worker: Received stop signal")
            return
        case job := <-work:
            fmt.Println("Processing:", job)
        }
    }
}

func main() {
    done := make(chan struct{})
    work := make(chan int)

    go worker(done, work)

    work <- 1
    work <- 2

    close(done)  // Signal worker to stop
    time.Sleep(100 * time.Millisecond)
}

Common Mistakes and Misconceptions

Mistake 1: Sending on a Closed Channel

go
ch := make(chan int)
close(ch)
ch <- 1  // PANIC: send on closed channel

Mistake 2: Forgetting to Close in Range Loops

go
// BROKEN: Range never ends
ch := make(chan int)
go func() {
    for i := 0; i < 5; i++ {
        ch <- i
    }
    // Forgot close(ch)!
}()

for v := range ch {  // Blocks forever after receiving 5
    fmt.Println(v)
}

Mistake 3: Deadlock from Unbuffered Single-Goroutine

go
// BROKEN: Deadlock
ch := make(chan int)
ch <- 1  // Blocks forever no receiver
fmt.Println(<-ch)  // Never reached

go
ch := make(chan int, 1)  // Buffer of 1
ch <- 1                   // Succeeds
fmt.Println(<-ch)         // Works

Mistake 4: Nil Channel Behavior

go
var ch chan int  // nil
ch <- 1          // Blocks forever
<-ch             // Blocks forever

Performance and Best Practices

Buffer Size Guidelines

Channel vs Mutex

Memory Efficiency

Summary

• Channels are typed communication pipes: They safely transfer data between goroutines.
• Unbuffered channels synchronize: Sender and receiver must meet; both block until the other arrives.
• Buffered channels decouple: Sends succeed immediately if buffer has room; useful for burst handling.
• Closing signals completion: Receivers detect closure; range loops use this automatically.
• Select multiplexes channels: Wait on multiple operations; enables timeouts and non-blocking patterns.
• Channel direction restricts operations: chan<- for send-only, <-chan for receive-only; caught at compile time.
• Only senders should close: Closing is a broadcast signal that no more data is coming.

Interview Questions

1. Explain the difference between unbuffered and buffered channels. When would you choose one over the other?
2. What happens when you send to an unbuffered channel with no receiver? What about to a buffered channel that isn't full?
3. A developer closes a channel and then attempts to send to it. What happens? What about receiving from a closed channel?
4. Explain the select statement. How does Go choose which case to execute when multiple channels are ready?
5. What is the comma-ok idiom for channel receives? When is it necessary versus using range?
6. Describe a scenario where a nil channel might be intentionally useful in a select statement.
7. What are channel direction types (chan<- and <-chan)? Why would you use them in function signatures?
8. You have a producer generating data and three consumers processing it. Design a channel-based solution. Who closes what channel?
9. Explain why the following code deadlocks:

   go
   ch := make(chan int)
   ch <- 42
   fmt.Println(<-ch)

10. What's the difference between len(ch) and cap(ch) for a buffered channel?
11. A range loop over a channel never terminates even though the sender function has returned. What's wrong?
12. Describe the worker pool pattern using channels. What are its advantages over creating one goroutine per task?
13. How would you implement a timeout for a channel receive without using the context package?
14. What are the performance trade-offs between channels and mutex-based synchronization?
15. Can you explain why Go chose channels as a core language feature rather than leaving concurrency to libraries?