Ошибка	Последствие
Считать, что место (стек/куча) определяет ключевое слово, а не escape analysis	Неверная ментальная модель аллокаций — не объяснить профиль `-gcflags=-m`
Думать, что стек goroutine фиксированного размера	Не понять, почему горутина дёшева и почему глубокая рекурсия не падает мгновенно
Полагать, что указательные типы всегда живут в куче	Промах с местом размещения — указатель на локальную переменную часто остаётся в стеке
Считать, что slice передаётся по ссылке	Не объяснить, почему `append` внутри функции иногда виден снаружи, а иногда нет
Думать, что копия slice независима от оригинала	Баг с alias — запись через одну копию портит элементы другой
Путать `len` и `cap`	Неверное представление о том, когда `append` реаллоцирует backing array
Думать, что `append` расширяет backing array на месте	Не объяснить, почему после реаллокации старые срезы не видят новых элементов
Считать, что `append` всегда удваивает ёмкость	Неверная оценка памяти — для больших срезов коэффициент меньше
Называть escape analysis runtime-механизмом	Промах с пониманием — это статический анализ времени компиляции
Думать, что `make` с переменной длиной может остаться в стеке	Неверная оценка аллокаций — неизвестный размер принудительно уходит в кучу
Считать map деревом или плоским массивом	Не объяснить overflow-бакеты, рандомизацию итерации и поведение при коллизиях
Брать адрес элемента map через `&m[k]`	Код не компилируется — элемент map не адресуем
Думать, что эвакуация бакетов происходит вся сразу	Неверная модель стоимости вставки — эвакуация размазана по последующим записям

advanced

Memory in Go — The Compiler Decides Where Data Lives

Stack versus heap, escape analysis, array and slice internals, slice growth, map internals, and element addressability.

go-memory

Sections

Contents

Detailed explanation

Memory in Go — The Compiler Decides Where Data Lives

Go has no new and delete in the C++ sense — it has a garbage collector, and that creates the illusion that data placement needs no thought. The illusion is dangerous: where a value actually lives — in a frame's stack or in the GC-managed heap — is decided by the compiler at compile time, and that decision directly drives how much work the collector inherits. An unnecessary escape to the heap will not break the program, but it turns a cheap local into a load on the GC.

This topic's traps cluster around three misconceptions. First — that placement is decided by the keyword (var, new, make): in reality escape analysis picks it from how the value is used. Second — that a slice is passed "by reference": in reality its three-word header is copied, and two copies start sharing one backing array, hence aliasing bugs. Third — that a map can be addressed like a plain array: &m[k] does not compile, and the reason is the incremental evacuation of buckets during growth. This topic dissects Go memory layer by layer — from the layout of a goroutine stack to map rehashing.

Topic Map

Stack vs heap — each goroutine has its own small growable stack, the GC-managed heap, and the compiler decides where a value lives.
Arrays vs slices — an array is a fixed-size value copied wholesale, a slice is a header over a backing array.
The slice header — three machine words {pointer, len, cap} and why a header copy shares elements with the original.
Escape analysis — a compile-time pass that decides whether a value outlives its frame and therefore escapes to the heap.
Forced heap allocation — cases beyond ordinary escape: unknown size, too-large value, interface conversion.
Slice growth — why append past cap allocates a new backing array, and what the growth factor is.
Map internals — the runtime hmap struct, an array of 8-slot buckets, tophash, and overflow buckets.
Map element addressability — why &m[k] does not compile and how bucket evacuation relocates entries.

Common Mistakes and Traps

Mistake	Consequence
Believing the keyword decides stack vs heap rather than escape analysis	Wrong allocation model — cannot read a `-gcflags=-m` profile
Thinking a goroutine stack has a fixed size	Cannot explain why a goroutine is cheap or why deep recursion does not fault instantly
Assuming pointer types always live on the heap	Wrong placement guess — a pointer to a local often stays on the stack
Believing a slice is passed by reference	Cannot explain why `append` inside a function is sometimes visible outside and sometimes not
Thinking a slice copy is independent of the original	Aliasing bug — a write through one copy corrupts the other's elements
Confusing `len` and `cap`	Wrong idea of when `append` reallocates the backing array
Thinking `append` extends the backing array in place	Cannot explain why old slices do not see new elements after a reallocation
Believing `append` always doubles capacity	Wrong memory estimate — for large slices the factor is smaller
Calling escape analysis a runtime mechanism	Conceptual miss — it is a static, compile-time analysis
Thinking a `make` with a variable length can stay on the stack	Wrong allocation estimate — an unknown size is forced to the heap
Treating a map as a tree or a flat array	Cannot explain overflow buckets, iteration randomization, or collision behaviour
Taking the address of a map element via `&m[k]`	The code does not compile — a map element is not addressable
Thinking bucket evacuation happens all at once	Wrong cost model for inserts — evacuation is spread across later writes

Interview Relevance

Memory is a mandatory topic at any serious Go interview. The interviewer checks not whether you know the word "heap", but whether you have a working model of what the compiler decides versus what the runtime decides — and where it hits performance.

What interviewers usually check:

The difference between stack and heap — who frees each region and when, who picks the location.
What escape analysis is — a static compiler pass, not runtime observation.
Why an array is copied wholesale while a slice is copied by header only, and what aliasing bugs follow.
The three fields of a slice header and how they change on a reslice.
How a slice grows on append past cap and why the result must be assigned back.
The internal layout of a map — buckets, tophash, overflow buckets, growth and rehashing.
Why &m[k] does not compile and what incremental bucket evacuation is.

A typical wrong answer: "a slice is a reference type, passed by reference." This opens a discussion that it is exactly the three-word header copied by value — which is why an append that reallocated the backing array is invisible outside the function, while an append within cap is visible through the shared array.

Why it matters

Go hides memory management behind a garbage collector, making it feel like data placement is not your concern. Yet half of Go's performance problems live exactly here — unnecessary escapes to the heap, slice reallocations in a hot loop, unexpected aliasing through a shared backing array. Without knowing what the compiler decides and what the runtime decides, you cannot explain an allocation profile or a bug where `append` corrupted a neighbouring slice.

Ошибка	Последствие
Считать, что место (стек/куча) определяет ключевое слово, а не escape analysis	Неверная ментальная модель аллокаций — не объяснить профиль `-gcflags=-m`
Думать, что стек goroutine фиксированного размера	Не понять, почему горутина дёшева и почему глубокая рекурсия не падает мгновенно
Полагать, что указательные типы всегда живут в куче	Промах с местом размещения — указатель на локальную переменную часто остаётся в стеке
Считать, что slice передаётся по ссылке	Не объяснить, почему `append` внутри функции иногда виден снаружи, а иногда нет
Думать, что копия slice независима от оригинала	Баг с alias — запись через одну копию портит элементы другой
Путать `len` и `cap`	Неверное представление о том, когда `append` реаллоцирует backing array
Думать, что `append` расширяет backing array на месте	Не объяснить, почему после реаллокации старые срезы не видят новых элементов
Считать, что `append` всегда удваивает ёмкость	Неверная оценка памяти — для больших срезов коэффициент меньше
Называть escape analysis runtime-механизмом	Промах с пониманием — это статический анализ времени компиляции
Думать, что `make` с переменной длиной может остаться в стеке	Неверная оценка аллокаций — неизвестный размер принудительно уходит в кучу
Считать map деревом или плоским массивом	Не объяснить overflow-бакеты, рандомизацию итерации и поведение при коллизиях
Брать адрес элемента map через `&m[k]`	Код не компилируется — элемент map не адресуем
Думать, что эвакуация бакетов происходит вся сразу	Неверная модель стоимости вставки — эвакуация размазана по последующим записям

advanced

Memory in Go — The Compiler Decides Where Data Lives

Stack versus heap, escape analysis, array and slice internals, slice growth, map internals, and element addressability.

go-memory

Practice: 16 questions · 4 tasks →

Sections

Contents

Detailed explanation

Memory in Go — The Compiler Decides Where Data Lives

Topic Map

Stack vs heap — each goroutine has its own small growable stack, the GC-managed heap, and the compiler decides where a value lives.
Arrays vs slices — an array is a fixed-size value copied wholesale, a slice is a header over a backing array.
The slice header — three machine words {pointer, len, cap} and why a header copy shares elements with the original.
Escape analysis — a compile-time pass that decides whether a value outlives its frame and therefore escapes to the heap.
Forced heap allocation — cases beyond ordinary escape: unknown size, too-large value, interface conversion.
Slice growth — why append past cap allocates a new backing array, and what the growth factor is.
Map internals — the runtime hmap struct, an array of 8-slot buckets, tophash, and overflow buckets.
Map element addressability — why &m[k] does not compile and how bucket evacuation relocates entries.

Common Mistakes and Traps

Mistake	Consequence
Believing the keyword decides stack vs heap rather than escape analysis	Wrong allocation model — cannot read a `-gcflags=-m` profile
Thinking a goroutine stack has a fixed size	Cannot explain why a goroutine is cheap or why deep recursion does not fault instantly
Assuming pointer types always live on the heap	Wrong placement guess — a pointer to a local often stays on the stack
Believing a slice is passed by reference	Cannot explain why `append` inside a function is sometimes visible outside and sometimes not
Thinking a slice copy is independent of the original	Aliasing bug — a write through one copy corrupts the other's elements
Confusing `len` and `cap`	Wrong idea of when `append` reallocates the backing array
Thinking `append` extends the backing array in place	Cannot explain why old slices do not see new elements after a reallocation
Believing `append` always doubles capacity	Wrong memory estimate — for large slices the factor is smaller
Calling escape analysis a runtime mechanism	Conceptual miss — it is a static, compile-time analysis
Thinking a `make` with a variable length can stay on the stack	Wrong allocation estimate — an unknown size is forced to the heap
Treating a map as a tree or a flat array	Cannot explain overflow buckets, iteration randomization, or collision behaviour
Taking the address of a map element via `&m[k]`	The code does not compile — a map element is not addressable
Thinking bucket evacuation happens all at once	Wrong cost model for inserts — evacuation is spread across later writes

Interview Relevance

What interviewers usually check:

The difference between stack and heap — who frees each region and when, who picks the location.
What escape analysis is — a static compiler pass, not runtime observation.
Why an array is copied wholesale while a slice is copied by header only, and what aliasing bugs follow.
The three fields of a slice header and how they change on a reslice.
How a slice grows on append past cap and why the result must be assigned back.
The internal layout of a map — buckets, tophash, overflow buckets, growth and rehashing.
Why &m[k] does not compile and what incremental bucket evacuation is.

Why it matters

Память в Go — где живут данные решает компилятор

Память в Go — где живут данные решает компилятор

Карта темы

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

Значение для собеседований

Memory in Go — The Compiler Decides Where Data Lives

Memory in Go — The Compiler Decides Where Data Lives

Topic Map

Common Mistakes and Traps

Interview Relevance

Память в Go — где живут данные решает компилятор

Память в Go — где живут данные решает компилятор

Карта темы

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

Значение для собеседований

Memory in Go — The Compiler Decides Where Data Lives

Memory in Go — The Compiler Decides Where Data Lives

Topic Map

Common Mistakes and Traps

Interview Relevance