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

Философия lock-free программирования и машинных инструкций

«Быстрее всего в компьютере работает та операция, которая выполняется целиком в кремнии регистров процессора и кэша L1, ни разу не постучавшись в дверь ядра операционной системы. Пакет sync/atomic открывает прямой доступ к этим аппаратным примитивам».
— Брайан Керниган

Пакет sync/atomic предоставляет разработчику прямой доступ к аппаратным атомарным инструкциям центрального процессора. В отличие от sync.Mutex, который управляет очередями горутин, задействует системные семафоры и при высокой конкуренции паркует потоки в ядре ОС через системный вызов futex, атомарные инструкции выполняются полностью в пространстве пользователя (User Space) всего за несколько машинных тактов CPU.

Это кремниевый фундамент для построения сверхбыстрых высоконагруженных счетчиков, атомарных флагов состояния, безопасной смены указателей конфигураций и неблокирующих (lock-free) структур данных.

Under the hood: Протокол MESI и когерентность кэшей

Когда горутина выполняет атомарную операцию, процессор не «замораживает» всю оперативную память. Он взаимодействует с локальными кэшами соседних процессорных ядер через аппаратный протокол когерентности MESI (Modified, Exclusive, Shared, Invalid).

flowchart TD
    A["Горутина 1: atomic.AddInt64"] --> B["CPU 0 запрашивает кэш-линию"]
    B --> C{"Состояние линии в CPU 1?"}
    C -->|"Shared"| D["Шлет сигнал Invalidate"]
    C -->|"Modified"| E["Записывает данные в RAM<br>Шлет Invalidate"]
    C -->|"Exclusive/Invalid"| F["Линия уже в Exclusive"]
    D --> G["CPU 0 получает линию в Exclusive"]
    E --> G
    F --> G
    G --> H["Выполнение LOCK инструкции"]
    H --> I["Линия помечается Modified"]
    I --> J["Возврат результата<br>Без перехода в Kernel"]

    classDef proc fill:#1e3a8a,stroke:#3b82f6,color:#dbeafe;
    classDef check fill:#064e3b,stroke:#10b981,color:#d1fae5;
    classDef bus fill:#7f1d1d,stroke:#f87171,color:#fee2e2;

    class A,B,G,H,I,J proc;
    class C check;
    class D,E,F bus;
  

Понимание этой механики критически важно для соблюдения принципа Mechanical Sympathy. Атомарные операции экстремально дешевы при низкой конкуренции (буквально 10–15 тактов CPU), но при одновременной попытке десятков ядер обновить одну и ту же ячейку памяти возникает катастрофический шторм на шине процессора — cache coherence traffic. Каждое ядро вынуждено непрерывно рассылать широковещательные сигналы инвалидации (Invalidate Messages) другим ядрам, сбрасывая их кэши L1/L2 и сжигая полосу пропускания шины памяти.

1. Типизированные атомики и паттерн CAS (Go 1.19+)

Исторически в Go атомики работали через небезопасные указатели atomic.AddInt64(&val, 1). Начиная с версии Go 1.19, стандартная библиотека получила типобезопасные структуры-обертки: atomic.Int32, atomic.Int64, atomic.Bool, atomic.Pointer[T]. Они исключают ошибки разыменования, защищают от случайных прямых присваиваний и автоматически выравнивают память.

Основные методы

• Load() / Store(): Атомарное чтение и запись с полным барьером памяти.
• Add(delta): Атомарное сложение/вычитание (идеально для метрик и счетчиков RPS).
• Swap(new): Безусловная атомарная замена с возвратом старого значения.
• CompareAndSwap(old, new): Фундаментальная операция CAS (Compare-And-Swap). Основа большинства lock-free алгоритмов. Заменяет значение на new только если текущее значение в памяти в этот микросекундный момент в точности равно old.

Классический CAS-цикл

Когда простой инструкции Add недостаточно (например, при вычислении сложного математического выражения или обновлении нескольких полей), применяется идиома CAS-цикла (CAS loop / Optimistic Concurrency Control):

type LockFreeCounter struct {
    val atomic.Int64
}

func (c *LockFreeCounter) Increment() {
    for {
        old := c.val.Load()
        new := old + 1

        // Пытаемся атомарно заменить old на new
        if c.val.CompareAndSwap(old, new) {
            return // Успех: никто не успел вклиниться между Load и CAS
        }
        // Если CAS провалился, значит другая горутина изменила значение.
        // Повторяем цикл с новым стартовым значением.
    }
}

Mechanical Sympathy: False Sharing и выравнивание

Поскольку процессор обменивается данными между ядрами не отдельными байтами, а целыми 64-байтовыми кэш-линиями (Cache Lines), размещение двух независимых счетчиков рядом в одной структуре порождает эффект False Sharing (ложное разделение).

// ❌ ПЛОХО: a и b могут попасть в одну 64-байтовую кэш-линию
type BadMetrics struct {
    a atomic.Int64
    b atomic.Int64
}

// ✅ ХОРОШО: Паддинг гарантирует разделение кэш-линий между ядрами
type GoodMetrics struct {
    a atomic.Int64
    _ [56]byte // 8 + 56 = 64 байта. b начнется со следующей кэш-линии
    b atomic.Int64
}

При использовании структуры GoodMetrics обновление счетчика a ядром CPU 0 никогда не инвалидирует кэш-линию счетчика b на ядре CPU 1. В высоконагруженных метрических системах с миллионами инкрементов в секунду это устраняет паразитный трафик шины и ускоряет исполнение в 5–10 раз.

2. atomic.Pointer[T] и обновление конфигураций без блокировок

Тип atomic.Pointer[T] позволяет безопасно и атомарно заменять указатели на сложные иммутабельные структуры данных без использования блокировок sync.RWMutex. Это канонический паттерн для горячего обновления конфигураций, списков маршрутизации и справочников в памяти (Zero-Downtime Reload).

var config atomic.Pointer[AppConfig]

// Инициализация при старте
config.Store(&AppConfig{Timeout: time.Second})

// Горутина-обработчик читает конфиг без единой блокировки
func handleRequest() {
    // Load атомарно читает указатель за 1 такт CPU.
    // Даже если другой поток обновит конфиг прямо сейчас,
    // эта горутина получит консистентную версию структуры.
    cfg := config.Load()
    process(cfg.Timeout)
}

// Горутина-релоадер обновляет конфиг
func reloadConfig(newCfg *AppConfig) {
    config.Store(newCfg)
}

Сборщик мусора Garbage Collector в Go отслеживает достижимость объектов через граф ссылок. Старый экземпляр AppConfig не будет собран до тех пор, пока все горутины, прочитавшие его через config.Load(), не завершат свою работу. Это делает паттерн на 100% безопасным и не требующим ручного подсчета ссылок.

Ловушки и хардкорные вопросы с собеседований

Сравнение с экосистемами других языков

Итог

1. sync/atomic транслируется напрямую в машинные инструкции процессора (LOCK CMPXCHG, LOCK XADD).
2. Всегда предпочитайте современные типизированные атомики (atomic.Int64, atomic.Pointer[T]) устаревшим функциям из Go 1.0.
3. Паттерн CAS-цикла — надежная основа lock-free алгоритмов при умеренной конкуренции.
4. Избегайте False Sharing через паддинг критических счетчиков до размера строки кэша CPU (64 байта).
5. Атомики не заменяют мьютексы при высокой конкуренции. Используйте их для счетчиков, флагов и атомарного переключения иммутабельных конфигураций.
6. Никогда не смешивайте атомарный и неатомарный доступ к одной и той же переменной.

Понимание атомарных операций ведет нас к следующей важнейшей задаче оптимизации бэкенда: эффективному управлению оперативной памятью. Создание миллионов короткоживущих буферов нагружает сборщик мусора паузами GC. Как переиспользовать однажды выделенную память без блокировок? В следующей статье мы разберем: 21. sync.Pool. Переиспользование объектов.