Busca en todas las páginas de la documentación
Channels are typed queues with blocking semantics coordinated by the runtime. An unbuffered channel forces a rendezvous between the sender and receiver; a buffered channel stores values in a fixed ring until its capacity is full. Closing a channel changes the send/receive rules and serves as the idiomatic broadcast signal.
A channel variable is a descriptor pointing to an hchan structure that holds a buffer, queues of goroutines waiting to send or receive, and lock-based synchronization mechanisms. Understanding the blocking points is crucial to prevent deadlocks, memory leaks, and misuse of the close function.
Quick-reference recipe card - ready to copy and paste.
ch := make(chan int) // unbuffered - synchronizes handoff
buf := make(chan int, 8) // buffered - accepts up to 8 sends without a receiver
buf <- 1
v := <-buf
close(buf)
v, ok := <-buf // ok will be false after the buffer is drainedWhen to use this:
close (allowing receivers to exit their loops).package main
import (
"fmt"
"sync"
)
func main() {
ch := make(chan int, 2) // Create a buffered channel with capacity 2
var wg sync.WaitGroup
wg.Add(1)
go func() {
defer wg.Done()
ch <- 1 // Send value 1
ch <- 2 // Send value 2
close(ch) // Close the channel after sending all values
}()
// Range over the channel to receive values
for v := range ch {
fmt.Println(v) // Print received value
}
wg.Wait() // Wait for the goroutine to finish
}What this demonstrates:
close allows the range loop to drain any remaining values from the channel and then exit.close the channel.hchan structure: Contains a buffer ring, qcount (queue count), send/receive wait queues (implemented as sudog linked lists), a lock, and information about the element type.ok == false.| Operation | nil chan | open, empty | open, has data | closed, drained |
|---|---|---|---|---|
| receive | block forever | block | value, ok true | zero value, ok false |
| send | block forever | unbuf: block until recv; buf: maybe block | send if buf space | panic |
close(ch): After closing, no more values can be sent on the channel. Receivers can still retrieve any remaining buffered values. Subsequent receives on the channel will return the zero value for the channel's type with ok == false.select with default: Non-blocking operations can be implemented using a select statement with a default case, which executes immediately if no other case is ready.// Ownership: The sender closes the channel when it's done producing values.
go func() {
defer close(out) // Ensure the channel is closed when the goroutine finishes
for item := range work { // Process items from the 'work' channel
out <- process(item) // Send the processed item to the 'out' channel
}
}()
// Do not close from the receiver side unless the protocol explicitly dictates it.
// The 'range' loop automatically exits when the channel is closed and drained.sync.Once if the closing pattern is complex but well-defined.select statement that checks for context cancellation (ctx.Done()) or ensure that all sends are completed before closing the channel.make(chan T, 0) is functionally identical to an unbuffered channel. This can be confusing if the intent was to create a buffered channel but no capacity was specified. Fix: Omit the capacity argument (make(chan T)) for channels that require synchronization at the point of handoff. Specify an explicit buffer size (make(chan T, N)) when throughput is more important than immediate synchronization.context cancellation and select statements to provide a way to unblock and terminate goroutines.len(ch) for synchronization is unreliable because it provides only a snapshot of the number of elements currently in the buffer. It does not guarantee a specific queue depth contract. Fix: If the protocol requires tracking counts, use explicit counter variables managed atomically or with mutexes.| Alternative | Use When | Don't Use When |
|---|---|---|
sync.Mutex + sync.Cond | Protecting shared structured state that requires conditional waiting. | Handing off ownership of values between goroutines. |
errgroup + context | Managing a group of goroutines that fan out from a single task, with cancellation propagation. | Implementing fine-grained item-by-item pipelines. |
| Custom buffered ring buffer | Implementing lock-free, high-performance paths where deep expertise in concurrency primitives is available. | Handling standard business logic or when the complexity outweighs the benefits. |
sync.WaitGroup | Waiting for a fixed set of goroutines to complete a one-shot task. | Streaming values between pipeline stages or signaling ongoing work. |
An unbuffered channel synchronizes the sender and receiver at the exact moment of the handoff. A buffered channel allows send operations to proceed without immediately blocking, up to its defined capacity, even if there isn't a receiver waiting.
Typically, the sender or producer goroutine should close the channel when it determines that no more values will be sent. Receivers can detect the channel's completion either by checking the ok boolean returned from a receive operation or by using a range loop, which automatically terminates when the channel is closed and drained.
After a channel is closed and all buffered values have been received, any subsequent receive operations will return immediately without blocking. They will yield the zero value for the channel's element type and ok will be false.
This behavior is intentional and indicates a protocol violation or bug in the program's logic. Sending on a closed channel implies that producers and consumers disagree about the channel's lifecycle, which is a critical error.
A nil channel is a channel that has not been initialized. Any attempt to send to or receive from a nil channel will block indefinitely. This behavior is often useful in select statements to dynamically disable a particular case.
While the Go runtime typically wakes waiting goroutines in FIFO (First-In, First-Out) order for channel wait queues in most common scenarios, you should not rely on this fairness for program correctness. Design your concurrency patterns assuming potential unfairness.
Yes, you can use the built-in len(ch) function to get the number of elements currently queued in the channel's buffer, and cap(ch) to get the buffer's total capacity. However, both len and cap return snapshots of the channel's state and can be subject to race conditions if used for synchronization in concurrent programs.
Channel variables themselves are descriptors. When you copy a channel variable, you are duplicating the handle to the same underlying hchan structure. Both the original and the copied variable refer to the same channel.
Yes. A send operation on a channel happens before the corresponding receive operation completes. Similarly, a close operation happens before any receive operation that returns the zero value with ok == false.
The buffer size should be sufficient to absorb temporary bursts from the producer without causing it to block, thus improving throughput. However, it should also be small enough to apply backpressure to the producer if the consumer cannot keep up, preventing unbounded memory growth.
No, ranging over a nil channel will block forever, similar to attempting a receive operation on a nil channel.
Channels can only be compared to nil using the == operator. Comparing two non-nil channels for equality is not permitted.
select statement.Stack versions: This page was written for Go 1.26.x (Green Tea GC default, go fix modernizers - verify patch at build), chi (latest - verify at build), gin (latest - verify at build), echo (latest - verify at build), google.golang.org/grpc (latest - verify at build), sigs.k8s.io/controller-runtime (latest - verify at build), kubebuilder (latest - verify at build), tinygo (latest - verify board targets at build), wazero (latest - verify at build), and golangci-lint (latest - verify linter set at build).
Revisado por Chris St. John·Última actualización: 16 jul 2026