Что произойдет, если писать в канал после закрытия?

Исчерпывающий ответ о записи в закрытый канал в Go

Если попытаться выполнить операцию записи в закрытый канал (channel), произойдет паника (panic), которая приведет к аварийному завершению программы (если паника не будет восстановлена). Это фундаментальное правило безопасности каналов в Go, предотвращающее неопределенное поведение и race conditions.

Подробное объяснение

В Go каналы имеют три основных состояния: открытый, закрытый и nil. Поведение при операциях с ними различается:

package main

func main() {
    ch := make(chan int, 2)
    
    // Нормальная работа с открытым каналом
    ch <- 1
    ch <- 2
    
    // Закрываем канал
    close(ch)
    
    // Попытка записи в закрытый канал ВЫЗОВЕТ ПАНИКУ
    ch <- 3 // panic: send on closed channel
}

Почему это спроектировано именно так?

1. Предотвращение race conditions - если бы запись в закрытый канал просто игнорировалась или возвращала ошибку, отправители могли бы продолжать "слепую" отправку данных, не зная, что получатели перестали их читать.

2. Явность и безопасность - такое поведение заставляет разработчиков явно управлять жизненным циклом каналов и обрабатывать их закрытие корректно.

3. Согласованность с select - в конструкции select операция отправки на закрытый канал также вызывает панику.

Правильные паттерны работы с каналами

1. Использование defer для закрытия

func producer(ch chan<- int) {
    defer close(ch) // Гарантированное закрытие при выходе
    for i := 0; i < 5; i++ {
        ch <- i
    }
}

2. Отправка через горутину с recover

func safeSend(ch chan<- int, value int) {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("Не удалось отправить %d: канал закрыт", value)
        }
    }()
    ch <- value
}

3. Использование контекста для отмены операций

func worker(ctx context.Context, ch chan<- int) {
    for {
        select {
        case <-ctx.Done():
            // Контекст отменен, прекращаем отправку
            return
        case ch <- doWork():
            // Нормальная отправка
        }
    }
}

Сравнение с чтением из закрытого канала

Важно отметить различие в поведении:

• Чтение из закрытого канала - возвращает нулевое значение типа и false как второе возвращаемое значение
• Запись в закрытый канал - всегда вызывает панику

ch := make(chan int, 1)
ch <- 1
close(ch)

value, ok := <-ch // ok = true, value = 1
value, ok = <-ch  // ok = false, value = 0 (zero value для int)

ch <- 2 // PANIC: send on closed channel

Распространенные антипаттерны

1. Закрытие канала отправителем без синхронизации:

// НЕПРАВИЛЬНО - может привести к панике
go func() {
    for i := range ch {
        // обработка
    }
    close(ch) // Закрываем канал в получателе
}()

1. Неопределенный владелец канала - канал должен закрываться тем, кто его создал, или иметь явно определенного "владельца".

Практические рекомендации

• Принцип ответственности: чётко определяйте, какая горутина отвечает за закрытие канала
• Используйте sync.Once если канал нужно закрыть только один раз из нескольких мест
• Проверяйте состояние канала в отправителях через дополнительный канал сигнализации
• Проектируйте пайплайны так, чтобы каждый этап закрывал свой выходной канал после завершения работы

Заключение

Запись в закрытый канал в Go - это ошибка времени выполнения, приводящая к панике. Это сознательное дизайнерское решение, которое обеспечивает безопасность конкурентных программ. Правильное управление жизненным циклом каналов через контексты, defer и четкое распределение ответственности между горутинами позволяет избежать этой проблемы и создавать надежные concurrent-приложения.