Что нельзя делать с каналом?

Основные ограничения и запрещённые операции с каналами в Go

Каналы в Go — это мощный механизм для коммуникации между горутинами и синхронизации, но с ними связан ряд жёстких ограничений, нарушение которых приводит к панике, блокировкам или неопределённому поведению программы.

1. Закрытие закрытого канала

Повторное закрытие уже закрытого канала вызывает немедленную панику (panic). Это одна из самых частых ошибок.

ch := make(chan int)
close(ch)
close(ch) // panic: close of closed channel

Решение: Используйте sync.Once или проверяйте статус через recover.

var closeOnce sync.Once
closeOnce.Do(func() { close(ch) })

2. Отправка данных в закрытый канал

Попытка отправить значение в закрытый канал также приводит к панике.

ch := make(chan int)
close(ch)
ch <- 42 // panic: send on closed channel

Решение: Организуйте логику так, чтобы отправляющая горутина либо точно знала состояние канала, либо использовала select с default.

3. Закрытие канала nil

Попытка закрыть nil-канал вызывает панику.

var ch chan int
close(ch) // panic: close of nil channel

Решение: Всегда инициализируйте каналы через make.

4. Чтение/отправка через nil-канал

Операции чтения из или отправки в nil-канал блокируются навсегда. Это не паника, но это приводит к deadlock (который детектируется рантаймом Go, если все горутины заблокированы).

var ch chan int
<-ch       // Блокировка навсегда (deadlock)
ch <- 42   // Блокировка навсегда (deadlock)

Решение: Всегда инициализируйте каналы. Используйте конструкцию make(chan тип, [буфер]).

5. Использование неподходящих типов данных

Каналы типизированы. Отправка значения несовместимого типа приведёт к ошибке компиляции.

ch := make(chan int)
ch <- "строка" // Ошибка компиляции: cannot use "строка" (type string) as type int in send

6. Некорректное использование односторонних каналов

Односторонние каналы (chan<- тип только для отправки, <-chan тип только для чтения) вводят ограничения на этапе компиляции. Попытка выполнить запрещённую операцию приведёт к ошибке компиляции.

func sender(ch chan<- int) {
    <-ch // Ошибка компиляции: invalid operation: <-ch (receive from send-only type chan<- int)
}

7. Игнорирование возможности блокировки (без select и default)

Если канал не буферизованный, операция отправки блокируется, пока другая горутина не готова принять данные, и наоборот. Использование таких операций в единственной горутине приводит к deadlock.

ch := make(chan int) // Небуферизованный канал
ch <- 1              // Блокировка здесь, если нет другой горутины, читающей из ch
fmt.Println(<-ch)    // Эта строка никогда не выполнится

Решение: Всегда организовывайте взаимодействие как минимум двух горутин или используйте буферизованные каналы.

8. Неправильное использование for range по каналу

Цикл for range по каналу будет выполняться, пока канал не будет закрыт. Если канал никогда не закрыть, цикл может привести к утечке горутин (ожидание вечно). Кроме того, range по nil-каналу заблокируется навсегда.

ch := make(chan int)
go func() {
    for v := range ch { // Этот цикл не завершится, т.к. канал не закрыт
        fmt.Println(v)
    }
}()
// Если не выполнить close(ch), горутина останется заблокированной

Решение: Чётко определяйте, кто и когда закрывает канал. Используйте контексты (context.Context) для отмены операций.

9. Сравнение каналов на равенство

Каналы являются сравниваемыми типами (можно использовать == и !=). Однако их сравнение редко имеет смысл и может быть источником ошибок. Канал равен nil или другому каналу только если они ссылаются на один и тот же объект в памяти.

ch1 := make(chan int)
ch2 := ch1
fmt.Println(ch1 == ch2) // true, это один и тот же канал
fmt.Println(ch1 == make(chan int)) // false, это разные каналы

Важно: Не используйте сравнение каналов как замену логике закрытия/состояния.

10. Пренебрежение блокирующей природой в select

В конструкции select без блока default выполняется случайный неблокирующий переход. Если же все case блокируют, то select будет ждать, пока один из них не разблокируется. Отсутствие default может привести к неявной блокировке.

select {
case <-ch1:
    // ...
case <-ch2:
    // ... // Если ch1 и ch2 не готовы, select заблокируется здесь
}

Рекомендация: Добавляйте default для неблокирующих операций или таймауты с помощью time.After.

Итог и лучшие практики

• Всегда инициализируйте каналы.
• Закрывайте канал только один раз, желательно в горутине-отправителе (принцип "закрывает отправитель").
• Для избежания паники используйте паттерны (например, sync.Once для закрытия, context для отмены).
• Используйте буферизацию осознанно, чтобы избежать ненужных блокировок.
• Предпочитайте select с таймаутами или default для операций, которые не должны блокироваться надолго.
• Помните, что for range по каналу требует его последующего закрытия.

Нарушение этих правил ведёт к типичным ошибкам Go-программ: deadlock, panic и утечкам горутин (goroutine leak). Понимание этих ограничений критично для написания надёжного конкуррентного кода.