Understanding Go Channels: Implementation, Usage, and Performance

This article is a learning note based on the Go 1.18.1 source code, focusing on the underlying implementation of channels from Go 1.14 to Go 1.19. Channels are one of the earliest concurrency primitives introduced by Go, embodying the language's philosophy of "communicating by sharing memory, not sharing memory by communicating".

Do not communicate by sharing memory; instead, share memory by communicating.

The article first presents a concise conclusion: a channel is essentially a thread‑safe FIFO (First‑In‑First‑Out) queue composed of three FIFO queues—buf (circular buffer), sendq (waiting senders), and recvq (waiting receivers). The FIFO design guarantees fairness by giving priority to the goroutine that has waited the longest.

Key structural details of a channel are described. The runtime type hchan (found in src/runtime/chan.go ) contains fields such as qcount (total elements), dataqsiz (buffer size), buf (pointer to the circular buffer), sendq , recvq , and a mutex lock . The article explains the meaning of each field and how they interact during send and receive operations.

Channel creation uses the make built‑in, e.g.:

ch := make(chan int, 10)

The compiler translates this into an OMAKECHAN node, which eventually calls runtime.makechan . The implementation checks element size, alignment, and possible overflow before allocating memory for the hchan and its buffer.

Sending data ( ch <- v ) is compiled to an OSEND node and handled by chansend . The article outlines the six major steps:

If the channel is nil , a non‑blocking send returns false; a blocking send panics.

If the channel is closed, a panic occurs.

If there is a waiting receiver, the value is copied directly to the receiver, bypassing the buffer.

If the buffer has space, the value is copied into the circular buffer and counters are updated.

If the buffer is full, the sending goroutine is enqueued in sendq and parked.

When the goroutine is later awakened, it cleans up and returns.

Receiving data ( v := <-ch or v, ok := <-ch ) follows a symmetric flow, compiled to an ORECV node and processed by chanrecv . The steps include:

Nil channel handling (blocking or immediate return for non‑blocking).

If the channel is closed and empty, a zero value is returned with ok == false .

If a waiting sender exists, the value is taken directly from the sender.

If the buffer contains data, the value is copied from the buffer and counters are decremented.

If the buffer is empty, the receiving goroutine is enqueued in recvq and parked.

The article also presents a real‑world memory‑leak case: an unbuffered channel respAChan used in a goroutine becomes blocked when the parent goroutine returns early due to errors in other services. The blocked goroutine holds the channel forever, causing memory growth until the container restarts. The fix is to use a buffered channel and close it after writing:

respAChan := make(chan string, 1)
go func() {
    serviceAResp, _ := accessServiceA()
    respAChan <- serviceAResp
    close(respAChan)
}()

Further, the article discusses the design philosophy behind Go’s concurrency model (CSP) and why channels are preferred over shared‑memory with mutexes: channels provide a clear, FIFO‑based communication pattern that reduces data races and makes large, high‑concurrency programs easier to reason about.

Finally, the article details the channel closing process ( close(ch) ), which involves locking the channel, marking it closed, and waking up all waiting senders and receivers. Closing a nil channel or a channel that is already closed triggers a panic.

In summary, Go channels are lock‑protected FIFO queues that enable safe data transfer between goroutines. They copy values (or addresses for reference types) and enforce ownership transfer, simplifying concurrent program design while offering performance comparable to sync.Mutex .