Unveiling Go’s Channel: Deep Dive into Runtime, Memory Leaks, and Best Practices

Go introduced the channel early in its history as a core component of its concurrency model, embodying the CSP principle “communicating sequential processes” and encouraging communication over shared memory.

Memory‑Leak Case Study

At the end of last year a service running in a Kubernetes pod exhibited a saw‑tooth memory‑usage pattern, eventually hitting the 16 GB limit and causing the container to restart. The root cause was a goroutine that sent to an unbuffered channel ( respAChan) while the parent goroutine returned early due to errors from services B and C. The unbuffered channel never received a read, leaving the goroutine blocked and leaking memory as request volume grew.

Fixing the issue involved converting the channel to a buffered one and closing it after the write:

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

Channel Basics

Channels come in two flavors:

Unbuffered (synchronous) channels : send and receive block until the counterpart is ready.

Buffered (asynchronous) channels : send proceeds if the buffer has space; otherwise it blocks.

Common operations are:

Read: <- ch Write: ch <- v Close: close(ch) Length: len(ch) Capacity: cap(ch) Non‑blocking select: choose a ready case or default.

Design Philosophy

Go’s concurrency model treats a goroutine as the execution unit and a channel as the communication link. Instead of protecting shared memory with mutexes, Go prefers passing values (or pointers) through channels, which internally use a lock‑protected FIFO queue to guarantee fairness and simplify reasoning.

Internal Structure (hchan)

The runtime representation of a channel is the hchan struct defined in src/runtime/chan.go:

type hchan struct {
    qcount   uint           // total elements in the queue
    dataqsiz uint           // size of the circular buffer
    buf      unsafe.Pointer // pointer to the buffer
    elemsize uint16         // size of each element
    closed   uint32         // closed flag
    elemtype *_type         // element type information
    sendx    uint           // write index in the buffer
    recvx    uint           // read index in the buffer
    recvq    waitq          // waiting receivers
    sendq    waitq          // waiting senders
    lock     mutex          // protects the channel
}

Key fields: buf points to a fixed‑size circular buffer that stores values. sendq and recvq are doubly‑linked lists of sudog structures, each representing a goroutine waiting to send or receive.

The channel lock ensures that all modifications are atomic and safe for concurrent access.

Creating a Channel

Channel creation uses the built‑in make function:

ch := make(chan int, 10)

The compiler translates this to an OMAKECHAN node, which is handled by walkMakeChan. Depending on the size argument, the compiler calls either makechan64 (for 64‑bit sizes) or makechan (for 32‑bit platforms). The latter allocates the hchan object and, if needed, the buffer memory, performing checks for element size, alignment, and overflow.

Sending Data

A send statement ( ch <- v) becomes an OSEND node, processed by walkSend, which eventually calls the runtime function chansend1 → chansend. The algorithm proceeds as follows:

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

If the channel is unbuffered and no receiver is waiting, or the buffer is full, a non‑blocking send returns false.

The channel lock is acquired. If the channel is closed, a panic occurs.

If a receiver is waiting, the value is copied directly to the receiver’s stack ( sendDirect) and the receiver is awakened.

If the buffer has space, the value is copied into the circular buffer, indices are updated, and the send succeeds.

Otherwise the sender is placed on sendq and the goroutine is parked until a receiver wakes it.

Receiving Data

A receive expression ( <- ch or v, ok := <-ch) compiles to an ORECV node, which the compiler turns into chanrecv1 / chanrecv2. The core routine chanrecv works as follows:

If the channel is nil, a non‑blocking receive returns

(false, false)</>; a blocking receive parks the goroutine.</li>
<li>For a non‑blocking call, <code>empty(c)

checks whether the channel is empty; if closed, a zero value is returned with (true, false).

The channel lock is taken. If the channel is closed and empty, the zero value is returned.

If a sender is waiting, the value is taken directly from the sender ( recvDirect) and the sender is awakened.

If the buffer contains data, the value is copied from the buffer, indices are advanced, and the receive succeeds.

If no data is available, the receiver is enqueued on recvq and the goroutine is parked until a sender wakes it.

Closing a Channel

The statement close(ch) is compiled to a call to runtime.closechan. The function performs these steps:

Panic if the channel is nil or already closed.

Acquire the channel lock and set the closed flag.

Drain both recvq and sendq, clearing pending data and marking each waiting goroutine as unsuccessful.

Wake all goroutines in the collected list so that receivers obtain the zero value and senders panic on further sends.

Summary

A Go channel is a lock‑protected FIFO queue that transfers values between goroutines. The transfer is a pure value copy; for reference types the copy is of the pointer, effectively moving ownership. Because the implementation relies on a mutex and waiting queues, channels provide deterministic fairness and avoid the pitfalls of manual lock‑based shared‑memory communication.