Можно ли писать в закрытый канал?

Ответ

Нет, записывать данные в закрытый канал в Go нельзя. При попытке отправки значения в закрытый канал возникает паника (panic), которая приведёт к аварийному завершению программы (если только паника не будет восстановлена с помощью recover).

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

1. Что происходит при записи в закрытый канал

При выполнении операции отправки ch <- value в канал ch, который уже был закрыт с помощью close(ch), рантайм Go немедленно вызывает panic. Это защитный механизм, предотвращающий гонки данных (data races) и неопределённое поведение программы.

Пример, вызывающий панику:

package main

func main() {
    ch := make(chan int, 2)
    ch <- 1
    close(ch) // Закрываем канал
    
    // Попытка записи в закрытый канал вызывает panic:
    // "panic: send on closed channel"
    ch <- 2 
}

2. Почему это запрещено: философия дизайна Go

Запрет на отправку в закрытый канал связан с несколькими ключевыми принципами:

• Предотвращение скрытых гонок данных: Если бы отправка в закрытый канал была разрешена, могли бы возникнуть ситуации, когда одна горутина закрывает канал, а другая продолжает в него писать, не зная о закрытии.
• Явность и безопасность: Операция закрытия канала должна быть чётким сигналом "общения завершены", после которого все отправители должны прекратить попытки отправки.
• Идиоматика "закрытия для вещания": В Go закрытие канала используется как сигнал всем получателям о том, что больше данных не будет. Разрешение записи после этого ломает данную семантику.

3. Как безопасно работать с каналами

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

Пример безопасного использования:

package main

import (
    "fmt"
    "sync"
)

func sender(ch chan<- int, wg *sync.WaitGroup) {
    defer wg.Done()
    defer close(ch) // Закрываем канал ТОЛЬКО после отправки всех данных
    
    for i := 0; i < 5; i++ {
        ch <- i
    }
}

func receiver(ch <-chan int, wg *sync.WaitGroup) {
    defer wg.Done()
    
    for {
        value, ok := <-ch
        if !ok {
            fmt.Println("Канал закрыт, приём завершён")
            return
        }
        fmt.Printf("Получено: %d\n", value)
    }
}

func main() {
    ch := make(chan int, 2)
    var wg sync.WaitGroup
    
    wg.Add(2)
    go sender(ch, &wg)
    go receiver(ch, &wg)
    
    wg.Wait()
}

4. Паттерны избежания паники

На практике используются несколько подходов для предотвращения отправки в закрытый канал:

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

var closeOnce sync.Once

func safeClose(ch chan int) {
    closeOnce.Do(func() {
        close(ch)
    })
}

1. Отправка через select с проверкой состояния канала (более сложный паттерн):

func safeSend(ch chan<- int, value int) (sent bool) {
    defer func() {
        if r := recover(); r != nil {
            sent = false // Отправка не удалась из-за закрытого канала
        }
    }()
    
    select {
    case ch <- value:
        return true
    default:
        return false
    }
}

1. Использование контекста для отмены операций (наиболее идиоматичный способ в современных Go-программах):

func senderWithCancel(ctx context.Context, ch chan<- int) {
    for i := 0; ; i++ {
        select {
        case ch <- i:
            // Успешная отправка
        case <-ctx.Done():
            close(ch) // Закрываем канал, когда контекст отменён
            return
        }
    }
}

5. Особенности чтения из закрытого канала

В отличие от записи, чтение из закрытого канала полностью безопасно:

• Можно бесконечно читать нулевые значения типа канала
• Операция val, ok := <-ch возвращает ok = false, когда канал закрыт И опустошён
• Закрытый канал никогда не блокирует операцию чтения

Выводы

1. Запись в закрытый канал всегда вызывает panic — это фундаментальное правило Go.
2. Закрывать канал должен только отправитель, и делается это когда гарантированно больше не будет отправок.
3. Правильная работа с каналами требует соблюдения паттернов синхронизации (sync.WaitGroup, context.Context, select).
4. Эта особенность Go способствует написанию более надёжного конкурентного кода, явно разделяя ответственность между горутинами.

Такое поведение может показаться строгим, но оно предотвращает целый класс сложноотлаживаемых ошибок в многопоточных программах и соответствует философии Go: "явное лучше неявного".