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

Передача значения через канал создаёт отношение happens-before: запись, выполненная до отправки, считается произошедшей до чтения, выполненного после получения. Поэтому race detector не должен считать эти два доступа гонкой, если между ними действительно существует такой порядок.

Канал не делает произвольные обращения к памяти безопасными. Он синхронизирует только те действия, для которых отправка и получение образуют необходимую связь; другие чтения и записи всё ещё могут конфликтовать.

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

Race detector нужен для поиска динамических гонок — ситуаций, когда несколько горутин обращаются к одной памяти, хотя бы один доступ является записью, а порядок между ними не установлен механизмом синхронизации.

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

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

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

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

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

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

Эта цепочка устанавливает порядок между записью и чтением. Race detector распознаёт канал как средство синхронизации и не сообщает о гонке для таких доступов.

Минимальный пример:

package main

import "fmt"

func main() {
    var value int
    ready := make(chan struct{})
    go func() {
        value = 42
        ready <- struct{}{}
    }()
    <-ready
    fmt.Println(value)
}

После получения из ready основная горутина читает value уже после записи в другой горутине. Однако канал не защищает последующие изменения автоматически: если после отправки одна горутина снова изменит value, а другая одновременно начнёт его читать, новая пара доступов может быть гонкой.

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

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

Сервис запускал рабочую горутину, которая заполняла общий результат, после чего отправляла уведомление в канал. Основная горутина получала уведомление и читала результат; race detector не находил гонку, поскольку канал правильно задавал порядок публикации результата.

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

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

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

Достаточно ли получения из канала, чтобы считать завершённой всю работу отправляющей горутины?

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

Что меняется, если канал буферизованный?

Буфер не отменяет синхронизацию между отправкой конкретного значения и его получением. Но отправитель может завершить отправку, не дожидаясь немедленного получателя, поэтому сам факт успешной отправки не означает, что другая горутина уже прочитала данные.

Почему отсутствие сообщения от race detector не доказывает корректность протокола?

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