Use channels for goroutine coordination and data flow by passing data safely between goroutines instead of relying on shared memory and mutexes, as shown in the worker pattern where tasks and results are communicated via channels to avoid race conditions. 2. Prefer unbuffered channels for synchronous communication to ensure sender-receiver coordination unless there is a specific need for buffering, such as improving performance in a worker pool or signaling completion without blocking, but avoid excessive buffering to prevent memory issues. 3. Always close channels only from the sender side when no more data will be sent, enabling range loops to terminate properly, and never close a channel from the receiver side or multiple times; use sync.WaitGroup for multiple senders and never attempt to close receive-only channels. 4. Use select to multiplex operations across multiple channels, enabling timeout handling with time.After, managing multiple worker outputs, and non-blocking communication using default cases to avoid deadlocks. 5. Avoid common pitfalls such as sending on closed channels or closing them twice—both cause panics—always check the second value in a receive operation to detect closure, and prevent goroutine leaks by ensuring proper exit conditions using context cancellation or done channels. 6. Prefer combining channels with context.Context for cancellation in long-running goroutines, allowing clean shutdowns through ctx.Done(), making concurrent programs more robust, structured, and testable. Effectively using Go channels means focusing on data flow and signaling to structure program logic, ensuring safe and maintainable concurrency through disciplined use of send, receive, close, select, and termination planning.

Go channels are a powerful feature for handling communication and synchronization between goroutines. Used correctly, they make concurrent programs easier to write, read, and maintain. Here’s how to use them effectively.

1. Use channels for goroutine coordination and data flow

Channels are designed to pass data between goroutines safely. Instead of using shared variables and mutexes, use channels to communicate by sharing memory via communication, not by sharing memory via communication.

Example: Worker pattern

func worker(tasks <-chan int, results chan<- int) {
    for task := range tasks {
        results <- task * task
    }
}

func main() {
    tasks := make(chan int, 10)
    results := make(chan int, 10)

    // Start workers
    go worker(tasks, results)
    go worker(tasks, results)

    // Send tasks
    for i := 0; i < 5; i   {
        tasks <- i
    }
    close(tasks)

    // Collect results
    for i := 0; i < 5; i   {
        fmt.Println(<-results)
    }
}

This pattern avoids race conditions and makes data flow explicit.

2. Prefer unbuffered channels unless you have a reason not to

Unbuffered channels (created with make(chan T)) provide synchronous communication: the sender blocks until the receiver is ready. This ensures coordination and helps avoid subtle timing bugs.

Use buffered channels (make(chan T, N)) only when:

• You need to decouple sender and receiver temporarily (e.g., for performance).
• You’re implementing a worker pool with a backlog.
• You’re signaling completion without blocking (e.g., done := make(chan bool, 1)).

But be cautious: too much buffering hides backpressure and can lead to memory bloat or missed signals.

3. Always close channels when appropriate — and know when not to

Close a channel only from the sender side, and only if the receiver needs to know that no more data is coming. Closing allows range loops to terminate.

go func() {
    defer close(results)
    for _, task := range tasks {
        results <- process(task)
    }
}()

for result := range results {
    fmt.Println(result)
}

Never close a channel from the receiver, and never close a channel multiple times. If multiple senders exist, use a sync.WaitGroup or another coordination mechanism before closing.

Also: don’t close receive-only channels — Go won’t let you anyway.

4. Use select for multiplexing and timeouts

When dealing with multiple channels, select lets you wait on multiple operations without blocking unnecessarily.

Example: Timeout pattern

select {
case result := <-ch:
    fmt.Println("Received:", result)
case <-time.After(2 * time.Second):
    fmt.Println("Timeout")
}

Example: Handling multiple workers

select {
case msg1 := <-ch1:
    fmt.Println("From worker 1:", msg1)
case msg2 := <-ch2:
    fmt.Println("From worker 2:", msg2)
}

You can also use default in select for non-blocking attempts:

select {
case ch <- "work":
    fmt.Println("Sent work")
default:
    fmt.Println("Channel full, skipping")
}

5. Avoid common pitfalls

• Don’t send on a closed channel → panic.
• Don’t close a channel twice → panic.
• Don’t ignore received values — use the second value in comma-ok to detect closure:

  if val, ok := <-ch; ok {
      fmt.Println(val)
  } else {
      fmt.Println("Channel closed")
  }

• Don’t leak goroutines — always ensure receivers or senders can exit. Use context cancellation or close signals:

  ctx, cancel := context.WithCancel(context.Background())
  go worker(ctx, ch)
  cancel() // signals worker to stop

6. Prefer context with channels for cancellation

For long-running goroutines, combine channels with context.Context to allow clean shutdown.

func worker(ctx context.Context, data <-chan int) {
    for {
        select {
        case <-ctx.Done():
            fmt.Println("Shutting down")
            return
        case val := <-data:
            fmt.Println("Processing:", val)
        }
    }
}

This makes your concurrent code more robust and testable.

Effectively using Go channels means thinking in terms of data flow and signaling, not just concurrency. Use them to structure your program’s logic, not just to pass values. With good discipline, channels make Go’s concurrency model elegant and safe.

Basically: send, receive, close from the right side, use select, and always plan for termination.

The above is the detailed content of How to effectively use Go channels for communication. For more information, please follow other related articles on the PHP Chinese website!