Ошибка	Последствие
Считать, что место (стек/куча) определяет ключевое слово, а не escape-анализ	Неверная ментальная модель аллокаций — не объяснить профиль `-gcflags=-m`
Думать, что стек goroutine фиксированного размера	Не понять, почему горутина дёшева и почему глубокая рекурсия не падает мгновенно
Полагать, что указательные типы всегда живут в куче	Промах с местом размещения — указатель на локальную переменную часто остаётся в стеке
Называть escape-анализ runtime-механизмом	Промах с пониманием — это статический анализ времени компиляции
Думать, что взятие адреса локальной переменной всегда вызывает escape	Escape наступает, только если адрес переживает кадр, — иначе значение в стеке
Думать, что escape-анализ — единственное, что кладёт значение в кучу	Неизвестный размер, слишком крупное значение и конверсия в interface уходят в кучу принудительно
Думать, что `make` с переменной длиной может остаться в стеке	Неверная оценка аллокаций — неизвестный размер принудительно уходит в кучу
Считать, что `make` возвращает указатель	Указатель отдаёт только `new`; `make` возвращает само значение `slice`/`map`/`chan`
Применять `new` к `map` или каналу	`new(map[K]V)` даёт `*map` над `nil`-картой — запись по ней паникует, для рабочей карты нужен `make`
Считать, что одинаковый `O(n)` обещает одинаковую скорость	На последовательном обходе `slice` обгоняет список из-за локальности и prefetch, а не асимптотики
Хранить горячие данные как `[]*T` ради «дешевизны»	Лишняя косвенность разбрасывает объекты по куче и убивает аппаратный prefetch

advanced

Memory in Go

Stack versus heap, escape analysis, forced heap allocation, new versus make, and cache locality.

go-memory

Sections

Contents

Detailed explanation

Memory in Go

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 one misconception — that placement is decided by the keyword (var, new, make). In reality escape analysis picks it from how the value is used: a pointer to a local often stays on the stack, while a plain var escapes to the heap if its address leaks. On top of that there are cases where a value lands on the heap beyond ordinary escape — unknown size, too-large value, interface conversion. And the upshot of the layout shows up in speed: a contiguous slice beats a linked list not because of asymptotics but because of cache locality. This topic dissects Go memory layer by layer — from the layout of a goroutine stack to hardware prefetch.

Topic Map

Stack vs heap — each goroutine has its own small growable stack, the GC-managed heap, and the compiler — not the keyword — decides where a value lives.
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.
new and make — new(T) gives a zeroed *T for any type; make initializes a slice, map, or channel and returns a ready value, not a pointer.
Cache locality — a contiguous slice beats a linked list on sequential traversal thanks to prefetching and rare cache misses.

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
Calling escape analysis a runtime mechanism	Conceptual miss — it is a static, compile-time analysis
Thinking taking the address of a local always triggers an escape	An escape happens only if the address outlives the frame — otherwise the value stays on the stack
Thinking escape analysis is the only thing that puts a value on the heap	Unknown size, an over-large value, and interface conversion are forced to the heap
Thinking a `make` with a variable length can stay on the stack	Wrong allocation estimate — an unknown size is forced to the heap
Believing `make` returns a pointer	Only `new` returns a pointer; `make` returns the `slice`/`map`/`chan` value itself
Applying `new` to a `map` or channel	`new(map[K]V)` gives a `*map` over a `nil` map — writing to it panics; use `make` for a working map
Believing equal `O(n)` promises equal speed	On a sequential traversal a `slice` beats a list due to locality and prefetch, not asymptotics
Storing hot data as `[]*T` for "cheapness"	The extra indirection scatters objects across the heap and kills hardware prefetch

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 the value's type alone does not decide placement — a pointer to a local often stays on the stack.
Which cases send a value to the heap beyond ordinary escape — unknown size, excessive size, interface conversion.
How new differs from make — a zeroed pointer versus a ready structure, and why neither controls placement.
Why a contiguous slice beats a linked list on sequential traversal — cache lines and hardware prefetch.

A typical wrong answer: "pointer types always live on the heap." This opens a discussion that it is not the type but escape analysis that decides: a pointer to a local that never leaves its frame stays on the stack, and the placement is visible with the -gcflags=-m flag.

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 load the GC, and a pointer to a local can unexpectedly stay on the stack. Without knowing that placement is decided by the compiler's escape analysis rather than by a keyword, you cannot explain an allocation profile under -gcflags=-m or why new sometimes does not go to the heap.

Ошибка	Последствие
Считать, что место (стек/куча) определяет ключевое слово, а не escape-анализ	Неверная ментальная модель аллокаций — не объяснить профиль `-gcflags=-m`
Думать, что стек goroutine фиксированного размера	Не понять, почему горутина дёшева и почему глубокая рекурсия не падает мгновенно
Полагать, что указательные типы всегда живут в куче	Промах с местом размещения — указатель на локальную переменную часто остаётся в стеке
Называть escape-анализ runtime-механизмом	Промах с пониманием — это статический анализ времени компиляции
Думать, что взятие адреса локальной переменной всегда вызывает escape	Escape наступает, только если адрес переживает кадр, — иначе значение в стеке
Думать, что escape-анализ — единственное, что кладёт значение в кучу	Неизвестный размер, слишком крупное значение и конверсия в interface уходят в кучу принудительно
Думать, что `make` с переменной длиной может остаться в стеке	Неверная оценка аллокаций — неизвестный размер принудительно уходит в кучу
Считать, что `make` возвращает указатель	Указатель отдаёт только `new`; `make` возвращает само значение `slice`/`map`/`chan`
Применять `new` к `map` или каналу	`new(map[K]V)` даёт `*map` над `nil`-картой — запись по ней паникует, для рабочей карты нужен `make`
Считать, что одинаковый `O(n)` обещает одинаковую скорость	На последовательном обходе `slice` обгоняет список из-за локальности и prefetch, а не асимптотики
Хранить горячие данные как `[]*T` ради «дешевизны»	Лишняя косвенность разбрасывает объекты по куче и убивает аппаратный prefetch

advanced

Memory in Go

Stack versus heap, escape analysis, forced heap allocation, new versus make, and cache locality.

go-memory

Practice: 8 questions →

Sections

Contents

Detailed explanation

Memory in Go

Topic Map

Stack vs heap — each goroutine has its own small growable stack, the GC-managed heap, and the compiler — not the keyword — decides where a value lives.
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.
new and make — new(T) gives a zeroed *T for any type; make initializes a slice, map, or channel and returns a ready value, not a pointer.
Cache locality — a contiguous slice beats a linked list on sequential traversal thanks to prefetching and rare cache misses.

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
Calling escape analysis a runtime mechanism	Conceptual miss — it is a static, compile-time analysis
Thinking taking the address of a local always triggers an escape	An escape happens only if the address outlives the frame — otherwise the value stays on the stack
Thinking escape analysis is the only thing that puts a value on the heap	Unknown size, an over-large value, and interface conversion are forced to the heap
Thinking a `make` with a variable length can stay on the stack	Wrong allocation estimate — an unknown size is forced to the heap
Believing `make` returns a pointer	Only `new` returns a pointer; `make` returns the `slice`/`map`/`chan` value itself
Applying `new` to a `map` or channel	`new(map[K]V)` gives a `*map` over a `nil` map — writing to it panics; use `make` for a working map
Believing equal `O(n)` promises equal speed	On a sequential traversal a `slice` beats a list due to locality and prefetch, not asymptotics
Storing hot data as `[]*T` for "cheapness"	The extra indirection scatters objects across the heap and kills hardware prefetch

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 the value's type alone does not decide placement — a pointer to a local often stays on the stack.
Which cases send a value to the heap beyond ordinary escape — unknown size, excessive size, interface conversion.
How new differs from make — a zeroed pointer versus a ready structure, and why neither controls placement.
Why a contiguous slice beats a linked list on sequential traversal — cache lines and hardware prefetch.

Why it matters

Память в Go

Память в Go

Карта темы

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

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

Memory in Go

Memory in Go

Topic Map

Common Mistakes and Traps

Interview Relevance

Память в Go

Память в Go

Карта темы

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

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

Memory in Go

Memory in Go

Topic Map

Common Mistakes and Traps

Interview Relevance