How do channels work?

Question

Accepted Answer

A **channel** is a typed conduit for **communication between goroutines** — one goroutine sends values, another receives them. Channels are how Go goroutines safely pass data and synchronize, embodying the motto "share memory by communicating."

## Creating and using channels

```go
ch := make(chan int)     // an unbuffered channel of ints

go func() {
    ch <- 42             // SEND a value into the channel (arrow points INTO ch)
}()

value := <-ch            // RECEIVE a value from the channel (arrow points OUT)
fmt.Println(value)       // 42
```

The `<-` operator both sends (`ch <- v`) and receives (`v := <-ch`).

## Unbuffered vs buffered channels

```go
// UNBUFFERED — send blocks until a receiver is ready (synchronization point)
ch := make(chan int)
// sending blocks until another goroutine receives → they "rendezvous"

// BUFFERED — holds up to N values; send blocks only when the buffer is FULL
buf := make(chan int, 3)
buf <- 1; buf <- 2; buf <- 3   // these don't block (buffer has room)
buf <- 4                        // blocks now — buffer is full
```

**Unbuffered** channels synchronize: a send waits for a receive (and vice versa), making them a coordination tool. **Buffered** channels decouple sender and receiver up to the buffer size.

## Closing channels and ranging

```go
ch := make(chan int)
go func() {
    for i := 0; i < 3; i++ { ch <- i }
    close(ch)               // signal "no more values" (only the SENDER closes)
}()

for v := range ch {         // receives until the channel is CLOSED
    fmt.Println(v)
}

// the comma-ok form detects a closed channel
v, ok := <-ch               // ok = false if the channel is closed and drained
```

Closing a channel signals completion; `range` over a channel receives until it's closed. **Only the sender should close** a channel.

## Common deadlock and panic pitfalls

```go
// ❌ deadlock — sending on an unbuffered channel with no receiver
ch := make(chan int)
ch <- 1                     // 💥 fatal error: all goroutines asleep - deadlock!

// ❌ panic — operations on/after close
close(ch); close(ch)        // 💥 panic: close of closed channel
close(ch); ch <- 1          // 💥 panic: send on closed channel
v := <-closedCh             // ✅ OK — receiving from a closed channel returns the zero value
```

Deadlocks (everyone blocked) and close-related panics are common channel bugs to understand.

## Directional channels (for clear APIs)

```go
func producer(out chan<- int) { out <- 1 }   // send-only
func consumer(in <-chan int)  { <-in }         // receive-only
```

## Why it matters

Channels are the heart of Go's concurrency model and the idiomatic way for goroutines to communicate and synchronize — implementing the core philosophy "don't communicate by sharing memory; share memory by communicating." They let you pass data safely between concurrent goroutines without explicit locks, build pipelines, distribute work, and signal completion.

Understanding the send/receive operations, the crucial **unbuffered (synchronizing) vs buffered (decoupling)** distinction, closing semantics (sender closes; range/comma-ok detect it), and the common pitfalls (**deadlocks** from blocked sends/receives, **panics** from closing twice or sending on a closed channel) is essential for writing correct concurrent Go.

Channels (with goroutines) are central to Go's identity and among the most important and frequently-tested concepts in the language.