Проблема: при одновременном инкременте общей переменной из $2$ горутин без синхронизации возникает гонка данных — результат и порядок неопределены, программа некорректна и может сломаться при оптимизациях/кешировании.
Способы синхронизации и их затраты
1) sync.Mutex
- Как: блокировать мьютекс перед изменением и разблокировать после.
- Затраты: контекстная синхронизация — при конкуренции возможны переходы планировщика в состояние ожидания, переключения горутин и расходы на блокировку/разблокировку. Хорош для сложных критических секций и множественных полей. Под высокой конкуренцией может быть дороже, чем атомики, но обеспечивает простую семантику «взаимоисключение» и сильный happens-before.
2) sync/atomic (atomic.AddInt64 / atomic.LoadInt64 или atomic.Int64 в Go $1.19$+)
- Как: использовать атомарную операцию для инкремента, например atomic.AddInt64(&counter, 1).
- Затраты: меньше накладных расходов — нет блокирования планировщика, операция выполняется на уровне CPU с инструкциями атомарного обновления и барьерами памяти. При низкой/умеренной конкуренции обычно быстрее мьютекса. При очень высокой конкуренции появляются расходы кеш‑коэрентности (cache line bouncing) — частые переиздания линии памяти между ядрами, что снижает масштабируемость.
3) Канал (serialiser): одна горутина — владелец счётчика, другие посылают запросы (increment) через канал
- Как: все инкременты посылаются в канал; одна горутина читает и обновляет значение. Можно буферизовать/батчировать.
- Затраты: больше накладных расходов на передачу сообщений и планирование; но даёт упорядоченность и легко расширяется для сложной логики. Подходит, если помимо инкремента нужно делать ещё работу в одном потоке (консолидация).
4) Владелец‑горoтина (goroutine confinement) / шардирование
- Как: разбить счётчик на N шардов (по порядку или по goroutine id), каждый шард изменяется одной горутиной; итог — сумма шардов при чтении. Или держать счётчик в одной горутине и управлять доступом через API.
- Затраты: снижает конкуренцию и кеш‑коэрентность, улучшает масштабирование; добавляет сложность при чтении суммы.
Дополнительные замечания
- Для простого счётчика чаще всего рекомендую atomic.AddInt64 — низкая задержка и простота. Для критических секций с несколькими переменными или сложной инвариантной логикой — mutex. Для потоков с высокой нагрузкой и частыми инкрементами рассматривайте шардирование. Для упрощённой архитектуры или когда нужно сериализовать дополнительные операции — канал/конфинемент.
- Гарантии памяти: mutex и атомики обеспечивают happens-before; используйте подходящие атомарные операции или располагайте доступы под той же блокировкой.
- Отладка: включите детектор гонок — go run -race или go test -race, чтобы найти существующие гонки.
Если нужно, могу показать короткие примеры кода для каждого подхода.