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

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

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

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

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

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

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

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

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

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

Компилятор строит анализ живости локальных переменных и формирует для безопасных точек сведения о том, какие области стека содержат действующие указатели. GC использует эти сведения при сканировании стека: ссылка учитывается только в тех состояниях, где соответствующая переменная считается живой.

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

Момент освобождения всё равно не детерминирован. Даже после потери последней ссылки объект будет освобождён только во время последующего цикла GC, а память может остаться у аллокатора Go или операционной системы.

runtime.KeepAlive(value) создаёт специальную гарантию: значение считается используемым как минимум до этой точки. Это не освобождает память и не запускает GC, а только предотвращает преждевременное признание объекта недостижимым. Вызов следует размещать после операции, для которой объект должен оставаться живым.

Явное присваивание nil иногда помогает выразить намерение и уменьшить удержание крупного объекта, но не заменяет понимание карт живости: компилятор может самостоятельно определить отсутствие дальнейшего использования, а полагаться на ручное обнуление как на универсальную оптимизацию не следует.

Минимальный пример гарантии времени жизни:

package main

import "runtime"

func consume([]byte) {}

func process() {
    buf := make([]byte, 1<<20)
    consume(buf)
    runtime.KeepAlive(buf)
}

func main() { process() }

В реальном коде между consume и KeepAlive может находиться системный вызов или операция, использующая адрес буфера косвенно. В данном примере KeepAlive явно фиксирует границу, до которой буфер должен считаться живым.

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

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

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

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

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

Вопрос: Гарантирует ли выход из области видимости переменной немедленную доступность объекта для освобождения?

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

Ответ: Передача в функцию гарантирует живость только до момента, который действительно считается последним использованием значения. Если после вызова адрес объекта используется косвенно, например системным или небезопасным API, компилятор может не учитывать это скрытое использование. runtime.KeepAlive сообщает компилятору и рантайму, что объект должен оставаться живым до указанной точки; сам вызов не является барьером памяти и не предназначен для синхронизации горутин.
Вопрос: Может ли раннее прекращение жизни ссылки заметно ускорить GC само по себе?

Ответ: Да, если объект крупный или содержит много указателей и благодаря этому перестаёт быть достижимым до начала маркировки. Тогда GC не сканирует этот объект и его потомков, что может уменьшить время маркировки и пиковое удержание памяти. Но эффект зависит от момента следующей сборки и структуры графа объектов: если объект всё равно будет жив до ближайшего цикла GC, практической выгоды может не быть. Также раннее прекращение жизни ссылки не гарантирует немедленного снижения RSS процесса.