Escape analysis: стек или куча?

Вопрос с собеседования: «Вы создаёте переменную через &User{} внутри функции — где она окажется: на стеке или в куче? От чего это зависит?»

Этот вопрос — практически классика для Go-собеседований среднего и продвинутого уровня. Чтобы ответить на него уверенно, нужно понять, что такое escape analysis («анализ побега», можно перевести и как «анализ утечки за пределы функции»).

Два места, где живут переменные: стек и куча

Прежде чем говорить про escape analysis, вспомним, что в памяти программы есть два основных «склада» для данных:

Стек (stack) — это память, которая выделяется под конкретный вызов функции и автоматически освобождается, когда функция завершает работу. Работа со стеком очень быстрая: чтобы выделить память, процессору достаточно просто сдвинуть указатель, а не искать свободное место. У каждой горутины в Go — свой собственный стек.

Куча (heap) — это общая память, из которой можно выделить участок на произвольное время, а не только на время работы одной функции. Куча гибче, но работа с ней дороже: нужно найти свободный участок подходящего размера, а освобождать его позже придётся сборщику мусора (о котором мы говорили в прошлом уроке).

Так вот, ключевой вопрос: когда компилятор Go решает создать переменную на стеке, а когда — в куче? Программист в Go, в отличие от C, не пишет это явно — за него решает компилятор. Именно это решение и называется escape analysis.

Что значит «переменная убегает» (escapes)

Название «escape analysis» дословно означает «анализ побега». Компилятор анализирует код и проверяет: не «убегает» ли переменная за пределы функции, в которой была создана? Если однозначно нет — переменную можно безопасно разместить на быстром стеке, она умрёт вместе с завершением функции, и это нормально. Если переменная может понадобиться и после того, как функция закончит работу, — компилятор вынужден разместить её в куче, чтобы она не исчезла раньше времени.

Разберём классический пример:

func onStack() int {
    x := 42
    return x // возвращаем значение x, а не ссылку на x
}

func onHeap() *int {
    y := 42
    return &y // возвращаем указатель на y!
}

В функции onStack мы возвращаем само значение 42 — копию числа. После возврата из функции переменная x компилятору больше не нужна ни в каком виде, поэтому она спокойно живёт и умирает на стеке.

А вот в функции onHeap мы возвращаем &y — адрес переменной y. Это значит, что после завершения onHeap кто-то снаружи будет обращаться к этой памяти по указателю. Если бы y лежала на стеке функции onHeap, эта память была бы уничтожена сразу после возврата — и указатель показывал бы «в никуда». Поэтому компилятор говорит: «эта переменная убегает» — и размещает y в куче, где она проживёт столько, сколько нужно, а сборщик мусора удалит её позже, когда на неё не останется ссылок.

Как это работает под капотом

Escape analysis выполняется компилятором Go на этапе компиляции — то есть ещё до запуска программы, статически, без замера реального поведения. Компилятор строит граф того, как используется каждая переменная, и ищет любой путь, по которому ссылка на неё могла бы «утечь» за границы функции. Самые частые причины «побега»:

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

Важный нюанс, который часто ловит кандидатов: то, что переменная создана через new() или оператор &, ещё не гарантирует, что она окажется в куче. Это лишь синтаксис создания указателя — а решение «стек или куча» принимает escape analysis отдельно, исходя из того, как эта переменная используется дальше.

Как самому проверить, куда «убежала» переменная

Go предоставляет удобный флаг компилятора, который показывает решения escape analysis прямо в терминале:

go build -gcflags="-m" main.go

Вывод (пример для функции onHeap):

./main.go:7:2: moved to heap: y

Строка moved to heap: y прямо говорит: компилятор решил, что переменная y должна жить в куче, а не на стеке. Это один из самых практичных инструментов для реального Go-разработчика — и заодно отличный факт для собеседования, показывающий, что вы не просто знаете теорию, но умеете её проверить.

Почему это влияет на производительность

Здесь и кроется главная практическая ценность escape analysis. Размещение на стеке — почти бесплатно и не создаёт работы для сборщика мусора. Размещение в куче — дороже при выделении и добавляет объект в список того, что рано или поздно придётся обработать GC. Если в горячем, часто вызываемом участке кода (например, в цикле, обрабатывающем тысячи запросов в секунду) переменные постоянно «убегают» в кучу без необходимости, это создаёт лишнюю нагрузку и на выделение памяти, и на сборщик мусора — программа замедляется, хотя видимых причин в бизнес-логике вроде бы нет.

Частые ошибки на собеседовании

«Указатель — всегда куча, значение — всегда стек» — неверно. Указатель на локальную переменную вполне может остаться на стеке, если компилятор докажет, что переменная не переживёт функцию (компилятор умеет встраивать — inline — маленькие функции и оптимизировать такие случаи).
«Программист явно управляет, где разместить переменную» — нет, в Go нет ключевых слов вроде stack/heap. Решение полностью на стороне компилятора, программист может только писать код так, чтобы облегчить компилятору «безопасный» вывод.
Путают escape analysis с garbage collection — это разные, хоть и связанные механизмы: escape analysis решает на этапе компиляции, где разместить переменную, а GC на этапе выполнения программы решает, когда освободить память объектов в куче.
Считают, что куча — это всегда плохо — нет, это нормальный и нужный механизм для данных, которые действительно должны жить дольше одного вызова функции. Проблема не в куче самой по себе, а в лишних, случайных «побегах» там, где без них можно было обойтись.

Итоги-шпаргалка

Escape analysis — это статический анализ, который компилятор Go выполняет во время компиляции, чтобы решить: может ли переменная безопасно жить на быстром стеке, или она «убегает» за пределы функции и должна быть размещена в более медленной, но гибкой куче. Переменная убегает, если на неё может остаться ссылка после завершения функции — например, при возврате указателя, передаче через интерфейс или захвате в замыкание. Проверить решение компилятора можно флагом go build -gcflags="-m". Чем реже переменные без нужды «убегают» в кучу, тем меньше работы для аллокатора памяти и сборщика мусора — а значит, выше производительность.