История вопроса. Карта в Go реализована как хеш-таблица с изменяемыми buckets. Когда коэффициент загрузки превышает порог, выполнение запускает фазу роста, в ходе которой записи реhashed и перераспределяются в новые, большие массивы buckets.
Проблема. Если бы язык позволял выражения вроде &m["ключ"], то полученный указатель ссылался бы на конкретное местоположение в памяти внутри хеш bucket. Во время роста карты записи копируются в новые buckets, а старые buckets освобождаются, что делает любые существующие указатели висячими и небезопасными.
Решение. Спецификация Go однозначно запрещает брать адрес выражения индексации карты. Компилятор рассматривает &m[k] как недопустимую операцию, что гарантирует, что никакая программа не может удерживать указатели на внутреннее содержимое карты. Это позволяет среде выполнения свободно перемещать записи во время роста или уменьшения без необходимости управления обновлением указателей или их аннулирования.
Описание проблемы. В службе телеметрии с высокой пропускной способностью инженерам нужно было обновить поле счетчика внутри большого структурированного конфигурационного объекта, хранящегося в кэше карты в памяти. Первоначальные попытки использовали cfg := &configMap[deviceID]; cfg.Counter++, что не скомпилировалось с ошибкой "нельзя взять адрес элемента карты". Эта схема была распространена в кодовых базах C++, с которых команда мигрировала, где итераторы std::map остаются стабильными.
Решение 1: Хранить указатели в карте. Изменить тип карты с map[string]Config на map[string]*Config. Это позволяет получать указатель и модифицировать основную структуру напрямую без переназначения. Плюсы включают возможность прямой модификации и избежание копирования структуры, в то время как минусы включают увеличение выделений в куче, снижение локальности кэша и необходимость проверок на nil.
Решение 2: Скопировать-изменить-переназначить. Извлечь значение в локальную переменную, изменить его и записать обратно с помощью cfg := configMap[deviceID]; cfg.Counter++; configMap[deviceID] = cfg. Плюсы включают работу с типами значений и ноль дополнительных выделений, в то время как минусы включают накладные расходы по производительности при копировании больших структур при каждом обновлении.
Решение 3: Использовать sync.RWMutex с оберткой структуры. Защитить карту с помощью мьютекса, чтобы позволить безопасные операции чтения-изменения-записи в конкурентных средах. Плюсы включают явную синхронизацию для одновременного доступа, в то время как минусы включают потенциальные конфликты блокировок и продолжительную необходимость переназначения.
Выбранное решение и результат. Для маленьких структур (<64 байта) было принято решение 2 из-за его простоты и свойств без аллокаций. Для больших, часто обновляемых структур использовалось решение 1 с пулом выделений для снижения давления на сборщик мусора. Система достигла стабильной производительности без использования небезопасных указателей.
Почему я могу взять адрес элемента среза, но не элемента карты?
Взять адрес элемента среза &s[i] допустимо, потому что базовый массив среза имеет стабильный адрес памяти, если срез не перераспределяется (например, при append, превышающем емкость). Указатель остается действительным, пока основной массив не перераспределяется. В отличие от этого, buckets карты часто перемещаются во время операций роста. Если бы адреса элементов карты были разрешены, они стали бы висячими указателями после повторного хеширования, нарушая безопасность памяти.
Позволяет ли использование карты указателей изменять хранящиеся данные без переназначения?
Хотя вы не можете взять адрес слота указателя (&m[key] недопустимо даже для map[K]*V), вы можете скопировать значение указателя и разыменовать его: p := m[key]; p.Field = newVal. Это срабатывает, потому что вы изменяете структуру, выделенную в куче, через копию указателя, а не внутреннее хранилище карты. Различие тонкое: карта хранит значение указателя (адрес), и хотя этот адрес нельзя адресовать напрямую, его можно прочитать и использовать для доступа к объекту в куче.
Как будет работать рост карты, если адреса элементов были бы разрешены?
Если бы язык разрешал &m[key], среде выполнения потребовалось бы обеспечить стабильность указателей во время миграции buckets. Это потребует либо индирекции (хранение указателей на записи в buckets, удваивая накладные расходы на указатели), либо никогда не освобождать старые buckets (утечка памяти), либо реализовать барьер чтения для обновления указателей во время перемещения (значительная потеря производительности). Текущий дизайн оптимизирует для общего случая операций с картами, жертвуя возможностью брать адреса элементов, избегая этих накладных расходов.