Ответ.

Работа с конкурентными коллекциями в Go стала важной темой из-за возрастающих требований к многопоточным приложениям. Обычные map в Go не являются потокобезопасными и могут привести к гонкам данных (data race). Появление sync.Map дало стандартное решение для безопасного совместного доступа к коллекциям без внешней синхронизации.

История вопроса:

До появления sync.Map разработчики должны были использовать обычные map с внешним Mutex или RWMutex для организации безопасного доступа из нескольких горутин. Это увеличивало количество кода и вероятность ошибок синхронизации. В Go 1.9 был представлен sync.Map с целью упростить работу с конкурентными коллекциями.

Проблема:

Обычный map не потокобезопасен. Если несколько горутин читают и пишут в map без синхронизации, это приводит к панике или неожиданным результатам. Mutex сложен в правильном использовании и может привести к блокировкам и деградации производительности. Также возникает сложность с "double check" и работой с тяжелоизмеряемой синхронизацией.

Решение:

sync.Map — специальная структура из стандартной библиотеки, предоставляющая потокобезопасные методы Load, Store, LoadOrStore, Delete, Range. Она реализует lock-free стратегию (частично), оптимизированную для сценариев с частым чтением и редкой записью.

Пример кода:

import (
	"fmt"
	"sync"
)

func main() {
	var m sync.Map
	m.Store("foo", 42)
	value, ok := m.Load("foo")
	fmt.Println(value, ok) // 42 true
	m.Delete("foo")
}

Ключевые особенности:

Потокобезопасность без явной блокировки для большинства операций.
Производительность оптимальна для систем с преобладанием чтений над записями.
Отсутствие жёсткой типизации ключей и значений (интерфейсный тип).

Вопросы с подвохом.

Можно ли заменить все map на sync.Map в многопоточных программах?

Нет, sync.Map — не универсальная замена обычной map. Она хорошо подходит для тех структур данных, где преобладают конкурентные, независимые чтения, но при интенсивной записи (частой модификации) или для небольших коллекций обычные map + Mutex быстрее и эффективнее.

Что произойдет, если обычную map использовать только для чтения в нескольких горутинах?

Если map полностью инициализирована и не изменяется после запуска всех горутин, параллельное чтение допустимо и безопасно. Но любое удаление или изменение данных приведёт к непредсказуемому поведению, панике или corrupted map.

Какие типы данных можно использовать как ключ для sync.Map?

Правила те же, что и для обычной map: только сравнимые типы (comparable types). Однако sync.Map принимает ключ любого типа интерфейса{}, что может создать риск объекты с разной семантикой, которые нельзя сравнить между собой или в которых допускаются runtime ошибки.

Пример кода:

var m sync.Map
m.Store([]int{1,2}, "value") // panic: runtime error: hash of unhashable type []int

Типовые ошибки и анти-паттерны

Преждевременное или необоснованное использование sync.Map вместо обычной map и Mutex без профилирования.
Использование sync.Map для небольших коллекций — это приводит к лишним накладным расходам и ухудшению производительности.
Ошибочная попытка использовать некорректные типы ключей (например, срезы).
Одновременное использование sync.Map и внешних sync-примитивов для одних и тех же данных.

Пример из жизни

Негативный кейс

Разработчик использовал sync.Map для хранения настроек приложения, которые изменяются редко, но читаются часто. Однако позже туда начали массово писать данные о сессиях пользователей, что привело к неожиданному увеличению нагрузки GC и деградации производительности.

Плюсы:

Код стал проще, меньше ручного управления mutex.
Не возникало проблем гонки на начальной стадии.

Минусы:

Быстрый рост памяти и задержек при большом числе параллельных записей.
Появляются сложности с типизацией и ошибками при работе с ключами.

Позитивный кейс

Команда внедрила sync.Map для хранения кэша часто запрашиваемых результатов вычислений в high-load сервисе. Количество «чтений» превышает «записи» в сотни раз. Всё работает стабильно и эффективно, код стал короче и проще в поддержке.