Краткий ответ

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

Исторический контекст

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

Модель каналов Go позволяет представить такое событие как изменение состояния общего объекта. После закрытия канала любой текущий или будущий получатель может узнать, что дальнейших значений не будет, без отдельного сообщения для каждой горутины.

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

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

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

Подробное решение

После close(ch) операция получения из ch становится готовой для всех ожидающих горутин. При обычном чтении возвращается нулевое значение типа канала; при двухзначном чтении второй результат равен false, что позволяет отличить закрытие от получения настоящего нулевого значения.

Закрытие не помещает специальное значение в канал и не является отправкой. Оно меняет состояние канала: новых отправок быть не может, а получения либо забирают оставшиеся буферизованные значения, либо сразу сообщают об окончании.

Закрытый канал также постоянно готов в соответствующей ветви select. Это удобно для сигнала остановки: каждая рабочая горутина может одновременно ждать работу и уведомление о завершении.

Ключевые ограничения:

закрыть канал можно только один раз;
отправка в закрытый канал вызывает панику;
закрытие nil-канала вызывает панику;
закрытие не дожидается завершения горутин и не заменяет WaitGroup;
канал обычно закрывает сторона, которая производит значения или управляет завершением, а не произвольный получатель.

Минимальный пример широковещательного уведомления:

package main

import (
	"fmt"
	"sync"
)

func main() {
	stop := make(chan struct{})
	var wg sync.WaitGroup
	for i := 0; i < 3; i++ {
		wg.Add(1)
		go func(id int) {
			defer wg.Done()
			<-stop
			fmt.Println(id)
		}(i)
	}
	close(stop)
	wg.Wait()
}

Все три горутины разблокируются после одного close(stop). Канал типа chan struct{} выбран потому, что данные передавать не нужно: важен только факт наступления события.

Ситуация из практики

Сервис запускает набор рабочих горутин и при остановке должен прекратить ожидание новых задач. Вариант с отправкой отдельного сигнала каждой горутине требует поддерживать точное число получателей и может оставить часть горутин заблокированной. Общая переменная-флаг с периодической проверкой уменьшает связанность с каналом, но требует синхронизации и создаёт задержку из-за опроса.

Для локального сигнала завершения выбран отдельный канал остановки, который закрывается координатором. Рабочие горутины ожидают задачи через select одновременно с чтением из этого канала, поэтому после закрытия немедленно прекращают работу. WaitGroup затем используется отдельно, чтобы дождаться фактического завершения рабочих горутин.

Если остановка должна передаваться через границы функций и сопровождаться дедлайном или причиной отмены, практичнее использовать context.Context. Закрытие канала хорошо подходит для простого однонаправленного широковещательного сигнала внутри компонента, но само по себе не хранит причину, дедлайн или ошибку.

Что кандидаты часто упускают

Что произойдёт, если закрыть буферизованный канал с оставшимися значениями?

Закрытие запрещает новые отправки, но не удаляет уже помещённые в буфер значения. Получатели сначала извлекут все эти значения в обычном порядке, а после опустошения буфера будут получать нулевое значение и false при двухзначном чтении. Поэтому закрытие означает отсутствие будущих отправок, а не немедленную потерю накопленных данных.
Гарантирует ли закрытие канала, что работа всех получателей уже завершена?

Нет. Оно гарантирует только разблокирование операций получения и доступность уведомления о завершении. После этого горутины могут ещё выполнять очистку, сохранять результаты или освобождать ресурсы. Для ожидания их фактического завершения нужен отдельный механизм, например sync.WaitGroup.
Что случится, если две горутины могут одновременно закрыть один канал?

Одна из них успешно закроет канал, а вторая вызовет панику при попытке повторного закрытия. Необходимо передать право закрытия одному координатору либо синхронизировать эту операцию, например с помощью sync.Once. При этом sync.Once защищает сам факт однократного вызова, но не решает вопрос, действительно ли выбранная горутина владеет жизненным циклом канала.