debug a problem involving Channel Creation
Fast recall
Quick revision
Core answer
Practical understanding of Channel Creation.
Repeating a definition without saying when to use it.
Give one trade-off and say how you would test it.
Interview-ready guide
Interview answer
Two functions, two different meanings — and the pair teaches what a channel IS:
ch := make(chan int, 3) // cap 3, forever
cap(ch) // 3 — the buffer size from make
len(ch) // 0 — empty right now
ch <- 1
ch <- 2
len(ch) // 2 — two values buffered
<-ch
len(ch) // 1 — one value remainsThe capacity is set once at make and never changes — it's the size of the ring buffer the runtime allocated. Unbuffered channels have cap 0.
The length is a diagnostic: how many values are in the buffer at this instant. For an unbuffered channel, len is always 0 — values never sit in an unbuffered channel; they transfer directly.
The critical understanding: len is a snapshot in a concurrent world. Between reading len(ch) and acting on it, another goroutine can send or receive, so len's value is stale the moment you have it. That's why len(ch) is for diagnostics and debugging (metrics, health checks, logging queue depth), never for control flow. Deciding 'should I send?' based on len(ch) == cap(ch) is a race — the correct decision procedure IS the send: just send, and let the channel block or not. The channel's own blocking is the only atomic test-and-act it needs.
debug a problem involving Channel Creation
Direct Answer
cap(ch) is the buffer size set at make — fixed for life. len(ch) is the number of values currently sitting in the buffer — a runtime snapshot that changes with every send/receive.
Deep Dive & Architecture
The reason len is advisory-only lives in the channel's lock: every operation (send, receive, len, cap) takes the channel's internal lock, but separately. Your len call and another goroutine's send are two lock acquisitions — nothing composes them. There is no 'len+send' atomic, and adding one would make the API a mini-transaction manager the channel deliberately avoids being.
What len IS used for, honestly: monitoring and load-shedding signals. A worker pool publishing its queue depth (len of a buffered channel) into a metric lets operators see consumer lag — the number rising means the consumer is falling behind. It's information, not coordination.
The cap/len distinction also explains channel behavior classes cleanly: cap 0 (unbuffered — len always 0, every send is a rendezvous), cap 1 (the classic semaphore or single-slot handoff), cap n (the decoupling queue — len measures the momentary imbalance between production and consumption rates). When a system's design uses len meaningfully, it's almost always the cap-n case being monitored; the cap-0 and cap-1 cases have nothing to measure — their protocol is in the blocking itself.
Common Mistakes & Pitfalls
Repeating a definition without saying when to use it.
Check your understanding
Answer these without looking back at the article.
- What is Channel Creation, and when would you use it?
- When would you use Channel Creation in a real project?
- How would you compare Channel Creation with an alternative?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.