В бенчмарке Go много раз создают значения типа struct{}. Почему число таких операций не обязательно означает сопоставимый рост heap и работы GC?
Значение нулевого размера не требует собственного участка памяти. Если такая переменная всё же попадает в heap, рантайм Go может использовать общий специальный адрес zerobase, поэтому для неё не создаётся отдельный сканируемый объект и не возникает пропорциональной нагрузки на сборщик мусора.
Кроме того, компилятор может полностью устранить создание значения, если оно не наблюдаемо за пределами функции. Поэтому количество операций в исходном коде, число реальных аллокаций и объём работы GC могут сильно различаться.
Поддержка типов нулевого размера позволяет описывать маркеры и множества без хранения данных в самом значении. Типичный пример — struct{}, который используется как пустое значение в map или как сигнал наличия свойства.
Чтобы такие конструкции не создавали отдельный объект на каждое значение, модель памяти Go допускает отсутствие выделенного хранилища для объекта нулевого размера. Это снижает расход памяти и накладные расходы аллокатора, сохраняя обычную типобезопасную семантику языка.
Разработчик видит в коде много созданий struct{} и ожидает пропорциональный рост heap, пауз GC и времени аллокаций. Такой вывод ошибочен: сначала нужно определить, действительно ли значения размещаются в памяти и имеют ли они ненулевой размер.
Нужно учитывать несколько рисков. Компилятор может удалить неиспользуемое создание, а измерение через слишком простой бенчмарк — само создание и вовсе не зафиксировать. С другой стороны, окружающая структура, срез или map всё равно могут требовать памяти независимо от размера элемента.
struct{} имеет размер 0 байт. Для обычной переменной это означает отсутствие полезного хранилища; переменная существует на уровне семантики языка, но не требует отдельного блока памяти для данных.
Если адрес такого значения нужен и объект должен считаться escaping, рантайм не обязан выделять уникальный блок под каждый экземпляр. Для нулевого размера используется общий служебный адрес, известный как zerobase. Это не означает, что все объекты Go размещаются там: механизм относится именно к объектам нулевого размера.
Такой объект не добавляет в heap отдельный диапазон памяти, который нужно обходить при маркировке. Поэтому он не создаёт обычной пропорциональной нагрузки на GC: сборщику нечего сканировать внутри объекта, и отсутствует отдельное полезное хранилище, которое нужно освобождать.
Однако компилятор может пойти ещё дальше. Если значение не выходит из области видимости и его наблюдаемое поведение не зависит от адреса, escape analysis и оптимизации могут убрать саму операцию создания. Поэтому корректно рассуждать нужно не по количеству синтаксических созданий, а по машинному коду, профилю и фактическим счётчикам аллокатора.
У адресов объектов нулевого размера нет полезной уникальности. Язык допускает, что адреса разных таких переменных совпадут, поэтому сравнение указателей на struct{} нельзя использовать для определения идентичности объектов.
Нулевой размер элемента не делает бесплатным контейнер. Срез всё равно хранит заголовок, а его длина и вместимость занимают память; для ненулевых элементов нужен backing array. У map остаются buckets, хеш-метаданные и указатели, если они предусмотрены конкретной реализацией. Кроме того, выравнивание и поля окружающей структуры могут добавить padding.
Следовательно, []struct{} может почти не требовать памяти под элементы, но большой map с ключами или сложной структурой всё равно может быть дорогим. Аналогично, замена значения структуры на struct{} убирает стоимость payload, но не стоимость самой записи контейнера.
В сервисе множество идентификаторов хранили в map[string]bool. Значение bool здесь не несло информации: важен был только факт присутствия ключа. Профиль показывал заметный расход памяти на map, и команда рассматривала два варианта.
Сохранить bool было проще и явно выражало наличие значения, но каждый bucket продолжал хранить ненужный payload. Заменить значение на struct{} позволяло убрать этот payload, но не устраняло стоимость строковых ключей, bucket-ов и роста map; также требовалось проверить читаемость кода и поведение операций доступа.
Выбрали map[string]struct{} и отдельно ограничили рост набора, удаляя устаревшие ключи. Результат проверили по heap-профилю, а не по числу операций создания struct{}: экономия появилась за счёт отсутствия данных значения, тогда как основная стоимость осталась в ключах и структуре map.
Означает ли нулевой размер, что значение никогда не попадает в heap?
Нет. Взятие адреса, возврат через интерфейс или передача в контекст, который переживает текущий вызов, могут повлиять на escape analysis. Но heap-размещение нулевого объекта не обязательно означает отдельную физическую аллокацию: рантайм может использовать общий адрес. Поэтому нужно различать факт escape и наличие отдельного блока памяти.
Можно ли сравнивать указатели на разные значения struct{}?
Нельзя использовать такое сравнение как проверку идентичности. Для объектов нулевого размера адреса могут совпадать, поскольку отдельное хранилище не требуется. Надёжно сравнивать следует сами значения или логические идентификаторы, а не адреса их нулевого payload.
Почему большой []struct{} всё же может влиять на память и производительность?
Нулевой размер элемента не отменяет стоимость метаданных среза и операций с ним. Сам backing array может не требовать пропорционального места под элементы, но рост длины, передача среза, проверки границ и окружающие структуры остаются. Если вместо struct{} используется структура с padding или хотя бы одним ненулевым полем, стоимость уже определяется её фактическим размером, а не намерением разработчика хранить только маркер.