Ловушки каналов в Go

Громкая половина: паники

Три операции паникуют, и тексты у них разные - по ним удобно опознавать проблему в логе. Отправка в закрытый канал: send on closed channel. Повторное закрытие: close of closed channel. Закрытие nil-канала: close of nil channel. Все три проверены и все три - обычные паники, которые ловит recover.

Заметь асимметрию: приём из закрытого канала абсолютно безопасен и просто отдаёт нулевое значение, а отправка в него паникует. Логика в том, что закрытие означает «данных больше не будет», и читатели должны об этом узнать штатно, а вот писатель, который пишет после закрытия, явно ошибся в собственной логике.

Отсюда правило про право закрытия. Закрывает отправитель, потому что только он знает, что поток кончился. Отправителей несколько - не закрывает никто из них, закрывает отдельная горутина после WaitGroup.

// Ловить эти паники через recover - плохое лечение. Они означают ошибку в устройстве программы, а не внешний сбой, и перехват просто спрячет её до следующего раза.

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

ch <- 1        // panic: send on closed channel
close(ch)      // panic: close of closed channel

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

Тихая половина: вечная блокировка

Операции с nil-каналом не паникуют - они блокируются навсегда. И приём, и отправка. Ошибка тут обычная: объявили var ch chan int вместо make, и всё внешне работает, просто ничего не происходит.

Иногда рантайм спасает. Если заблокированы вообще все горутины, он замечает это и печатает fatal error: all goroutines are asleep - deadlock! вместе с состоянием каждой горутины - в нашем случае chan receive (nil chan). Очень удобно.

Но это работает только когда спят все. В реальном сервисе всегда есть работающая горутина - HTTP-сервер, планировщик, сборщик метрик - и тогда рантайм молчит. Заблокированная горутина просто остаётся висеть, держит свой стек и всё, на что ссылается.

// Тот же тихий эффект даёт незакрытый канал: range на другой стороне ждёт закрытия, которого не будет. И небуферизованный канал без готового получателя: отправитель блокируется на первой же строчке, а его никто не ждёт.

deadlock-детектор

рантайм роняет процесс, только если СПЯТ ВСЕ горутины; частичную блокировку он не видит

Как не наступать

Первое: право закрытия принадлежит одной стороне и записано в сигнатуре. Функция возвращает <-chan T - значит она же и закроет. Направленные типы каналов делают это правило проверяемым компилятором, а не устной договорённостью.

Второе: у каждой блокирующей операции должен быть выход. Отправка и приём в долгоживущем коде идут через select с веткой ctx.Done() либо с таймаутом. Тогда блокировка «навсегда» превращается в блокировку «до отмены».

Третье: канал создаётся через make в момент создания владельца, а не остаётся нулевым полем структуры. Половина nil-каналов в проде - это забытая инициализация поля, которую компилятор поймать не может.

// И проверка, которая ловит остальное: гонки ищутся сборкой с -race, а зависшие горутины - дампом стеков. Оба инструмента штатные и включаются одной строкой, о них подробнее в теме про утечки.

Как отвечать: «Что произойдёт при отправке в закрытый канал и при работе с nil-каналом?»

Это два разных класса проблем, и разница принципиальна. Отправка в закрытый канал паникует с текстом send on closed channel - это обычная паника, её видно в логе и её ловит recover, хотя ловить тут нечего: она означает ошибку в устройстве программы. Туда же относятся повторное закрытие и закрытие nil-канала, тексты у них свои. При этом приём из закрытого канала полностью безопасен - возвращает нулевое значение и ok равное false. Асимметрия осмысленная: закрытие означает «данных больше не будет», читатели узнают об этом штатно, а писатель после закрытия явно ошибся. С nil-каналом всё наоборот и хуже: и приём, и отправка блокируются навсегда, молча. Если случайно заблокировались все горутины, рантайм напишет fatal error про deadlock и даже покажет состояние chan receive nil chan. Но если хоть одна горутина работает - а в сервисе всегда работает - никакого сообщения не будет, горутина просто повиснет вместе со всей памятью, на которую ссылается. Поэтому в долгоживущем коде я не пишу голых блокирующих операций: всё через select с ctx.Done() или таймаутом.

Два класса разведены по симптому и по опасности, названы точные тексты ошибок, объяснена асимметрия закрытия и дан предел работы deadlock-детектора - последнее знают немногие.

На чём валят

• −Отправляют в закрытый канал: паника send on closed channel и упавший процесс.
• −Закрывают канал дважды или закрывают nil-канал - тоже паника.
• −Забывают make и получают nil-канал: всё висит молча, без единой ошибки.
• −Рассчитывают, что рантайм поймает любую вечную блокировку - он видит только сон всех горутин.
• −Пишут голые блокирующие отправки в долгоживущем коде без ветки отмены.
• −Ловят паники каналов через recover вместо того, чтобы починить право закрытия.