Как синхронизировать Map?

Синхронизация Map в Go: Полное Руководство

В Go стандартный тип map не является потокобезопасным (not thread-safe). Это означает, что конкурентные операции чтения и записи из нескольких горутин без синхронизации приведут к состоянию гонки (race condition) и, в итоге, к панике программы. Для синхронизации доступа к map в конкурентной среде существует несколько основных подходов.

1. Использование sync.RWMutex или sync.Mutex

Это классический и наиболее гибкий подход. Мы оборачиваем map в структуру и защищаем все операции мьютексом.

package main

import (
    "sync"
)

// SafeMap - потокобезопасная обёртка вокруг map
type SafeMap struct {
    mu   sync.RWMutex // Используем RWMutex для оптимизации чтений
    data map[string]interface{}
}

// NewSafeMap создаёт новый экземпляр SafeMap
func NewSafeMap() *SafeMap {
    return &SafeMap{
        data: make(map[string]interface{}),
    }
}

// Set безопасно устанавливает значение по ключу
func (sm *SafeMap) Set(key string, value interface{}) {
    sm.mu.Lock()         // Блокировка для записи
    defer sm.mu.Unlock()
    sm.data[key] = value
}

// Get безопасно получает значение по ключу
func (sm *SafeMap) Get(key string) (interface{}, bool) {
    sm.mu.RLock()       // Блокировка для чтения (не блокирует другие чтения)
    defer sm.mu.RUnlock()
    val, ok := sm.data[key]
    return val, ok
}

// Delete безопасно удаляет значение по ключу
func (sm *SafeMap) Delete(key string) {
    sm.mu.Lock()
    defer sm.mu.Unlock()
    delete(sm.data, key)
}

// Len возвращает количество элементов (требует блокировки)
func (sm *SafeMap) Len() int {
    sm.mu.RLock()
    defer sm.mu.RUnlock()
    return len(sm.data)
}

Преимущества:

• Полный контроль над логикой работы с map
• Можно добавлять сложную бизнес-логику в методы
• sync.RWMutex оптимизирован для сценариев с частыми чтениями и редкими записями

Недостатки:

• Необходимость писать обёрточные методы
• Риск забыть про блокировку в каком-то месте

2. Использование sync.Map (из стандартной библиотеки)

Начиная с Go 1.9, в стандартной библиотеке появился sync.Map - специальная потокобезопасная реализация map для определённых случаев использования.

package main

import (
    "fmt"
    "sync"
)

func main() {
    var sm sync.Map
    
    // Сохранение значений
    sm.Store("name", "Alice")
    sm.Store("age", 30)
    
    // Получение значений
    if value, ok := sm.Load("name"); ok {
        fmt.Println("Name:", value) // Вывод: Name: Alice
    }
    
    // Удаление
    sm.Delete("age")
    
    // LoadOrStore - загружает или сохраняет значение
    actual, loaded := sm.LoadOrStore("name", "Bob")
    fmt.Printf("Value: %v, Loaded: %v\n", actual, loaded) // Value: Alice, Loaded: true
    
    // Range - итерация по всем элементам
    sm.Range(func(key, value interface{}) bool {
        fmt.Printf("Key: %v, Value: %v\n", key, value)
        return true // продолжить итерацию
    })
}

Когда использовать sync.Map:

• Когда ключи стабильны (редко добавляются/удаляются)
• При частых чтениях и редких записях
• При работе с disjoint sets of keys в разных горутинах

Когда НЕ использовать sync.Map:

• При частых записях и обновлениях
• Когда нужен контроль над типами ключей и значений
• При необходимости сложных атомарных операций

3. Шардирование (Sharding) для высокой производительности

Для сценариев с очень высокой нагрузкой можно использовать шардирование - разделение map на несколько частей, каждая со своим мьютексом.

package main

import (
    "hash/fnv"
    "sync"
)

const shardCount = 32

// ShardedMap - шардированная потокобезопасная map
type ShardedMap struct {
    shards []*shard
}

type shard struct {
    mu    sync.RWMutex
    items map[string]interface{}
}

// NewShardedMap создаёт новую шардированную map
func NewShardedMap() *ShardedMap {
    shards := make([]*shard, shardCount)
    for i := range shards {
        shards[i] = &shard{
            items: make(map[string]interface{}),
        }
    }
    return &ShardedMap{shards: shards}
}

// getShard определяет, в какой шард попадает ключ
func (m *ShardedMap) getShard(key string) *shard {
    hasher := fnv.New32()
    hasher.Write([]byte(key))
    return m.shards[hasher.Sum32()%shardCount]
}

// Set безопасно устанавливает значение
func (m *ShardedMap) Set(key string, value interface{}) {
    shard := m.getShard(key)
    shard.mu.Lock()
    defer shard.mu.Unlock()
    shard.items[key] = value
}

// Get безопасно получает значение
func (m *ShardedMap) Get(key string) (interface{}, bool) {
    shard := m.getShard(key)
    shard.mu.RLock()
    defer shard.mu.RUnlock()
    val, ok := shard.items[key]
    return val, ok
}

4. Каналы (Channel-based подход)

Это идиоматичный для Go подход, основанный на принципе "Do not communicate by sharing memory; instead, share memory by communicating".

package main

type CommandType int

const (
    SetCommand CommandType = iota
    GetCommand
    DeleteCommand
)

type Command struct {
    Type  CommandType
    Key   string
    Value interface{}
    Resp  chan interface{}
}

// MapManager управляет map через каналы
type MapManager struct {
    commands chan Command
    data     map[string]interface{}
}

// NewMapManager создаёт менеджер map
func NewMapManager() *MapManager {
    mm := &MapManager{
        commands: make(chan Command),
        data:     make(map[string]interface{}),
    }
    go mm.run()
    return mm
}

func (mm *MapManager) run() {
    for cmd := range mm.commands {
        switch cmd.Type {
        case SetCommand:
            mm.data[cmd.Key] = cmd.Value
            cmd.Resp <- nil
        case GetCommand:
            cmd.Resp <- mm.data[cmd.Key]
        case DeleteCommand:
            delete(mm.data, cmd.Key)
            cmd.Resp <- nil
        }
    }
}

// Set устанавливает значение через канал
func (mm *MapManager) Set(key string, value interface{}) {
    resp := make(chan interface{})
    mm.commands <- Command{Type: SetCommand, Key: key, Value: value, Resp: resp}
    <-resp
}

Критерии выбора подхода

• sync.Mutex/RWMutex: Универсальное решение для большинства случаев
• sync.Map: Специализированные сценарии с редкими записями
• Шардирование: Экстремально высокая нагрузка, write-intensive workload
• Каналы: Когда нужна строгая последовательность операций или интеграция с другими асинхронными компонентами

Важные нюансы

1. Итерация по map всегда требует полной блокировки, даже с sync.RWMutex
2. Проверка существования ключа должна быть частью атомарной операции
3. Атомарные обновления (check-and-set) требуют удержания блокировки на время всей операции
4. sync.Map имеет накладные расходы на boxing типов (interface{})

На практике для большинства случаев достаточно sync.RWMutex или стандартного sync.Map для простых сценариев с преобладанием операций чтения.