> Как послать сигнал в канал, чтобы все горутины получили уведомление о завершении работы в Go (Go)

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

Самый простой способ - закрыть канал через close(ch). Все горутины, читающие из этого канала, получат zero value и флаг ok == false в операции v, ok := <-ch. Это broadcast-уведомление: закрытие канала рассылает сигнал всем читателям без ограничения на количество получателей. Альтернатива - отдельный канал done с struct{}, который закрывается один раз. Важно: сигнал нельзя "послать" через запись в канал так, чтобы его получили все - запись получает только одна горутина.

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

В Go каналы - это механизм синхронизации, а не broadcast-шина. Запись в канал ch <- value доставляет значение ровно одному читателю. Если нужно уведомить N горутин, запись не подходит: потребуется N записей и N чтений, плюс синхронизация, чтобы никто не остался без сигнала.

Закрытие канала решает задачу иначе. Когда канал закрыт, любое чтение из него немедленно возвращает zero value для типа канала и false для второго возвращаемого значения. Это работает для любого количества читающих горутин: каждая получит сигнал независимо. При этом не важно, читают ли горутины в этот момент или заблокированы на <-ch - они проснутся.

Ключевые свойства:

• close(ch) - идемпотентно только в том смысле, что повторный close вызывает panic. Поэтому закрытие должно выполняться ровно один раз, обычно через sync.Once или в defer в главной горутине.
• Читатель должен проверять ok, чтобы отличить данные от сигнала завершения.
• Если канал буферизован, закрытие не теряет уже записанные данные - читатели сначала получат их, а потом сигнал.
• Паттерн "done channel" - это канал типа chan struct{}, потому что struct{} не занимает память и семантически означает "событие, а не данные".

Почему это работает для всех горутин: закрытие канала - это операция над самим каналом, а не над конкретным получателем. Runtime Go помечает канал как закрытый, и все последующие операции чтения возвращают zero value. Это гарантировано спецификацией языка.

На практике

В реальном коде чаще всего используется именно done channel с close. Например, для graceful shutdown: главная горутина ждёт сигнал от ОС, закрывает done, и все воркеры, читающие из done, завершают свою работу.

Важные нюансы:

• Если горутина слушает несколько каналов, используйте select с case <-done.
• Не закрывайте канал, если есть риск, что кто-то ещё попытается в него записать - это вызовет panic. Для этого нужен отдельный канал только для сигнала.
• Если нужно уведомить о завершении и дождаться, пока все горутины закончат, комбинируйте close(done) с sync.WaitGroup.
• Для отмены долгих операций (например, HTTP-запросов) используйте context.Context - внутри он работает как done channel, но предоставляет дополнительные возможности (deadline, значения).

Типичный сценарий: пул воркеров, каждый в цикле слушает jobs и done. При close(done) воркеры выходят из цикла, вызывают wg.Done(), и главная горутина завершает программу.

Пример кода

GO
package main

import (
    "fmt"
    "sync"
    "time"
)

func worker(id int, done <-chan struct{}, wg *sync.WaitGroup) {
    defer wg.Done()
    for {
        select {
        case <-done:
            fmt.Printf("worker %d: received shutdown signal\n", id)
            return
        default:
            // имитация работы
            fmt.Printf("worker %d: working\n", id)
            time.Sleep(100 * time.Millisecond)
        }
    }
}

func main() {
    done := make(chan struct{})
    var wg sync.WaitGroup

    for i := 1; i <= 3; i++ {
        wg.Add(1)
        go worker(i, done, &wg)
    }

    time.Sleep(300 * time.Millisecond)
    close(done) // broadcast-сигнал всем горутинам
    wg.Wait()
    fmt.Println("all workers finished")
}

Как отвечать на собеседовании

Начните с прямого ответа: "закрыть канал". Затем объясните, почему запись не подходит - она доставляет значение только одному получателю. Покажите понимание семантики close: все читатели получают zero value и ok == false. Упомяните паттерн done channel с chan struct{} и комбинацию с sync.WaitGroup для ожидания завершения.

Если спросят про альтернативы, скажите про context.WithCancel - это более высокоуровневый механизм, но внутри он использует тот же принцип. Подчеркните, что закрытие канала - это единственный встроенный способ broadcast-уведомления в Go.

Хорошо добавить пример из практики: graceful shutdown HTTP-сервера или пула воркеров. Покажите, что понимаете проблему повторного close и решаете её через sync.Once или структуру кода, где закрытие происходит ровно один раз.

Что проверяет интервьюер

Интервьюер проверяет:

• Понимание модели каналов в Go: запись - точка-точка, закрытие - broadcast.
• Знание идиоматического паттерна done channel.
• Умение избегать panic при повторном закрытии.
• Понимание разницы между буферизованными и небуферизованными каналами в контексте закрытия.
• Способность комбинировать примитивы синхронизации: каналы, sync.WaitGroup, sync.Once.

Для senior-уровня важно, чтобы вы не просто назвали close, а объяснили, почему это работает на уровне runtime, и какие есть подводные камни (например, запись в закрытый канал - panic).

Типичные ошибки

• Попытка "разослать" сигнал через запись в канал - получает только одна горутина.
• Повторный close - panic. Нужен sync.Once или гарантия однократного вызова.
• Чтение из закрытого канала без проверки ok - можно принять zero value за данные.
• Закрытие канала, в который ещё пишут - panic при записи. Нужен отдельный канал для сигнала.
• Использование close для передачи данных - это антипаттерн, данные должны идти через отдельный канал.
• Забывают про WaitGroup - главная горутина завершается раньше, чем воркеры успевают обработать сигнал.