Answer.

History of the question:

Channels (chan) are a key tool for data exchange between goroutines and synchronization of concurrent processes, which distinctly sets Go apart from other languages. They are designed for thread-safe data transmission.

Problem:

Without a proper understanding of how channels work, developers often encounter deadlocks, unexpected blocks, non-obvious errors when closing a channel, and data loss (race conditions).

Solution:

It is essential to clearly understand how to declare, use, and close channels. Decide when to use buffered/unbuffered channels, and keep track of who and when should close the channel to avoid "everything is stuck."

Code example:

func producer(ch chan<- int) { // only sending
    for i := 0; i < 5; i++ { ch <- i }
    close(ch)
}

func consumer(ch <-chan int) { // only reading
    for v := range ch {
        fmt.Println(v)
    }
}

func main() {
    ch := make(chan int)
    go producer(ch)
    consumer(ch)
}

Key features:

A channel can only be closed from the side where there are "no" more senders.
Reading from a closed channel returns zero value; writing causes a panic.
Channels can be buffered or unbuffered — their behaviors differ greatly.

Tricky questions.

What happens when trying to write to a closed channel?

A panic will occur. A common mistake is closing a channel on the reader's side or allowing writes to a channel after it has been closed.

Is it safe to check if a channel is closed?

No, there is no direct check. You need to design channel lifecycle management correctly, or use the second parameter when reading (v, ok := <-ch), which becomes false when the channel is closed.

Is a channel thread-safe by itself?

A channel is thread-safe for transmitting data between goroutines. However, if multiple goroutines write to one channel without coordination, it can lead to issues (possibly premature closing).

Typical mistakes and anti-patterns

Inconsistent management of channel closing/opening: closing from the wrong side, "duplicate" closing
Attempts to read/write to a channel after it has been closed
Using one channel with multiple senders without coordination

Real-life example

Negative case

A project with several producers and one consumer: each producer closed the channel, resulting in a panic at runtime due to double closing, and data was lost.

Pros:

The "fan-in" pattern was quickly implemented.

Cons:

Leaks, race conditions, complex debugging.

Positive case

Only one thread was used to close the channel, while producers signaled completion through a separate WaitGroup. The channel was used solely for passing results.