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

Сборщик мусора Go рассматривает действительный указатель внутрь выделенного объекта как ссылку на весь объект. Поэтому указатель на один элемент большого массива или среза удерживает живым весь backing array, а освободить только часть такой аллокации GC не может.

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

Язык Go допускает работу с указателями на элементы массивов и срезов. Поэтому сборщик мусора должен корректно обрабатывать не только указатели на начало аллокации, но и внутренние указатели — адреса, указывающие на её часть.

Такой подход сохраняет простую семантику указателей: пока существует действительный указатель на элемент, память, содержащая этот элемент, не может быть освобождена. Обратная сторона — небольшая ссылка иногда продлевает жизнь крупного объекта.

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

Представим, что приложение читает большой буфер, сохраняет указатель на один байт, а сам буфер больше не использует. Логически нужен один байт, но физически живым остаётся объект, содержащий весь буфер.

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

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

Во время маркировки GC находит объект, которому принадлежит обнаруженный адрес. Если адрес указывает внутрь выделенного объекта, объект помечается целиком. Сборщик мусора не делит одну аллокацию на независимые части и не освобождает неиспользуемые байты внутри неё.

Для среза важно различать сам дескриптор и backing array. Копирование дескриптора среза обычно сохраняет ссылку на backing array; указатель на элемент также удерживает backing array, поскольку элемент находится внутри этой аллокации.

Минимальный пример:

package main

import "runtime"

var saved *byte

func keepOneByte() {
    buf := make([]byte, 100<<20)
    saved = &buf[50]
}

func main() {
    keepOneByte()
    runtime.GC()
}

После keepOneByte переменная saved указывает внутрь большого массива, поэтому вызов GC не может освободить весь buf. Само значение одного байта не содержит информации о том, что остальная аллокация больше не нужна.

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

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

Сервис разбирал сообщения размером до 64 МБ и сохранял указатель на небольшой идентификатор внутри входного буфера. В результате очередь из нескольких сотен идентификаторов удерживала гигабайты памяти, хотя каждый идентификатор занимал десятки байт.

Рассматривались два варианта: хранить указатель на исходный буфер или копировать идентификатор. Первый вариант не требовал копирования, но удерживал крупные аллокации и увеличивал нагрузку на GC. Второй добавлял небольшую стоимость копирования, зато позволял освобождать исходные буферы.

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

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

1. Удерживает ли указатель на элемент среза только часть среза?

Нет. Срез — это дескриптор с длиной, вместимостью и указателем на backing array, а элемент находится внутри backing array. Любая действительная ссылка на элемент удерживает живой объект, выделенный под соответствующий массив; GC не освобождает отдельные неиспользуемые элементы внутри него.

2. Всегда ли присваивание большого среза меньшему срезу копирует данные?

Нет. Обычное получение под-среза создаёт новый дескриптор, но обычно не копирует backing array. Поэтому небольшой под-срез может продолжать удерживать весь исходный массив. Если нужно отделить небольшой результат от большого источника, данные копируют в новый компактный буфер.

3. Может ли runtime.KeepAlive уменьшить удерживаемую память?

Нет. runtime.KeepAlive только гарантирует, что указанный объект считается достижимым до определённой точки программы. Он не ограничивает размер удерживаемой аллокации и не позволяет GC освободить её часть. Если указатель указывает внутрь большого объекта, KeepAlive фактически гарантирует сохранение всего этого объекта до указанной точки.