Краткий ответ

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

Если нужно вернуть память после массового удаления, обычно создают новую map нужной ёмкости и переносят в неё оставшиеся записи. Это требует временной дополнительной памяти и затрат на копирование, но после сборки старой map GC сможет освободить её внутренние структуры.

Исторический контекст

Хеш-таблица оптимизируется прежде всего под быстрые операции поиска, вставки и удаления. Автоматическое уменьшение при каждом снижении размера потребовало бы дополнительных проверок, перемещения данных или перестройки бакетов, что ухудшило бы производительность обычных рабочих нагрузок.

Поэтому стратегия Go предполагает, что размер map может вырасти до пикового значения и затем использоваться повторно. Это выгодно для кэшей, пулов и временных всплесков нагрузки, но может быть невыгодно для структур, которые после пика надолго остаются почти пустыми.

Постановка проблемы

Рассмотрим map, в которую временно загрузили миллионы записей, а затем удалили почти все элементы. Логический размер структуры уменьшился, однако её внутренняя ёмкость не обязана уменьшаться пропорционально.

Такое поведение опасно для долгоживущих объектов: редкий пик нагрузки может постоянно удерживать большой объём памяти. Кроме того, даже очищенная map может влиять на обход и обслуживание внутренних структур, хотя GC не будет считать удалённые значения живыми, если ссылки на них действительно очищены.

Подробное решение

Map хранит записи во внутренних бакетах или группах, организованных для эффективного поиска по хешу. При росте количества элементов runtime расширяет структуру, чтобы сохранить приемлемую плотность и скорость операций. Операция delete удаляет запись из логического содержимого map и очищает соответствующие ссылки, но не обязана возвращать освободившееся место операционной системе и не обязана уменьшать число уже созданных бакетов.

Это означает важное различие между тремя понятиями:

логический размер — число элементов, возвращаемое len;
внутренняя ёмкость — объём структур, подготовленных для хранения элементов;
RSS процесса — память, которую процесс получил от операционной системы и может не вернуть ей сразу.

После удаления указательных значений GC обычно перестаёт считать сами значения достижимыми. Однако память бакетов остаётся частью map, пока map жива. Поэтому уменьшение числа элементов не гарантирует пропорционального уменьшения heap или RSS.

Типичный способ компактирования — создать новую map и перенести в неё сохранившиеся записи:

package main

func compact(src map[string][]byte) map[string][]byte {
    dst := make(map[string][]byte, len(src))
    for k, v := range src {
        dst[k] = v
    }
    return dst
}

После присваивания новой map старая становится недостижимой, если на неё больше нет ссылок. GC сможет освободить её бакеты, но момент фактического возврата памяти ОС зависит от runtime и не обязан совпадать с завершением сборки.

Пересоздание не всегда лучше. Оно требует обхода элементов, временно удерживает старую и новую структуры, может вызвать дополнительные аллокации и не оправдано, если map скоро снова вырастет. Решение принимают по профилям памяти и характеру нагрузки, а не только по текущему значению len.

Ситуация из практики

Сервис обрабатывал пакетный импорт: во время загрузки в map накапливались миллионы записей, после публикации результата почти все записи удалялись. Heap-профиль показывал, что живых значений осталось мало, но долгоживущая map продолжала удерживать крупные внутренние структуры.

Рассматривались два варианта. Периодическая принудительная сборка уменьшала количество живых объектов, но не устраняла вместимость map и добавляла задержки. Сохранение большой map позволяло быстро принимать следующий импорт, однако удерживало высокий базовый расход памяти.

Выбрали пересоздание map после завершения импорта, когда размер оставшихся данных был существенно меньше пикового. Это добавило однократную стоимость копирования, зато снизило постоянное потребление памяти; при частых повторных пиках пересоздание отключали, поскольку повторное выделение оказалось дороже повторного использования уже имеющихся бакетов.

Что кандидаты часто упускают

1. Вопрос: Освобождает ли delete значение, если на него есть другая ссылка вне map?

Ответ: Нет. delete убирает ссылку именно из map, но объект остаётся достижимым через другие ссылки и потому не может быть освобождён GC. Освобождение определяется достижимостью объекта из корней, а не фактом удаления одной конкретной ссылки.

2. Вопрос: Гарантирует ли создание новой map немедленное уменьшение RSS процесса?

Ответ: Нет. После того как старая map станет недостижимой, GC может освободить её объекты внутри управляемой кучи, но runtime может оставить полученные у ОС страницы для повторного использования. Поэтому heap-профиль, объём памяти, доступный аллокатору, и RSS могут уменьшаться в разное время или не уменьшаться заметно.

3. Вопрос: Почему нельзя считать len(map) оценкой памяти, занятой map?

Ответ: len показывает только число текущих записей. Он не отражает исторический пик размера, число внутренних бакетов, размер ключей и значений, выравнивание, служебные метаданные, а также память, удерживаемую значениями через ссылки. Для оценки используют профилирование heap и анализ жизненного цикла map, а не одно значение len.