Стек goroutine, escape analysis и heap allocations

У каждой goroutine есть собственный небольшой stack, который runtime увеличивает по мере необходимости. Локальная переменная не обязана жить на stack: компилятор применяет escape analysis и помещает значение в heap, если его время жизни или адрес могут пережить текущий stack frame. Это оптимизация корректности и производительности, а не правило стиля «никаких указателей».

Зачем это на интервью

Нужно объяснить, почему миллионы goroutine не требуют миллиона больших стеков сразу, почему возврат указателя не обязательно плох и как отличить реально дорогую аллокацию от сообщения компилятора. Практический ответ связывает placement со сроком жизни, profile и семантикой API.

Минимум для E4

• Знать, что goroutine stack динамически растёт; его нельзя считать фиксированным stack потока ОС.
• Объяснять escape: значение уходит в heap, когда компилятор не может доказать, что stack lifetime достаточен.
• Знать типичные причины: возврат адреса, сохранение ссылки после вызова, захват переменной замыканием, упаковка в interface — но не считать их безусловными правилами.
• Проверять гипотезу go build -gcflags=-m=2 ./... или go test -gcflags=-m=2, затем benchmark/profile.
• Помнить, что inlining и версия компилятора меняют результат escape analysis.

Углубление для E5/Senior

Stack growth включает копирование stack и корректировку указателей runtime; удерживать адрес stack-переменной за пределами допустимого вызова нельзя. Поэтому код на unsafe не должен превращать pointer в uintptr и хранить его через потенциальную точку роста stack или GC. Публичный API проектируют ради ясного владения и данных, не ради принудительного placement.

Heap-стоимость — это allocation rate, scanning pointers, lifetime и contention allocator/GC. Иногда []T с одним backing array лучше множества *T; иногда указатели нужны для optional semantics или стабильной идентичности. Предвыделение capacity полезно, только если корректна верхняя граница и профиль подтверждает churn; чрезмерная capacity увеличивает retention.

package main
 
import "fmt"
 
type User struct{ Name string }
 
func newUser(name string) *User {
	// Адрес результата переживает frame функции; компилятор вправе выделить User в heap.
	return &User{Name: name}
}
 
func main() {
	fmt.Println(newUser("Ada").Name)
}

Такой код идиоматичен. Изменять его на значение имеет смысл только если API и измерения от этого выигрывают.

Ключевые понятия

Понятие	Суть	Проверка
Stack frame	параметры, локальные данные и служебная информация вызова	traceback/профиль, не размер RSS
Stack growth	runtime расширяет stack goroutine при необходимости	нагрузочный тест с глубокой рекурсией не как production-паттерн
Escape analysis	статический анализ компилятора	-gcflags=-m=2
Heap allocation	выделение вне текущего stack frame	-benchmem, alloc_space
Retention	достижимая память живёт дольше нужного	inuse_space, heap profile

Типовые вопросы

1. Всегда ли возврат *T создаёт heap allocation?
   • Нельзя обещать это как языковое правило: решение у компилятора и зависит от контекста/inlining. Но объект должен быть доступен после возврата, поэтому обычно потребуется размещение, эквивалентное более долгой жизни.
2. Почему маленький stack безопасен?
   • Stack goroutine начинается небольшим и runtime увеличивает его по необходимости; это позволяет создавать много goroutine без заранее выделенного большого stack.
3. Значит ли moved to heap, что код надо переписать?
   • Нет. Это диагностическая информация. Сначала оцените allocations/op и вклад в production profile.
4. Как closure вызывает escape?
   • Замыкание, запускаемое или сохраняемое после текущего вызова, должно иметь доступ к захваченным данным позже; компилятор обеспечивает нужное время жизни. Избегайте заодно захвата большой структуры, если нужна только часть.
5. Чем allocation отличается от retention?
   • Allocation — создание памяти, retention — удержание достижимой памяти. Быстрые временные аллокации могут давить на GC без утечки; медленный retention увеличивает live heap.
6. Нужно ли всегда передавать []byte вместо string?
   • Нет: разные семантика, mutability и конверсии. Выбирайте формат на границе API и измеряйте hot path.

Практика

• Сравните два представления. Напишите benchmark обработки []User и []*User на реалистичном объёме.
  • Критерии готовности: есть -benchmem, объяснены allocation, locality и требуемая семантика; нет вывода только по ns/op.
• Найдите escape. Скомпилируйте маленький пакет с -gcflags=-m=2 и сопоставьте два сообщения с кодом.
  • Критерии готовности: указано, какое время жизни требует heap; после изменения запущены тесты и benchmark.
• Устраните retention. Сконструируйте пример хранения малого slice большого буфера и сделайте явную копию нужных байтов.
  • Критерии готовности: heap profile показывает уменьшение retained bytes, а тест подтверждает неизменность результата.

Частые ошибки и ловушки

• Считать pointer синонимом heap, а value — stack.
• Переписывать понятный API ради отсутствия одного escape.
• Предвыделять огромный slice «на всякий случай» и удерживать лишнюю память.
• Хранить uintptr на месте Go pointer через вызов, который может выделять память или запускать GC.
• Использовать глубокую рекурсию как нормальный способ обхода неограниченного ввода.

Связанные темы

Go runtime и память · GC · Локальность данных · Allocation rate

Источники

• Go specification: implementation restrictions (проверено 2026-10-02).
• Compiler diagnostics: -m (проверено 2026-10-02).
• Go GC guide: stacks and roots (проверено 2026-10-02).
• Package unsafe (проверено 2026-10-02).