> Как избежать конкурентного доступа к флагу для управления состоянием в Go? (Go)

Короткий ответ

Конкурентный доступ к флагу состояния в Go решается через атомарные операции (sync/atomic), мьютексы (sync.Mutex, sync.RWMutex) или каналы. Для простого флага с чтением и записью из разных горутин предпочтителен atomic.Bool - он минимален по накладным расходам и гарантирует видимость изменений. Если флаг используется в составе более сложного состояния или требует инвариантов, выбирайте мьютекс. Каналы уместны, когда флаг - часть сигнальной логики, например, остановка worker'а через context.Context.

Подробное объяснение

Проблема конкурентного доступа к флагу - это data race: одновременное чтение и запись без синхронизации приводит к неопределённому поведению. В Go три основных подхода:

1. sync/atomic - для простых скалярных значений (bool, int32, int64, uintptr). Операции Load, Store, CompareAndSwap выполняются атомарно на уровне процессора. Плюсы: минимальная задержка, нет блокировок. Минусы: только одиночные операции, нельзя атомарно проверить и изменить несколько полей.

2. Мьютексы - sync.Mutex для записи и sync.RWMutex для сценариев с частыми чтениями. Плюсы: защищают произвольные структуры данных, позволяют выполнять составные операции (check-then-act). Минусы: блокировки, возможны contention и deadlock при ошибках.

3. Каналы - передача сигнала через chan struct{} или context.Context. Плюсы: идиоматично для координации горутин, поддерживает select и таймауты. Минусы: избыточно для простого флага, требует отдельной горутины-получателя.

Выбор зависит от семантики: если флаг - просто признак "включено/выключено" и не участвует в сложных переходах, atomic.Bool - лучший выбор. Если нужно, например, "установить флаг и проверить связанное счётчик", берите мьютекс.

На практике

Для senior-позиции важно не только назвать инструменты, но и объяснить trade-off. Начните с atomic.Bool как дефолта для одиночного флага. Упомяните, что atomic.Bool появился в Go 1.19, до этого использовали atomic.LoadInt32/atomic.StoreInt32 с приведением к int32 (0/1). Для флагов, управляющих жизненным циклом горутин, чаще используют context.WithCancel - это более высокоуровневый идиоматичный подход, чем ручной флаг.

Также стоит упомянуть sync.Once - если флаг нужен для одноразовой инициализации, он решает задачу без явного флага. И sync.WaitGroup - если флаг сигнализирует о завершении группы горутин.

Пример кода

GO
package main

import (
    "fmt"
    "sync"
    "sync/atomic"
    "time"
)

type Service struct {
    stopped atomic.Bool
}

func (s *Service) Stop() {
    s.stopped.Store(true)
}

func (s *Service) Run() {
    for !s.stopped.Load() {
        // работа
        time.Sleep(10 * time.Millisecond)
    }
    fmt.Println("stopped")
}

// Альтернатива с мьютексом для составного состояния
type Config struct {
    mu      sync.RWMutex
    enabled bool
    retries int
}

func (c *Config) SetEnabled(enabled bool, retries int) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.enabled = enabled
    c.retries = retries
}

func (c *Config) Snapshot() (bool, int) {
    c.mu.RLock()
    defer c.mu.RUnlock()
    return c.enabled, c.retries
}

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

Структурируйте ответ: сначала назовите три подхода, затем критерии выбора. Приведите пример из практики - например, флаг остановки сервиса через atomic.Bool и почему не через мьютекс. Если интервьюер спрашивает про "правильный" способ, уточните: "зависит от контекста - для простого флага atomic, для составного состояния мьютекс, для сигналов каналы". Покажите понимание memory model: atomic гарантирует happens-before, мьютекс - тоже, каналы - тоже.

Что проверяет интервьюер

Интервьюер оценивает: знание примитивов синхронизации, понимание data race и memory model, умение выбирать инструмент под задачу, осведомлённость о atomic.Bool и context.Context как альтернативе флагам. Также проверяется способность объяснить trade-off между производительностью и сложностью.

Типичные ошибки

• Использование обычного bool без синхронизации - сразу data race.
• Применение мьютекса для простого флага, когда достаточно atomic - избыточно.
• Использование atomic.Bool для составных операций (например, "проверить и сбросить") - нужен CompareAndSwap или мьютекс.
• Забывают, что atomic.Bool не заменяет context.Context для отмены долгих операций - флаг проверяется только в точках цикла, а context позволяет прервать блокирующий вызов через select.
• Путаница между sync.Once и флагом: Once гарантирует однократное выполнение, флаг - просто состояние.