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

Race detector обнаруживает динамическую гонку данных: конфликтующие обращения к одной памяти, среди которых хотя бы одно является записью, не упорядоченные механизмом синхронизации. Такой отчёт означает, что в конкретном выполнении программы обнаружен доступ без установленной связи happens-before, поэтому результат может зависеть от планирования горутин.

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

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

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

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

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

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

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

package counter

import (
    "sync"
    "testing"
)

func TestCounter(t *testing.T) {
    var n int
    var wg sync.WaitGroup
    wg.Add(2)
    for i := 0; i < 2; i++ {
        go func() {
            defer wg.Done()
            n++
        }()
    }
    wg.Wait()
}

Запуск такого теста с race detector может сообщить о конфликтующих обращениях к n, даже если итоговое значение иногда оказывается ожидаемым.

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

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

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

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

Проверка запускается с флагом -race, например через go test -race. Она динамическая: неисполненная ветка не анализируется. Инструмент заметно увеличивает время выполнения и потребление памяти, поэтому его обычно применяют в тестах и CI, но не используют как замену обычному запуску или нагрузочному тестированию.

Race detector не обнаруживает логические гонки, если доступы формально синхронизированы, но порядок действий всё равно неверен. Он также не заменяет проверку deadlock, starvation, неправильной гранулярности блокировок и ошибок в протоколе обмена данными.

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

В HTTP-сервисе тесты начали периодически падать после добавления параллельной загрузки конфигурации. Race detector указал на карту кэша: один обработчик читал её, пока другой добавлял запись.

Рассматривались три варианта. Глобальный mutex был простым и надёжным, но увеличивал конкуренцию при частых чтениях. sync.Map уменьшал необходимость ручной блокировки, однако усложнял типизацию и не подходил для всех операций над связанными данными. Третьим вариантом была публикация полностью построенной неизменяемой копии конфигурации через атомарную замену.

Выбрали третий вариант, потому что конфигурация редко обновлялась, а чтения преобладали. После построения новой копии сервис атомарно публиковал её, а читатели работали только с неизменяемыми данными. Тесты с -race перестали сообщать о конфликте, а блокировки из горячего пути чтения исчезли.

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

1. Достаточно ли вызвать WaitGroup.Wait, чтобы устранить гонку при записи в общую переменную?

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

2. Считает ли race detector любую параллельную работу с одной переменной ошибкой?

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

3. Гарантирует ли отсутствие отчётов при -race отсутствие гонок в программе?

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