Odpowiedź.

Historia pytania:

Kanały (chan) - kluczowe narzędzie do wymiany danych między gorutynami i synchronizacji procesów współbieżnych, co jednoznacznie wyróżnia Go spośród innych języków. Są przeznaczone do organizacji bezpiecznego przesyłania danych.

Problem:

Bez właściwego zrozumienia budowy kanałów deweloperzy często napotykają na deadlocki, nieoczekiwane zablokowania, nieoczywiste błędy przy zamykaniu kanału oraz utratę danych (race condition).

Rozwiązanie:

Należy dokładnie rozumieć jak ogłaszać, używać, zamykać kanały. Decydować, kiedy używać kanałów buforowanych/niebuforowanych i monitorować, kto i kiedy powinien zamknąć kanał, aby uniknąć "wszystko zacięte".

Przykład kodu:

func producent(ch chan<- int) { // tylko wysyłanie
    for i := 0; i < 5; i++ { ch <- i }
    close(ch)
}

func konsument(ch <-chan int) { // tylko odczyt
    for v := range ch {
        fmt.Println(v)
    }
}

func main() {
    ch := make(chan int)
    go producent(ch)
    konsument(ch)
}

Kluczowe cechy:

Kanał można zamykać tylko z tej strony, gdzie "nie ma" więcej nadawców.
Odczyt z zamkniętego kanału zwraca zero value, zapis wywołuje panikę.
Kanały mogą być buforowane lub niebuforowane - zachowanie znacznie się różni.

Pytania z pułapką.

Co się stanie, gdy spróbujesz zapisać do zamkniętego kanału?

Pojawi się panic. Często spotykanym błędem jest zamykanie kanału po stronie czytelnika lub pozwalanie na zapis do kanału po jego zamknięciu.

Czy można bezpiecznie sprawdzić, czy kanał jest zamknięty?

Nie, nie ma bezpośredniego sprawdzenia. Trzeba tylko właściwie projektować kontrolę nad życiem kanału lub używać drugiego parametru podczas odczytu (v, ok := <-ch), który stanie się false, gdy kanał jest zamknięty.

Czy kanał jest bezpieczny wątkowo sam w sobie?

Kanał - jest bezpieczny wątkowo do przesyłania danych między gorutynami. Ale jeśli kilka gorutyn zapisuje do jednego kanału, bez koordynacji może to prowadzić do problemów (możliwe przedwczesne zamknięcie).

Typowe błędy i antywzorce

Niespójne zarządzanie zamykaniem/otwieraniem kanału: zamykanie z niewłaściwej strony, "duplikujące" zamknięcie
Próby odczytu/zapisu do kanału po jego zamknięciu
Użycie jednego kanału przez wielu nadawców bez koordynacji

Przykład z życia

Negatywny przypadek

Projekt z wieloma producentami i jednym konsumentem: kanał był zamykany przez każdego producenta, w rezultacie - panic w czasie wykonywania przy próbie podwójnego zamknięcia, dane były tracone.

Zalety:

Szybko zrealizowany wzór "fan-in"

Wady:

Wycieki, race conditions, trudna debugowanie.

Pozytywny przypadek

Użyto tylko jeden wątek do zamknięcia kanału, a producenci przez osobną WaitGroup sygnalizowali zakończenie pracy. Kanał służył wyłącznie do przesyłania wyników.