Модуль 5 ⏱ ~27 мин чтения 📐 3 Mermaid диаграмм

42. Race Condition и Go Memory Model

«Цель абстракции — вовсе не расплывчатость, а создание нового семантического уровня, на котором можно достичь абсолютной точности».
— Эдсгер Дейкстра

Вплоть до этого момента мы изучали примитивы синхронизации и горутины, полагаясь на интуитивное житейское понимание времени. Нам кажется самоочевидным: если горутина А записала в память x = 1, а затем горутина Б прочитала x, то она обязана увидеть 1.

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

Чтобы разработчик распределенных систем не сошел с ума от плавающих и невоспроизводимых багов, создатели языка сформулировали четкий формальный контракт — Go Memory Model (Модель памяти Go).

1. Иллюзия последовательности (Mechanical Sympathy)

Представьте простой и невинный фрагмент кода:

A = 1
B = 2

Любой человек скажет, что переменная A получит единицу строго до того, как B получит двойку.
Но на уровне физического железа и машинного кода это иллюзия.

Почему порядок операций может нарушаться?

Оптимизация компилятора: Компилятор Go вправе поменять инструкции местами (Instruction Reordering), если решит, что это сэкономит регистры процессора или уменьшит задержки конвейера.
Out-of-Order Execution (Внеочередное выполнение): Современные процессоры (x86-64, ARM64) не исполняют команды строго по очереди. Они анализируют граф зависимостей инструкций и параллельно выполняют независимые ветки. Насколько это видно другим ядрам, зависит от архитектуры: на ARM64 и POWER другое ядро может увидеть B=2 раньше A=1; на x86-64 (модель TSO) записи видны в порядке выполнения, но запись может «отстать» от последующего чтения (перестановка store → load). Компилятор же вправе переставить обе записи на любой архитектуре.
Store Buffers и кэши процессора: Даже если процессор выполнил запись A = 1 первой, новое значение попадает не в оперативную память и даже не в кэш L1, а в локальный Store Buffer (буфер отложенной записи; на x86-64 он работает как очередь FIFO, поэтому записи между собой не переставляются). Другое физическое ядро процессора не увидит эту единицу до тех пор, пока буфер не сбросится в кэш и аппаратный протокол когерентности (MESI) не оповестит остальные ядра.

flowchart TD
    classDef process  fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef success  fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc
    classDef error    fill:#7f1d1d,stroke:#f87171,stroke-width:1px,color:#f8fafc
    classDef warning  fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef entry    fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef aux      fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc
    classDef system   fill:#312e81,stroke:#a78bfa,stroke-width:1px,color:#f8fafc
    classDef data     fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc
    classDef network  fill:#881337,stroke:#fb7185,stroke-width:1px,color:#f8fafc
    classDef accent   fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    subgraph Core1 ["Ядро CPU 1"]
        Reg1["Регистры"]:::data --> SB1["Store Buffer<br>A=1 висит здесь"]
        SB1 --> L1_1["L1 Кэш Ядра 1"]
    end

    subgraph Core2 ["Ядро CPU 2"]
        L1_2["L1 Кэш Ядра 2"]:::data --> Reg2["Регистры<br>Читают A=0 (Устаревшее)"]
    end

    L1_1 -.->|"Шина данных / MESI<br>Синхронизация запаздывает"| L1_2

Для однопоточного кода действует фундаментальное правило As-If Serial: компилятор и процессор гарантируют, что наблюдаемый результат работы программы будет таким, как если бы код исполнялся строго последовательно.
Но в многопоточной среде (между разными горутинами) эта иллюзия мгновенно рушится. Наступает хаос, известный как Data Race.

2. Data Race против Race Condition

На собеседованиях уровня Middle+/Senior соискателей регулярно просят объяснить принципиальную разницу между этими понятиями. Запомните: это совершенно разные категории проблем.

flowchart LR
    classDef process  fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef success  fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc
    classDef error    fill:#7f1d1d,stroke:#f87171,stroke-width:1px,color:#f8fafc
    classDef warning  fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef entry    fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef aux      fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc
    classDef system   fill:#312e81,stroke:#a78bfa,stroke-width:1px,color:#f8fafc
    classDef data     fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc
    classDef network  fill:#881337,stroke:#fb7185,stroke-width:1px,color:#f8fafc
    classDef accent   fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    subgraph BugTypes["Разделение понятий"]
        DR["Data Race (Гонка данных)<br>Ошибка программы (синхронизации)<br>2 горутины, 1 ячейка памяти, >=1 запись,<br>НЕТ синхронизации -> непредсказуемые значения"]
        RC["Race Condition (Состояние гонки)<br>Архитектурная ошибка алгоритма<br>Синхронизация есть (нет битой памяти),<br>но порядок событий ломает бизнес-логику"]
    end

Data Race (Гонка данных)

Происходит, когда две горутины одновременно обращаются к одной и той же ячейке памяти, и как минимум одно обращение — это запись.
В отличие от C и C++, где программа с гонкой целиком становится Undefined Behavior (Неопределенным поведением) и компилятор вправе сделать что угодно, гонка данных в Go не делает поведение всей программы неопределённым. Чтение переменной размером в машинное слово вернёт одно из записанных значений — старое или новое. Но для многословных значений — интерфейсов, срезов, строк — чтение может вернуть «половинки» разных записей, а это уже нарушение безопасности памяти (см. ниже). В любом случае гонка — это ошибка программы, а не сбой железа (никакого panic ядра она не вызывает).

Race Condition (Состояние гонки)

Это логическая ошибка проектирования. Приложение работает, память не портится (возможно, вы защитили все мьютексами), но порядок операций приводит к ошибке бизнес-логики.
Пример: Два запроса одновременно проверяют баланс if balance >= 100, оба видят 100 и оба списывают деньги, уводя баланс в минус. Память не повреждена (мьютексы спасли от Data Race), но деньги украдены.

Ловушка / Gotcha: Data Race интерфейсов (Фатальный сбой)

Самый страшный сценарий Data Race в Go — это гонка при записи в интерфейс или слайс.
Как мы помним из статьи 24. Интерфейсы под капотом. iface и eface, пустой интерфейс (any) занимает 16 байт и состоит из двух указателей: на тип и на данные.
Если одна горутина пишет в var val any = &User{}, а другая читает, процессор не может атомарно обновить все 16 байт (на 64-битных системах атомарная запись — это 8 байт).
В итоге читающая горутина может прочитать старый тип, но новые данные (или наоборот). Это называется Torn Write (Разорванная запись). Попытка вызвать метод у такого «франкенштейна» приведет к тому, что процессор прыгнет по случайному адресу в памяти. Это уязвимость, которую хакеры могут использовать для захвата контроля над сервером (Exploitation).

3. Go Memory Model: Отношение Happens-Before

Как писать безопасный код, если железо живет своей жизнью? Для этого нужна Модель Памяти.
Ее фундамент — отношение Happens-Before (Происходит-До).

Это математическое отношение частичного порядка. Если событие $E_1$ Happens-Before события $E_2$, это означает, что любые изменения памяти, сделанные до $E_1$, гарантированно будут видны в $E_2$.

Компилятор Go и рантайм берут на себя всю грязную работу (расстановку аппаратных Memory Barriers / Fences), чтобы это правило выполнялось. Если ваш код не использует гарантии Happens-Before, то компилятор имеет полное право игнорировать порядок ваших операций.

4. Гарантии Happens-Before в Go

Чтобы код был потокобезопасным, вы обязаны использовать примитивы, которые создают связь Happens-Before. Вот основные правила:

1. Горутины

Запуск горутины (go f()) happens-before начала выполнения кода внутри горутины.

var a string

func main() {
    a = "hello" // Гарантированно выполнится до чтения
    done := make(chan struct{})
    go func() {
        fmt.Println(a) // Безопасно, выведет "hello"
        close(done)
    }()
    <-done // Иначе main может завершиться раньше горутины
}

2. Каналы (Channels)

Запись в канал happens-before завершения чтения из этого же канала.
Закрытие канала (close) happens-before получения zero-value на стороне читателя.
Чтение из небуферизованного канала happens-before завершения записи в него.

var c = make(chan int, 10)
var a string

func f() {
    a = "hello"
    c <- 0  // Отправка (запись)
}

func main() {
    go f()
    <-c     // Чтение. Завершение чтения Happens-After записи 'a'
    fmt.Println(a) // Безопасно, всегда "hello"
}

sequenceDiagram
    autonumber
    participant G1 as Горутина 1 (f)
    participant Ch as Канал c
    participant G0 as Горутина 0 (main)

    G1->>G1: a = "hello"
    G1->>Ch: c <- 0 (Запись)
    Note over G1,Ch: Happens-Before барьер
    Ch->>G0: <-c (Завершение чтения)
    G0->>G0: Чтение a (Гарантированно "hello")

3. Блокировки (sync.Mutex)

Для любого sync.Mutex, вызов Unlock() happens-before завершения следующего вызова Lock().

var mu sync.Mutex
var a string

func main() {
    mu.Lock()
    a = "hello" // Защищено
    mu.Unlock() // Это действие happens-before следующего Lock()

    done := make(chan struct{})
    go func() {
        mu.Lock() // Этот Lock ждет Unlock() сверху
        fmt.Println(a) // Безопасно
        mu.Unlock()
        close(done)
    }()
    <-done // Иначе main может завершиться раньше горутины
}

4. Атомарные операции (sync/atomic)

Операции из sync/atomic (такие как Store, Load, CompareAndSwap) обеспечивают Sequential Consistency (Последовательную консистентность). Запись (Store) гарантированно синхронизируется со следующим чтением (Load) во всех горутинах.

Собеседование

Вопрос: Если я напишу бесконечный цикл for !flag {} в одной горутине, а в другой сделаю flag = true, почему первая горутина может никогда не выйти из цикла, даже если это обычный bool?
Ответ: Потому что между ними нет связи Happens-Before. Компилятор имеет право оптимизировать for !flag {} в if !flag { for {} } (вынести чтение переменной за пределы цикла, решив, что она не может измениться сама по себе). Сегодняшний gc так делает не всегда (например, на amd64 в этом простом виде он перечитывает flag на каждой итерации), но гарантии нет: зависание — разрешённое поведение. Кэш процессора тут ни при чём: кэши когерентны (MESI), и запись другого ядра рано или поздно станет видна. Корректное решение — atomic.Bool, канал или мьютекс.

5. Под капотом: Go Race Detector (-race)

В Go встроен один из лучших инструментов в индустрии для поиска Data Race. Вы запускаете тесты или приложение с флагом -race:
go test -race ./... или go run -race main.go.

Как он работает? Он не анализирует код статически. Он работает в рантайме.

Go использует библиотеку ThreadSanitizer (TSAN) от Google (которая также встроена в Clang/GCC для C++).

Shadow Memory (Теневая память): При компиляции с флагом -race рантайм выделяет огромный блок теневой памяти. На каждые 8 байт памяти вашего приложения TSAN выделяет 16 байт метаданных.
Инструментирование: Компилятор вставляет перехватчики (хуки) перед каждой операцией чтения и записи в память.
Векторные часы (Vector Clocks): Метаданные хранят историю последних 4 доступов (Thread ID, время по локальным часам потока, тип операции: read/write).
Алгоритм: Когда горутина обращается к памяти, TSAN сравнивает ее "Векторные часы" с часами в теневой памяти. Если он видит, что другая горутина писала в этот же адрес, и между этими событиями нет ребра графа Happens-Before (зафиксированного через мьютексы/каналы), детектор поднимает тревогу и печатает стек-трейс с точным указанием строк кода, где произошел конфликт.

Итог

Компиляторы и CPU врут: Они переставляют инструкции местами. Не полагайтесь на хронологический порядок выполнения кода между разными горутинами.
Data Race (Гонка данных) — это ошибка программы (отсутствие синхронизации при записи). Она приводит к непредсказуемым значениям, а для многословных данных — к "разорванным" интерфейсам и срезам и нарушению безопасности памяти.
Race Condition — ошибка бизнес-логики (неправильный алгоритм), даже если Data Race нет.
Go Memory Model базируется на отношении Happens-Before. Если вы не связали две горутины через канал, мьютекс или пакет atomic, рантайм вам ничего не гарантирует.
Использование go test -race обязательно в любом бэкенд-проекте на этапе CI (Continuous Integration).

Теперь вы знаете, как железо и компилятор работают с памятью и блокировками. Но знание примитивов — это лишь половина пути. В распределенных и высоконагруженных системах неправильное использование блокировок и каналов ведет к остановке всей системы. В следующей статье мы разберем классические архитектурные ошибки проектирования бэкенда на Go и способы борьбы с ними: 43. Deadlock, Livelock и типичные ошибки конкурентности.