RWMutex

Читатели параллельны, писатель один

type Meta struct {
    mu sync.RWMutex
    m  map[string]string
}

func (c *Meta) Get(k string) string {
    c.mu.RLock()         // разделяемая блокировка
    defer c.mu.RUnlock()
    return c.m[k]
}

func (c *Meta) Set(k, v string) {
    c.mu.Lock()          // исключительная
    defer c.mu.Unlock()
    c.m[k] = v
}

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

Писатель не голодает

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

Когда RWMutex оправдан

RWMutex сложнее и чуть дороже обычного Mutex. Выигрыш — когда чтений заметно больше, чем записей, и секция чтения не микроскопическая: справочник метаданных файлов, кэш конфигурации, карта маршрутов. Если чтения редки или тривиальны — обычный Mutex проще и не хуже. Выбор — по профилю доступа, а не по привычке.