Стек, куча и escape-анализ: почему указатель ещё ничего не значит

Что здесь на самом деле спрашивают

Вопрос почти всегда звучит как «что размещается на стеке, а что в куче», и почти всегда ждут неверного ответа — того самого, что переносится из C: «локальные на стеке, new в куче».

В Go этого различия нет на уровне языка. Спецификация описывает &x не говоря ни слова о том, где лежит x; FAQ отвечает на вопрос отказом от вопроса:

Это не уход от ответа, а сам ответ: возврат указателя на локальную переменную в Go законен, и именно поэтому вопрос о размещении отдан компилятору.

Дальше идёт вторая половина того же абзаца FAQ — и вот она уже правило:

Три слова в нём делают всю работу. «Не может доказать» — значит, по умолчанию куча, а стек надо заслужить. «После возврата» — значит, вопрос про срок жизни, а не про синтаксис. И «обязан» — значит, это не оптимизация, а требование корректности.

База: два места, где может жить значение

Прежде чем разбирать анализ, стоит назвать обычными словами сами эти два места — без них весь дальнейший разговор висит в воздухе.

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

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

И вот главное, ради чего написан урок: в Go программист не выбирает между этими двумя местами напрямую. В языке нет ни new против стека, ни отдельного способа «положить в кучу»; спецификация о размещении молчит вовсе. Выбор делает компилятор, и делает его по одному вопросу: может ли значение понадобиться после того, как вызов закончился?

Два примера, на которых это видно без единого термина.

Первый. Функция создаёт структуру, читает из неё поле и возвращает число. После возврата до структуры уже никак не добраться: ссылок на неё не осталось нигде. Компилятор это видит и оставляет её в кадре: ноль выделений в куче.

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

Разница между примерами не в том, что во втором «появился указатель». Разница в том, что во втором значение нужно после возврата, а в первом нет. Это единственный критерий, и он работает в обе стороны: адрес, взятый и никуда не уехавший, значение в кучу не отправляет.

Этого уже достаточно, чтобы ответить на базовый вопрос собеседования. Дальше — про то, что путей «понадобиться после возврата» больше, чем кажется: значение уезжает в кучу через интерфейс, через замыкание, через тело чужой функции — и даже просто из-за длины, неизвестной на сборке.

Механизм 1: ссылка убегает

База назвала критерий словами. Теперь та же мысль в виде модели, по которой можно разбирать свой код: она про поток ссылок, а не про синтаксис.

Компилятор отслеживает, куда может попасть ссылка на значение, и задаёт по каждому пути один вопрос: переживёт ли она кадр?

Ни одна ветка этого дерева не спрашивает про &. Все спрашивают одно: не окажется ли ссылка достижимой после возврата. Отсюда и то, что «указатель» и «куча» — независимые вещи.

И отсюда же несимметричность, которую называет FAQ: компилятор обязан доказать, что ссылка НЕ переживает кадр. Не сумел доказать — значит куча. По умолчанию куча; стек надо заслужить.

Механизм 2: семь случаев и решение по каждому

Щёлкайте по строкам — и смотрите, где решение расходится с привычным правилом:

Числа выделений печатает прогон bench/goescape/internals.go:

Вторая строка ломает правило «указатель — значит куча». Пятая ломает обратное: & в коде нет вообще, а выделение есть.

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

Отсюда практическое, которое стоит назвать: go func() { ... }() внутри цикла отправляет в кучу всё, что захватил, — и это одна из самых частых незамеченных аллокаций в конкурентном коде.

А третья и четвёртая — самая содержательная пара. Вызов выглядит одинаково: в обоих случаях в функцию передаётся &s. Отличается тело вызываемой функции — и решение меняется. Значит, уход в кучу не свойство вызова, это свойство всей достижимости значения, посчитанной через границы функций.

Компилятор готов назвать своё решение сам. bench/goescape/decisions.sh просит его об этом флагом -gcflags='-m -l':

./practice.go:44:7:  &Point{...} does not escape
./practice.go:50:10: &Point{...} escapes to heap
./practice.go:57:10: p escapes to heap

Первая строка — тот самый случай: адрес взят, а значение осталось в кадре. Это, а не догадки по коду, и есть способ узнать ответ для своей функции.

И у всей этой таблицы есть граница, которую стоит назвать прямо: это решения нынешнего компилятора. Escape-анализ живёт в оптимизаторе, а не в языке — спецификация о размещении молчит, а оптимизатор от версии к версии становится умнее. Значит, строка, которая убегает сегодня, на следующей версии может не убегать, и наоборот; изменится это молча, без единой ошибки сборки. Поэтому запоминать стоит не список случаев, а способ спросить: -gcflags='-m' на своём коде и на той версии Go, которой вы собираете.

Механизм 3: почему fmt добавляет выделений — и когда не добавляет

Самая частая непрошеная куча в реальном коде приезжает не из указателей, а из логов:

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

Но почему тогда 42 не выделяет? Первая редакция этого замера печатала только 42, получила ноль — и тем самым опровергала собственный текст. Причина оказалась не в escape-анализе: у рантайма есть готовый массив значений 0–255, и упаковка малого числа берёт адрес оттуда, ничего не выделяя. На 256 кеш кончается, и выделение появляется.

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

Механизм 4: размер, известный только во время выполнения

Вторая строка не выводится ни из одного расхожего правила. Срез никуда не уходит — и всё равно куча.

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

Практический вывод узкий и потому полезный: в горячем пути константная длина буфера — это не педантизм, а разница между стеком и кучей. var buf [64]byte и buf := make([]byte, n) при n == 64 дают разный машинный код.

Глубже: сколько это стоит — и чего в этой цене нет

Одна и та же структура, собранная в функции, которая возвращает число, против той же в функции, возвращающей указатель:

И вторая половина, которая объясняет, почему одну кратность запоминать бесполезно:

Прежняя запись этого замера давала ×25,9 — вдвое больше. Она была снята, пока на той же машине шла сборка сайта. Выделение в куче страдает от конкуренции за память сильнее, чем работа со стеком, поэтому кратность раздувается: число, снятое на занятой машине, измеряет машину, а не язык. Кратность здесь вообще не стоит запоминать — стоит запомнить, от чего она зависит.

Стековая колонка от размера почти не зависит. Отвести место в кадре стоит одинаково: это сдвиг указателя стека, и он не знает, сколько байтов за ним. Кучная растёт вчетверо, потому что выделение включает обнуление всей области.

То есть уход в кучу — не фиксированная надбавка «за указатель», а работа, пропорциональная размеру значения. Первая редакция этого замера предсказывала обратное; данные пришлось принять, а текст переписать.

Чего в этой цене нет

Три вещи, без которых числа выше выдают себя за больше, чем есть.

Работы сборщика. Замер не даёт куче вырасти, поэтому она здесь не видна — а в настоящей программе выделенное потом надо пометить и подмести, и эта работа растёт вместе с объёмом мусора. Числа выше — нижняя оценка.

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

Того, что куча иногда быстрее. Значение в куче, пережившее много вызовов, выделяется один раз; то же значение «на стеке» в цикле может собираться и разбираться каждую итерацию. Escape-анализ — это про размещение, а не про скорость, и приравнивать «ушло в кучу» к «медленно» неверно ровно так же, как «указатель» к «куче».

Отсюда единственный работающий порядок действий: сначала профиль, потом -gcflags='-m'. Профиль говорит, стоит ли вообще смотреть; флаг говорит, куда именно.

И то и другое делают на своей версии Go. Кратность зависит от машины, а сам факт выделения — от компилятора: перенести сюда чужое число или чужой вывод «эта конструкция не выделяет» нельзя, их получают заново.

Как отвечать на собеседовании

Короткий ответ: в Go программист не выбирает между стеком и кучей — выбор делает компилятор, и вопрос у него один: переживёт ли значение свой кадр. Если доказать, что не переживёт, нельзя — куча. Поэтому возврат указателя на локальную переменную законен, а & в коде сам по себе о размещении не говорит ничего.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

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

Опровергните оба ходовых правила числами. «& ничего не значит: у меня указатель на локальную структуру дал ноль выделений. И наоборот — структура без &, но положенная в интерфейс, дала одно».

Назовите неочевидную причину. «make с длиной, известной только в рантайме, уходит в кучу, даже никуда не уезжая: кадр размечается на сборке».

Скажите, как узнать точно. «go build -gcflags='-m' — компилятор печатает does not escape и escapes to heap построчно. Гадать по коду не нужно».

И про цену — с оговоркой. «У меня вышло ×12,8 на мелкой структуре, но кратность растёт с размером: выделение включает обнуление. Плюс работа сборщика, которой в микрозамере не видно».

И одна вещь, на которой легко переусердствовать: список случаев — не контракт. Escape-анализ живёт в оптимизаторе компилятора, а не в спецификации, и от версии к версии меняется — то, что убегает сегодня, завтра может не убегать. Точная формулировка звучит так: решение читают у того компилятора, которым собирают, и читают заново после смены версии.

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

func local() {
p := Point{1, 2, 3, 4}
sinkN = p.X + p.W
}

func pointerStays() {
p := &Point{1, 2, 3, 4}
sinkN = p.X + p.W
}

func pointerEscapes() {
sinkP = &Point{1, 2, 3, 4}
}

func intoInterface() {
p := Point{1, 2, 3, 4}
sinkI = p
}

0
0
1
1

0
1
1
0

0
1
1
1

1
1
1
1

Проверка знаний