Дизайн критических секций

Не держать мьютекс во время долгой операции

func (s *Store) LoadOrStore(key string, compute func() int) int {
    s.mu.Lock()
    if v, ok := s.m[key]; ok {
        s.mu.Unlock()
        return v
    }
    s.mu.Unlock()

    v := compute() // долгое вычисление — БЕЗ мьютекса

    s.mu.Lock()
    s.m[key] = v
    s.mu.Unlock()
    return v
}

compute может звать сеть или диск. Держать мьютекс во время него — значит сериализовать всех остальных на секунды. Правило: секция — только обращения к данным, всё остальное — за её пределами. (Тонкость: между разблокировкой и повторным захватом значение могли вычислить дважды — для этого есть singleflight, урок.)

Гранулярность по инвариантам

Если структура хранит два независимых набора данных, один мьютекс на оба — грубо: обращение к первому блокирует обращения ко второму. Два мьютекса — по одному на набор — дают реальный параллелизм. Но дробить мьютексы до «по одному на поле» — перебор: если поля меняются всегда вместе, они — один инвариант, и мьютекс у них один.

Contention

Когда горутины часто сталкиваются на одном мьютексе (contention), сериализация съедает весь параллелизм: горутины стоят в очереди, ядра простаивают. Лечится тем же: короче секции, тоньше гранулярность, реже общий доступ — например, раздать каждой горутине свою ячейку слайса, как в уроках про WaitGroup.