Code Review

О чём этот блок

В этом блоке код писать почти не нужно: его уже написали, и он выглядит рабочим. Ваша задача — найти в нём ошибки, объяснить, почему это ошибки, и исправить минимальной правкой. Гонки данных, зависшие горутины, буфер, который отдали в фоновую горутину и тут же перезаписали, — всё это компилируется, проходит беглый просмотр и ломается только под нагрузкой или под -race.

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

Что понадобится

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

Задачи

Начните с 22, затем переходите к 21: в ней ошибки разного рода и их больше.

• 22 · Параллельный HTTP-воркер с кэшированием — воркеры без синхронизации пишут в общий срез результатов и в кэш; кроме того, два воркера с одинаковым id не должны оба идти в API.
• 21 · Сервис агрегации метрик — гонка данных, утечка фоновой горутины и буфер, который одновременно передан в Save и перезаписывается.

Что прочитать

• Утечки горутин и гонки — реальный отчёт -race и как его читать, поиск утечек тестом.
• Модель памяти и happens-before — чем гонка данных отличается от логической гонки.

// Типичная находка ревью: append в общий срез из нескольких горутин.
go func(id int) {
    results = append(results, fetch(id)) // гонка: нет синхронизации
}(id)
// Исправление: mu.Lock()/Unlock() вокруг append или сбор через канал.