atomic.Pointer и выбор †

Публикация неизменяемого состояния

type Config struct {
    Timeout time.Duration
}

var cfg atomic.Pointer[Config]

func Update(c *Config) {
    cfg.Store(c) // публикуем новый конфиг
}

func Get() *Config {
    return cfg.Load() // снимок
}

Писатель собирает новый Config целиком (мутирует локальную копию, не трогая опубликованную) и одним Store делает её видимой. Читатели Load-ят снимок и работают с ним, не боясь, что он изменится под ними. Данные после публикации никто не мутирует — поэтому блокировки не нужны.

Паттерн copy-on-write

func SetTimeout(d time.Duration) {
    old := cfg.Load()
    newCfg := *old // копия
    newCfg.Timeout = d
    cfg.Store(&newCfg)
}

Правка идёт через копию: прочитали, скопировали, изменили копию, опубликовали. Старый объект продолжают держать читатели, которым он достался раньше, — и это безопасно, потому что он неизменяем. Это copy-on-write: дорого только для больших структур, для конфигов — идеально.

Атомик или мьютекс

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