sync и atomic в Go: два совета, которые разваливаются при замере

Что здесь на самом деле спрашивают

Лестница почти всегда такая:

1. «Что не так с n++ из горутин?» — разминка.
2. «Чем atomic отличается от мьютекса?» — здесь начинают отвечать «быстрее», и это половина ответа.
3. «Что быстрее и насколько?» — вопрос-ловушка: правильный ответ начинается со встречного вопроса «при какой конкуренции».
4. «Когда брать RWMutex?» — ещё одна ловушка: «когда много чтений» неверно.
5. «Зачем sync.Once, если можно флаг?» — про happens-before, а не про скорость.
6. «Почему нельзя копировать мьютекс?» — и чем это ловится.

Дальше урок идёт по этой лестнице. Спина у неё одна: синхронизация — это не скорость, а гарантии; а скорость зависит от конкуренции, а не от примитива.

База: состязание за данные — и почему n++ не одно действие

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

Кажется, что беды тут быть не может: инкремент — одна строка. Но одна строка в исходнике ничего не говорит о неделимости. n++ — это три действия:

1. прочитать текущее значение из памяти;
2. прибавить к нему единицу;
3. записать результат обратно.

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

Так это и выглядит на прогоне. Восемь горутин по 10 000 инкрементов обычной переменной:

n := 0
// восемь горутин: for i := 0; i < 10000; i++ { n++ }

Прогон bench/gosync/practice.go печатает, что итог меньше 80 000. Тот же счётчик атомарно даёт ровно 80 000.

Оговорка к этому замеру, и она важнее самого замера. В скрипте чтение и запись разведены явно — между ними стоит runtime.Gosched(). Сделано это не для наглядности, а потому, что первая редакция писала просто n++, и один из прогонов дал ровно 80 000: потери не случилось. Это не опровержение гонки, а её главное свойство — она проявляется не всегда. Именно поэтому такую ошибку не находят тестами: код «работает», пока не изменится нагрузка, версия Go или число ядер.

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

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

Механизм 1: гарантии даёт не замок, а happens-before

Начать стоит не с инструмента, а с того, откуда вообще берётся слово «безопасно». Оно не из слова «замок», а из модели памяти:

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

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

// защищает переменную — и не работает
mu.Lock(); n := len(items); mu.Unlock()
mu.Lock(); v := items[n-1]; mu.Unlock()   // между вызовами items уже другой
 
// защищает инвариант
mu.Lock()
v := items[len(items)-1]
mu.Unlock()

И вторая половина того же: если хоть одна горутина читает поле мимо замка, гарантии нет вовсе — компилятор и процессор вправе переупорядочить что угодно, и -race это найдёт.

Какое ребро создаёт каждый примитив

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

Эта таблица — и есть весь урок в свёрнутом виде. Всё остальное объясняет, чем эти рёбра отличаются по цене и по тому, что именно ими можно защитить.

Механизм 2: atomic — это не «быстрый мьютекс»

Разница не в скорости, а в том, что именно защищается.

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

Мьютекс защищает участок кода — сколько угодно полей и любую логику между ними.

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

Отсюда правило выбора, и оно не про производительность: atomic годится ровно тогда, когда защищаемое состояние — одно машинное слово. Счётчик, флаг, указатель на неизменяемый снимок. Как только появляется «прочитать А, решить, записать Б» — это мьютекс, и никакая атомарность его не заменит.

Сам пакет от себя отговаривает:

Отдельно про форму записи: с Go 1.19 есть типы — atomic.Int64, atomic.Bool, atomic.Pointer[T]. Их стоит предпочитать функциям (atomic.AddInt64(&x, 1)) по двум причинам: тип нельзя случайно прочитать неатомарно, и он сам решает проблему выравнивания на 32-битных платформах, где int64 требует 8-байтового выравнивания.

Механизм 3: «что быстрее» — неполный вопрос

Вот замер, ради которого урок и написан.

Без конкуренции мьютекс дороже atomic вдвое: 13,35 нс против 6,49. Это честное число, и на нём обычно всё и заканчивается.

Но спрашивают-то про конкуренцию. Один счётчик, разное число горутин:

Смотреть надо не на отдельные ячейки — они шумят, — а на последнюю строку. Мьютекс с ростом конкуренции дорожает почти на порядок, атомарная операция почти не дорожает. Причина в парковке: мьютекс снимает проигравшую горутину с процессора, и цена ожидания входит в замер; атомарная операция никого не паркует, а повторяет попытку.

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

И главный практический вывод: если за одну ячейку дерутся шестнадцать горутин, дело уже не в примитиве. Дешевле всего убрать саму конкуренцию — счётчик на горутину со сложением в конце, шардирование по ключу, накопление локально. Замена мьютекса на atomic — это оптимизация в пределах порядка; устранение конкуренции — в пределах двух.

И граница у этих чисел названа тут же: они сняты на двух ядрах и одной версии Go. Переносить отсюда нужно не «9,6» и не «8,7», а причину: мьютекс платит парковкой проигравшего, атомарная операция — согласованием между ядрами. Своё число, если оно нужно для решения, снимают на своей нагрузке и своём железе, а не берут из чужой таблицы.

Механизм 4: RWMutex не бесплатная замена Mutex

«Много чтений — бери RWMutex» звучит очевидно и проверку не проходит. Прежде чем смотреть на числа, стоит назвать, от чего вообще зависит ответ, — иначе таблица выглядит опровержением здравого смысла.

Выбор между Mutex и RWMutex определяют три величины, и ни одна из них не «сколько читателей в коде»:

Ловушка в том, что RLock дороже Lock: он считает читателей и проверяет, не ждёт ли писатель. Эта надбавка платится всегда, а выигрыш от параллельных читателей появляется, только когда есть что параллелить, — то есть когда секция достаточно длинная.

Причина простая: RLock делает больше работы, чем Lock — считает читателей и проверяет, не ждёт ли писатель. На короткой секции эта разница и есть всё время операции, а параллельность читателей окупить её не успевает. Выигрыш появляется только тогда, когда под замком проводят достаточно времени.

Устойчив здесь сам перелом, а не то, где именно он проходит: граница зависит от машины и числа ядер.

Про RWMutex стоит знать ещё две вещи:

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

Механизм 5: Once, WaitGroup и то, что копировать нельзя

sync.Once после первого вызова бесплатен. Замерено: 1,87 нс против 1,92 у своей атомарной проверки и 2,23 у «не делать ничего вовсе» — все три в пределах шума друг от друга. То есть заменять Once ручным флагом ради скорости нечем, а ошибиться в ручном варианте легко: между проверкой и установкой флага успевает вклиниться вторая горутина.

И Once даёт то, чего ручной флаг не даёт сам по себе:

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

WaitGroup: два правила. Add вызывается до запуска горутины, а не внутри неё — иначе Wait может успеть раньше. И счётчик не должен уходить в минус: лишний Done — это паника.

И то, что копировать нельзя. У Mutex, RWMutex, Once и WaitGroup в документации стоит одна и та же фраза:

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

Ловится это go vet, проверкой copylocks, чьё описание переводится как «проверка на замки, ошибочно переданные по значению». Она входит в набор, который go test запускает по умолчанию, и сообщение выглядит как passes lock by value. Три самых частых места: приём структуры по значению, получатель-значение у метода и присваивание.

Глубже: строки кеша — почему параллельность не бесплатна

Есть ещё одна причина, по которой «просто взять atomic на каждое поле» не даёт ожидаемого ускорения, и она лежит ниже уровня языка — в устройстве железа.

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

Это называют ложным разделением, и распознаётся оно по симптому: добавили ядер, а быстрее не стало — иногда стало медленнее. Лечится разнесением по разным строкам (в стандартной библиотеке для этого есть выравнивающие поля) либо тем, что каждое ядро копит свой счётчик и складывает их в конце.

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

И граница у этого разбора такая же, как у чисел выше. Шестьдесят четыре байта — свойство процессора, а не языка Go, и на другой машине размер строки может быть другим. Поэтому правило пишется не от числа, а от симптома: если добавление ядер не ускоряет, счётчики стоит развести — независимо от того, сколько именно байт в строке на этой машине.

Как отвечать на собеседовании

Короткий ответ: n++ — это три действия, а не одно: прочитать, прибавить, записать; две горутины успевают вклиниться друг другу между ними, и обновление теряется. Дальше выбор простой: мьютекс защищает целостность участка кода — сколько угодно полей и любую логику между ними, — а атомарная операция годится там, где состояние ограничено и меняется одним неделимым действием: счётчик, флаг, указатель. И то и другое даёт не скорость, а гарантию: что одна горутина увидит работу другой целиком, а не наполовину.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

На «что не так с n++» отвечайте тремя операциями. «Чтение, сложение, запись; два обновления сливаются в одно, и итог меньше ожидаемого — у меня восемь горутин по 10 000 давали меньше 80 000».

Про atomic и мьютекс говорите про объём защиты, а не про скорость. «Atomic защищает одну ячейку и одно действие; мьютекс — участок кода. Как только надо прочитать одно и записать другое, atomic не подходит независимо от скорости».

На «что быстрее» задайте встречный вопрос. «При какой конкуренции? Без неё мьютекс дороже вдвое; при шестнадцати горутинах на один счётчик — почти на порядок, потому что паркует проигравшего. И если конкуренция такая, лечить надо её, а не примитив».

Про RWMutex скажите про длину секции. «RLock дороже Lock, и на короткой секции RWMutex проигрывает; выигрыш появляется, когда под замком проводят достаточно времени».

Про Once назовите гарантию, а не цену. «Он даёт happens-before: увидевший флаг видит и результат инициализации. Быстрый путь у него и так бесплатный».

Про копирование назовите инструмент. «Копия мьютекса приезжает свободной; ловит go vet проверкой copylocks, она уже в go test».

Дальше спросят

sem := make(chan struct{}, 10)
for _, job := range jobs {
    sem <- struct{}{}
    go func(j Job) {
        defer func() { <-sem }()
        handle(j)
    }(job)
}

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

fmt.Println(unsynced())
fmt.Println(syncedAtomic())
fmt.Println(onceCount())
a, b := copiedStruct()
fmt.Println(a, b)

true
80000
1
1 2

false
80000
1
2 2

true
80000
8
1 1

true
80000
1
1 1

Проверка знаний