Модуль 22 ⏱ ~301 мин чтения 📐 3 Mermaid диаграмм

06. Память. Stack, Heap, Escape Analysis

«Память — это не просто абстрактная последовательность байтов; это физическое устройство со своими задержками, линиями кэша и стоимостью перемещения заряда. Программист, который понимает это, пишет код в разы быстрее».
— Брайан Керниган

Архитектура памяти: стек, куча, escape analysis и Mechanical Sympathy

В языке Go управление памятью гибридное: разработчик не вызывает вручную malloc и free, но компилятор с помощью статического анализа побега (escape analysis) стремится аллоцировать как можно больше объектов на сверхбыстром стеке горутины, снижая нагрузку на сборщик мусора (GC).

flowchart TD
    classDef start   fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef check   fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef stack   fill:#064e3b,stroke:#34d399,stroke-width:2px,color:#f8fafc
    classDef heap    fill:#1e1b4b,stroke:#818cf8,stroke-width:2px,color:#f8fafc

    Var["Создание переменной в функции"]:::start --> CheckEscape{"Escape Analysis:<br/>1. Возвращается ли указатель наружу?<br/>2. Передаётся ли в interface{} / any?<br/>3. Превышает ли размер лимит стека?<br/>4. Размер динамический (срез переменной длины)?"}:::check

    CheckEscape -->|"НЕТ: время жизни ограничено вызовом"| Stack["Стек горутины (SP смещение)<br/>• Стоимость: 0 ns (1 такт CPU)<br/>• Освобождение: мгновенно при RET<br/>• Нагрузка на GC: 0%"]:::stack

    CheckEscape -->|"ДА: ссылка переживает фрейм"| Heap["Куча рантайма (runtime.newobject)<br/>• Стоимость: поиск в mcache/mcentral<br/>• Освобождение: сборщик мусора (GC)<br/>• Нагрузка: маркировка + sweep STW"]:::heap

flowchart LR
    classDef old    fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc
    classDef modern fill:#1e1b4b,stroke:#818cf8,stroke-width:2px,color:#f8fafc
    classDef step   fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc

    subgraph StackGrowth["Динамический непрерывный стек (Go 1.4+)"]
        S2KB["Старт: 2 КБ"]:::step -->|"Стек заполнен (morestack)"| S4KB["Аллокация непрерывного буфера 4 КБ"]:::step
        S4KB --> Copy["Копирование всех фреймов + коррекция указателей"]:::modern
        Copy --> S8KB["Рост: 8 КБ ... до 1 ГБ (x64)"]:::step
    end

flowchart TD
    classDef strong fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef weak   fill:#78350f,stroke:#fbbf24,stroke-width:2px,color:#f8fafc
    classDef gc     fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc
    classDef dead   fill:#7f1d1d,stroke:#f87171,stroke-width:1px,color:#f8fafc

    Strong["Сильная ссылка (*T)"]:::strong --> Obj["Объект в куче"]:::gc
    Weak["Слабая ссылка (weak.Pointer[T])"]:::weak -.-> Obj

    GC1{"Сборщик мусора (GC):<br/>Есть ли сильные ссылки?"}:::gc
    Obj --> GC1
    GC1 -->|"Да"| Live["Объект жив, weak.Value() возвращает *T"]:::strong
    GC1 -->|"Нет"| Collected["Объект утилизируется, weak.Value() возвращает nil"]:::dead

TEXT

+-----------------------------------------------------------------------------------+
|                  Виртуальное адресное пространство процесса Go                    |
| [ Текст программы (.text) ] [ Данные (.data / .rodata) ] [ Стеки горутин ] [ Куча ]|
|            <-- Низкие адреса                        Высокие адреса -->             |
+-----------------------------------------------------------------------------------+

Навигатор по вопросам главы

Что такое стек (stack)?
Что такое куча (heap)?
Чем стек быстрее кучи?
Что такое аллокация (allocation)?
Что такое escape analysis?
Как компилятор решает, где разместить переменную на стеке или в куче?
Примеры, когда переменная убегает (escape) в кучу?
Как closures вызывают escape?
Что такое указатель (pointer)?
Когда использовать указатель?
Что такое выравнивание памяти (memory alignment)?
Что такое заполнение (padding)?
Что такое строка кэша (cache line)?
Что такое ложное разделение (false sharing)?
Как избежать false sharing?
Что такое zero allocation?
Как уменьшить количество аллокаций?
Как посмотреть escape analysis с помощью go build -gcflags="-m"?
Что такое профилирование памяти (memory profiling)?
Чем отличается аллокация на стеке от аллокации в куче с точки зрения GC?
Как работает unsafe.Pointer?
Когда использование unsafe.Pointer может привести к проблемам с GC?
Что такое uintptr и чем он отличается от unsafe.Pointer?
Как интерфейсы влияют на размещение переменных в памяти (interface boxing)?
Почему передача больших структур по указателю может быть эффективнее?
Почему передача маленьких структур по значению может быть эффективнее?
Что такое «агрессивное встраивание» (inlining) функций и как оно связано с escape analysis?
Как работает garbage collector для переменных в куче?
Что такое write barrier и зачем он нужен?
Как устроен менеджер памяти Go (TCMalloc)?
Что такое mcache, mcentral, mheap?
Как работает аллокация для объектов разных размеров (tiny, small, large)?
Что такое стек горутины и как он растет и сжимается?
Какие проблемы могут возникнуть при использовании cgo с точки зрения управления памятью?
Как бороться с утечками памяти (memory leak) с помощью профилировщика?
Что такое "раздувание кучи" (heap fragmentation) и как оно влияет на производительность?
Как размер страницы памяти ОС влияет на аллокатор Go?
Что такое "arena allocation" (Go 1.20+) и какие проблемы она решает?
Как вручную освободить память в Go (кроме сборщика мусора)?
Как работает runtime.SetFinalizer и какие риски с ним связаны?
Что такое sync.Pool и как он помогает переиспользовать память?
Как проверить, что слайс или мапа не ссылаются на старый большой массив после обрезания?
Что такое "live heap" и как его анализировать?
Как работает сборщик мусора в условиях нехватки памяти?
Как escape analysis работает с дженериками?
Что такое «аллокация на стеке с динамическим размером» и возможна ли она?
Как профилирование кучи помогает найти источники аллокаций?
Как использование string vs []byte влияет на аллокации?
Что такое "heap dump" и как его проанализировать?
Что такое weak.Pointer в Go 1.24?

Что такое стек (stack)?

Краткий ответ (30–60 секунд)

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

Развёрнутый ответ

Стек в Go — это сегмент памяти горутины, работающий как классический стек вызовов. Он хранит:

Локальные переменные, которые не «убежали» в кучу.
Сохранённые регистры и адреса возврата (через frame pointer).
Аргументы функций и возвращаемые значения (частично через регистры, но для больших — через стек).

Go использует сегментированный стек (ранее) и копирующий стек (ныне): при переполнении текущего размера runtime выделяет новый, вдвое больший сегмент, копирует данные и освобождает старый. Благодаря этому горутины стартуют с крошечным стеком (2 КБ), а максимальный размер виртуального адресного пространства позволяет вырасти до ~1 ГБ. Стек растёт вниз (на x86/amd64), указатель стека SP отслеживает вершину.

Пример стековой переменной:

func calc() int {
    x := 42        // x на стеке
    y := x + 1     // y на стеке
    return y
}

Стек работает быстро: выделение — вычитание из SP, освобождение — прибавление. Никакой фрагментации, синхронизации или обхода GC. Однако стек ограничен временем жизни фрейма функции — нельзя вернуть указатель на локальную переменную, не вызвав её перемещения в кучу (escape analysis это запретит, либо переменная переедет в кучу).

Под капотом (internals)

Структура g (горутина) содержит поля stack (lo, hi) и stackguard0 — граница, при пересечении которой срабатывает вызов runtime.morestack.
В файле runtime/stack.go: stackalloc выделяет стек (из пула или mmap). copystack корректирует указатели при копировании стека (использует map от старых адресов к новым во время GC).
runtime·morestack (ассемблер) вызывает newstack, которая растёт или сжимает стек. Сжатие происходит при GC, если используется менее ¼ текущего размера.
Frame pointer (RBP) включается с Go 1.7+ для точных стек-трейсов; компилятор может не выделять отдельный frame pointer, если не нужен.

Типичные ошибки кандидатов

Утверждение, что стек всех горутин статического размера — неверно. Стек растёт динамически, это ключевое преимущество горутин перед потоками ОС (у которых фиксированный стек ~1–8 МБ). Исправляется уточнением, что начальный размер 2 КБ, а рост кратен 2.
Мнение, что «стек автоматически сжимается при уменьшении использования» — сжатие происходит не сразу и только во время GC, когда горутина неактивна. Неверно полагать, что освобождённая память немедленно возвращается ОС: она может оставаться в пуле для будущих аллокаций. Стоит упомянуть, что runtime.Stack и shrink выполняются лениво.
Игнорирование опасности возврата указателя на локальную переменную — новичок может ожидать, что такое работает. На деле escape analysis помещает переменную в кучу, либо (в старых языках) это приводит к висячему указателю. Нужно помнить, что Go защищает от этого, но ценой кучи.

Возможные дополнительные вопросы интервьюера

Как горутина возвращает занятую стеком память обратно ОС?
Она не возвращает активно; shrink-процесс освобождает избыточные сегменты при GC, и если сегмент не используется, он может быть возвращён ОС через madvise или munmap (для больших сегментов). Подробности в runtime.(*mheap).scavenge.

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

Что такое куча (heap)?

Краткий ответ (30–60 секунд)

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

Развёрнутый ответ

Куча в Go — это общая для всего процесса структура, где размещаются:

Переменные, «убежавшие» из стека (возврат указателя, запись в глобальную переменную, замыкание, отправка в канал);
Большие объекты (в Go 1.22 порог large — >32 КБ);
Объекты с динамическим размером, неизвестным на этапе компиляции (слайсы с переменной длиной, мапы);
Интерфейсные значения (boxing).

Аллокатор Go основан на TCMalloc (thread-caching malloc): каждый P (логический процессор) имеет локальный кэш mcache, что снижает конкуренцию. Память запрашивается у ОС страницами (8 КБ для small, более крупные через mheap). Объекты в куче подлежат отслеживанию GC; пока на объект есть живая ссылка, он не может быть освобождён.

Пример escape-объекта:

func newInt(n int) *int {
    x := n
    return &x   // x перемещается в кучу
}

Под капотом (internals)

Реализация в runtime/malloc.go. Глобальные структуры: mheap (управляет span'ами — непрерывными областями памяти), mcentral (связные списки спанов одного класса размера, общие для P), mcache (локальный кэш на P).
Размеры малых объектов сгруппированы в классы (67 классов до 32 КБ). Класс tiny (до 16 байт) — микровыделения объединяются в один tiny-блок.
При выделении вызывается runtime.mallocgc(size, type, flags). Если объект не содержит указателей (flag noscan), GC не сканирует его содержимое, что экономит время.
Куча собирается конкурентным tri-color марк-свипом; фаза mark включает установку write barrier для отслеживания изменений.

Типичные ошибки кандидатов

Считать, что переменная автоматически попадает в кучу, если она большая — это не совсем так: переменная может быть большой и всё равно остаться на стеке, если не escape'ит. Компилятор допускает стековые аллокации больших объектов (до некоторого предела), если их размер известен. Понятие «большой» для кучного аллокатора — это >32 КБ, но escape analysis решает сам.
Полагать, что GC освобождает всю кучу сразу — GC в Go работает циклами, освобождая только недостижимые объекты, и делает это инкрементально, не «мир останавливается» на всё время. Неверно говорить «stop-the-world на время mark».
Не понимать разницы между выделением в куче на 0 байт — make([]int, 0) может вернуть ненулевой указатель на пустой заголовок, выделенный в куче, даже если данные не аллоцированы. Это считается аллокацией. В high-perf коде нужно избегать таких мест.

Возможные дополнительные вопросы интервьюера

Что происходит при нехватке памяти в куче?
Runtime пытается увеличить кучу, запрашивая у ОС дополнительную память через mmap. Если ОС отказывает (например, превышен лимит ulimit), происходит аварийное завершение с OOM (out of memory). GC запускается чаще, но может не спасти.

Как посмотреть размер кучи в работающем приложении?
Через runtime.ReadMemStats(&ms), поле ms.HeapAlloc показывает живой размер. Или через профилировщик pprof.

Чем стек быстрее кучи?

Краткий ответ (30–60 секунд)

Стек быстрее по трём причинам: (1) выделение/освобождение — O(1) смещением указателя, без фрагментации и блокировок; (2) локальность данных — стек компактен и почти гарантированно в L1/L2 кэше; (3) не требует GC — память освобождается автоматически при выходе из функции. Куча же включает поиск свободного блока, возможную синхронизацию, сканирование GC и более разбросанные по памяти объекты.

Развёрнутый ответ

Стековая аллокация — это вычитание из регистра SP на суммарный размер фрейма (stack frame). Компилятор знает оффсеты на этапе компиляции. Освобождение — просто восстановление SP при возврате. Никаких вызовов аллокатора, atomics или сложных структур.

В куче выделение проходит через runtime.mallocgc, который:

классифицирует размер, выбирает кэш mcache;
возможно, обновляет указатели в mcache с помощью atomics (при заполнении тред-локального буфера);
для больших объектов сразу идёт в mheap с блокировкой;
на многопоточных системах mcache может быть недостаточно, идёт синхронизация с mcentral;
GC обязан сканировать объект (если содержит указатели) и обновить метаданные;
освобождение не мгновенное, а после цикла GC, следовательно, время жизни объектов влияет на частоту GC и STW паузы.

Кроме того, данные на стеке локальны для горутины и расположены линейно, что радует предсказатель ветвлений и prefetcher. Куча же со временем становится фрагментированной, указатели разлетаются по разным span'ам, вызывая промахи кэша.

Под капотом (internals)

В ассемблерном выводе функция с только стековыми переменными имеет пролог SUBQ $size, SP и эпилог ADDQ $size, SP. Никаких CALL в runtime, кроме morestack (если не хватает места).
runtime.mallocgc может пропустить фактический вызов, если tiny-аллокация обслуживается из tiny-слота в mcache, но даже это несколько инструкций + проверка переполнения.
Профилирование CPU с perf показывает, что аллокации в куче часто идут через runtime.mallocgc и runtime.findObject, что заметно в flamegraph.

Типичные ошибки кандидатов

Стек «бесплатен» и всегда быстрее — забывают, что копирование стека при росте влечёт перемещение данных и обновление указателей, что может быть дорогим, если происходит часто в горячей рекурсии. Однако это всё равно реже, чем кучевые аллокации при обычном коде.
Сравнивать только выделение, забывая про GC — при высокой частоте аллокаций в куче основные накладные расходы создаёт не сам malloc, а последующая сборка мусора (mark+scan+Sweep). Стековые переменные не нагружают GC совсем.
Игнорировать влияние на локальность кэша — при анализе производительности на микроуровне промахи кэша из-за разбросанных объектов могут быть дороже в 10-50 раз.

Возможные дополнительные вопросы интервьюера

Насколько быстрее в цифрах?
Микро-бенчмарки показывают разницу до 10-100 нс на операцию для аллокации, но реальное преимущество стека измеряется в снижении GC pressure и лучшей пропускной способности (до 2-5x на аллокационно-нагруженных сервисах).

Как балансировать между стеком и кучей?
Следовать принципу «не убегай без необходимости», использовать value-семантику для маленьких структур, sync.Pool для тяжёлых объектов, pre-size слайсы, избегать boxing.

Что такое аллокация (allocation)?

Краткий ответ (30–60 секунд)

Аллокация — процесс резервирования участка памяти под новую переменную или структуру данных. В Go она бывает стековой (бесплатное смещение SP) и кучной (вызов mallocgc). С точки зрения GC, аллокацией считается лишь размещение в куче; именно её стараются минимизировать для высокой производительности.

Развёрнутый ответ

Понятие «аллокация» в Go-сообществе почти всегда означает heap allocation — событие, при котором runtime выделяет память в управляемой куче. Стековые размещения тоже технически являются выделением памяти, но их стоимость пренебрежимо мала и они не отслеживаются GC, поэтому в инструментах (-benchmem, trace) аллокацией считается именно heap allocation.

Почему важно: каждая аллокация увеличивает HeapAlloc, после достижения порога GOGC (по умолчанию 100%) запускается GC. Следовательно, количество аллокаций прямо влияет на частоту и длительность сборки мусора. Оптимизация “zero allocation” означает избежание любых выделений в куче на горячем пути.

Пример: создание слайса через make([]byte, 0, 1024) — аллоцирует массив на 1024 байта в куче (если переменная не уместилась на стеке/не escape). Измеряется как 1 аллокация.

Под капотом (internals)

При компиляции каждая операция, потенциально размещающая объект в куче, аннотируется вызовом runtime.newobject или runtime.mallocgc. Escape analysis решает, будет ли реальный вызов или достаточно стека.
runtime.mallocgc принимает размер и тип (с флагами, указателями для GC). Возвращает указатель на выделенную область.
-gcflags="-m" показывает, где компилятор вставил newobject (пометка “escapes to heap”).
Бенчмарк testing.B считает allocs/op через memstats.Mallocs (число вызовов mallocgc).

Типичные ошибки кандидатов

Путать «аллокацию» с выделением только больших объектов — каждое new(int) в куче — это аллокация, даже 8 байт.
Полагать, что var x []int создаёт аллокацию — это лишь заголовок слайса (указатель, len, cap), который часто помещается на стек. Аллокация происходит при make или append, если недостаточно ёмкости.
Забывать про неявные аллокации — например, fmt.Println(a...) аллоцирует []interface{} для boxing’а аргументов, конкатенация строк через + в цикле может порождать множество временных строк.
Игнорировать tiny-аллокации — множество мелких выделений (до 16 байт) объединяются в один tiny-блок, но Mallocs всё равно увеличивается на 1 за каждое; это всё ещё аллокация, влияющая на GC.

Возможные дополнительные вопросы интервьюера

Можно ли измерить, сколько процессорного времени занято аллокациями?
Да, через go tool pprof с параметром -alloc_space и -inuse_space, а также сэмплирование CPU профиля покажет mallocgc в top-функциях.

Что такое «аллокация на 0 байт» и опасна ли она?
Это вызов mallocgc(0, ...), который возвращает указатель runtime.zerobase — общий ненулевой адрес (не нулевой указатель!). Сама операция считается аллокацией только если параметр не константный 0 или создаётся слайс/мапа с нулевой длиной через make, где тип динамически загружен. В коде вида var a *int = new(int) и var b *int = nil разное поведение счётчиков.

Что такое escape analysis?

Краткий ответ (30–60 секунд)

Escape analysis (EA) — статический анализ компилятора Go, определяющий, может ли ссылка на переменную пережить стековый фрейм, в котором она создана («убежать»). Если да — переменная размещается в куче; иначе остаётся на стеке. Это ключевая оптимизация для снижения нагрузки на GC и повышения производительности.

Развёрнутый ответ

EA работает на этапе компиляции в пакете cmd/compile/internal/escape. Он анализирует поток ссылок: каждое присваивание, передача в функцию, возврат, помещение в интерфейс, замыкание — проверяет, может ли указатель (или значение, содержащее указатели) быть доступным после возврата функции. Основные причины escape:

Возврат указателя на локальную переменную.
Присваивание переменной глобальной переменной или полю структуры, которая переживает фрейм.
Запись в interface{} (boxing) всегда помещает значение в кучу, если компилятор не может доказать, что оно не покинет функцию. С Go 1.15+ появился devirtualization, но не всегда.
Замыкания: переменные, захваченные функцией, которая может быть вызвана после возврата.
Отправка в канал (переменная может быть прочитана другой горутиной позже).
Слайс, который передан в append с потенциальным ростом ёмкости.

EA снижает heap allocations без вмешательства программиста. Понимание EA позволяет писать более производительный код: передача маленьких структур по значению вместо указателей, избегание лишних boxing’ов.

Пример:

func dummy() *int {
    x := 42
    return &x // escapes to heap
}

Под капотом (internals)

Исходный код: src/cmd/compile/internal/escape/escape.go. Анализ выполняется на SSA-форме, но начиная с Go 1.16 он интегрирован в SSA-бэкенд; ранее был в отдельном AST-проходе.
Компилятор строит граф потоковых путей, помечая узлы как noescape или escapes. Использует алгоритм, основанный на abstract escape analysis, с учётом форм указателей на структуры.
Функции могут быть аннотированы //go:noescape для запрета анализа утекания (но это опасно и только для linkname и runtime).
Вывод флагов -m показывает решение: "x escapes to heap", "x does not escape".

Типичные ошибки кандидатов

Утверждать, что escape analysis всегда помещает переменные в кучу, если они возвращаются по указателю — это верно, но есть исключения, когда возвращаемый указатель указывает на аргумент или глобальную переменную; тогда сама переменная, на которую указывает, может быть не в куче, но указатель — да. Нюанс.
Думать, что EA предотвращает утечки памяти (memory leak) — EA лишь управляет размещением, но не освобождает память. Утечки возникают, когда ссылка на большой массив сохраняется, хотя нужна лишь малая часть (например, срез от большого слайса сохраняет весь массив в куче).
Полагать, что передача по значению гарантирует отсутствие escape — если структура содержит указатели, которые могут убежать (например, поле *int), то сама структура может escape, так как содержит ссылки, убегающие наружу.
Забывать, что интерфейсный параметр вызывает escape аргумента, даже если функция его не сохраняет — при вызове fmt.Println(x) происходит boxing x в интерфейс, и значение копируется в кучу, если x не фит в регистр (int, float до 16 байт могут поместиться в регистры, но все равно при boxing копируются).

Возможные дополнительные вопросы интервьюера

Как EA работает с дженериками (type parameters)?
В Go 1.18+ дженерики компилируются с помощью специализации либо shape-компиляции. EA выполняется после мономорфизации, так что для каждого типа параметра анализ корректен. Иногда из-за shape-реализации параметр передаётся через указатель и может вызвать escape, хотя при специализации он оставался бы на стеке. Подробнее в Как escape analysis работает с дженериками?.

Может ли компилятор ложно «убеждать» переменную, и что с этим делать?
Да, иногда консервативный анализ заставляет абсолютно локальный объект уйти в кучу (например, из-за вызова метода, который компилятор не может проанализировать). Помогает рефакторинг — разбить на чистые функции, убрать интерфейсные вызовы, использовать конкретные типы.

Как компилятор решает, где разместить переменную: на стеке или в куче?

Краткий ответ (30–60 секунд)

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

Развёрнутый ответ

Алгоритм можно представить так:

Компилятор строит граф потока данных для каждой функции (SSA).
Для каждой локальной переменной отслеживаются все операции, в которых она участвует.
Если операция «передаёт» указатель на переменную:
- Возврату из функции (return &x) — сразу escape.
- Записи в глобальную переменную или в поле структуры, которая уже убежала — escape.
- Передаче как аргумент в функцию, которая может сохранить указатель за пределами своего фрейма (анализ функции проводится, если она в том же пакете; иначе считается консервативно — аргумент-указатель в неанализируемую функцию убегает).
- При помещении в interface{} или any: данные копируются в кучу вместе с заголовком интерфейса (unless small types that fit in registers, but interface always stores pointer to underlying data if it's a pointer-like thing).
- При записи в слайс или мапу (реферер может сохраниться).
Замыкание захватывает переменную по ссылке; если замыкание может быть вызвано после возврата — переменные уходят в кучу.
Компилятор также учитывает размер: очень большие локальные переменные (> определённого порога) могут быть принудительно отправлены в кучу, но escape analysis всё равно сначала решает по ссылкам. Размер влияет, если компилятор не может быть уверен, что переменная не переполнит стек (но это эвристика).

Важно: переменная размещается целиком в куче/стеке. Нельзя «атомы» части.

Под капотом (internals)

В cmd/compile/internal/escape, функция assignments связывает адреса и прослеживает flow. leaks параметр показывает, может ли ссылка протечь.
Интерфейсный boxing: в runtime.convT2E, convT2I — данные копируются в кучу всегда, если не малый скаляр (type size <= 16 байт, содержит только числа/указатели), тогда они могут быть скопированы в кучу, но всё равно бокс-объект создаётся на куче. См. src/runtime/iface.go.
Для огромных локальных переменных (например, [1_000_000]int) стек мог бы не вместить; компилятор помечает их как large и отправляет в кучу явно.

Типичные ошибки кандидатов

Предположение, что решение зависит от рантайма — нет, это чисто compile-time.
Утверждение, что GC влияет на это решение — GC работает с уже размещёнными объектами, не участвует в выборе.
Игнорирование влияния инлайнинга — если функция встраивается (inlining), её локальные переменные становятся частью вызывающей функции, и EA может передумать: то, что убегало, может остаться на стеке. И наоборот.
Мнение, что new(T) всегда в куче — если возвращаемое значение не ссылается на *T, то new(T) может быть на стеке (Go не запрещает создавать указатели на стек). Компилятор часто размещает объект на стеке и возвращает указатель на него в рамках одного фрейма, если убеждён в отсутствии escape.

Возможные дополнительные вопросы интервьюера

Можно ли форсировать размещение в куче?
Да, явно взять адрес и вернуть его из внешней функции, либо использовать reflect.ValueOf, интерфейсы. Но специальной директивы //go:heap нет; это считается плохой практикой.

Как отлаживать, почему переменная попала в кучу?
go build -gcflags="-m=3" выводит подробные причины escape. Также можно смотреть SSA-дамп (GOSSAFUNC=func go build).

Примеры, когда переменная убегает (escape) в кучу?

Краткий ответ (30–60 секунд)

Основные сценарии: возврат указателя на локальную переменную, сохранение в глобальную переменную/поле внешней структуры, передача в канал, закрытие замыканием, которое может быть вызвано позже, приведение к интерфейсу (если значение не малое скалярное), запись в слайс/мапу, результат fmt-функций, методы с указателями при передаче значения.

Развёрнутый ответ

Возврат указателя:
Go
```
func newInt() *int { x := 1; return &x } // escapes
```

Сохранение в глобаль:

var global *int
func foo() { x := 1; global = &x } // escapes

Замыкание:

func outer() func() {
    x := 0
    return func() { x++ } // x escapes
}

Передача в канал:

func send() { ch := make(chan *int,1); x := 5; ch <- &x } // x escapes

Интерфейсный boxing:
Go
```
func printn(n int) { fmt.Println(n) } // n escaped (boxed to any)
```
Даже var e interface{} = 42 — 42 целиком в куче, если компилятор не оптимизирует.

Слайс с убегающим элементом:

func subset() []*int {
    var s []*int
    x := 10
    s = append(s, &x) // x escapes
    return s
}

Структура с указателем, возвращаемая значением — поля-указатели могут заставить структуру escape:
Go
```
type Wrap struct { p *int }
func makeWrap() Wrap {
    x := 1
    return Wrap{&x} // escapes, т.к. p указывает на убежавший x
}
```
Вызов метода с pointer receiver у значения — v.Method() приводит к взятию адреса v, если v может быть изменён, но чаще v уже на стеке и адрес не убегает. Однако если метод вызывает escape ссылки — значение может переместиться.

Под капотом (internals)

Escape analysis присваивает «уровень» (depth) переменной. Присваивание ссылки переменной с меньшим уровнем (например, return имеет уровень -1) вызывает escape.
Для каналов: ch <- val помещает значение во внутренний буфер, который живёт в куче.
convT64 и подобные функции runtime копируют скаляр в кучу.

Типичные ошибки кандидатов

Не считать escape’ом передачу в канал — если канал небуферизованный, то после отправки значение копируется в стек ожидающей горутины? На самом деле: в runtime канал хранит «элемент» в своей внутренней структуре (независимо от буфера), поэтому значение всё равно копируется в область, выделенную в куче, принадлежащую hchan. Так что escape есть.
Утверждать, что make([]int, 0) без указателей не вызывает escape элементов — верно, базовый массив всё ещё в куче (если слайс возвращается или передаётся). Сам факт make часто создаёт массив в куче, даже без ссылочных элементов.
Пропускать boxing при использовании reflect.ValueOf — всегда копирует значение в кучу.

Возможные дополнительные вопросы интервьюера

Всегда ли fmt.Println(x) вызывает heap-аллокацию для x?
Да, за исключением случаев, когда x — тип, не требующий боксинга для any (но any всё равно бокс). Для пустого интерфейса данные копируются в специальную структуру eface, указатель на которую передаётся, но копия данных создаётся в куче. Для маленьких фундаментальных типов компилятор может подставить специальный вызов runtime.convT64, который всё равно выделяет место под 8–16 байт в куче. Таким образом, формально heap-аллокация есть.

Как избежать боксинга при логировании?
Использовать библиотеки вроде zerolog или zap с typed-методами, избегая ...interface{}.

Как closures вызывают escape?

Краткий ответ (30–60 секунд)

Замыкание захватывает переменные по ссылке. Если функция-замыкание вызывается или возвращается из внешнего фрейма, все захваченные переменные, время жизни которых выходит за пределы внешней функции, перемещаются в кучу. Компилятор создаёт структуру «фрейма замыкания», размещая её в куче, и хранит там значения переменных.

Развёрнутый ответ

При определении замыкания Go компилятор создаёт не только анонимную функцию, но и неявную структуру, содержащую все захваченные переменные (по ссылке). Например:

func counter() func() int {
    var x int
    return func() int {
        x++
        return x
    }
}

Здесь x захватывается. Компилятор генерирует примерно:

type closure_data struct {
    x *int // на самом деле x *int, т.к. x размещается в куче
}

При вызове counter выделяется closure_data (или отдельно x в куче и указатель), а возвращаемая функция получает его как скрытый аргумент. Поскольку counter возвращает замыкание, x должен пережить вызов counter, следовательно escape в кучу.

Даже если замыкание не возвращается, но передаётся в другую функцию, которая может его сохранить (например, http.HandleFunc), переменные также убегут.

Захват по ссылке — ключевой момент. В цикле:

for i := 0; i < 3; i++ {
    go func() { fmt.Println(i) }()
}

Все горутины разделяют одну i, которая убегает в кучу (если i используется в замыкании). Чтобы получить копию на каждый литерал, создают локальную переменную i := i, но она тоже может escape, если горутина вызывается с go (передача через канал/аргумент может оставить на стеке).

Под капотом (internals)

В cmd/compile/internal/escape, анализ помечает захваченные переменные флагом addrescapes, что заставляет их размещаться в куче. Также сама структура замыкания размещается в куче.
Runtime: runtime.makemclosure может не вызываться, если компилятор специализирует.
Пример SSA: захваченная переменная становится PAUTOHEAP — псевдо-стековая, указывающая на heap.

Типичные ошибки кандидатов

Полагать, что замыкание копирует значение при создании — нет, захват по ссылке. Если не сделать локальную копию внутри цикла, все горутины увидят одно и то же значение.
Думать, что GC соберёт переменную замыкания сразу после последнего вызова — да, но структура замыкания в куче будет жить, пока жива функция, даже если переменные больше не нужны.
Не замечать неявные замыкания — например, defer func() { ... }() внутри цикла захватывает переменные и может сохранить в куче, если defer помещает функцию в список и вызывает при возврате (здесь часто escape не обязателен, но лучше проверять).

Возможные дополнительные вопросы интервьюера

Можно ли избежать кучи для замыкания, если оно вызывается синхронно в той же функции?
Да, если замыкание не сохраняется и не возвращается, EA часто может оставить захваченные переменные на стеке, а сама функция замыкания встраивается (inlining). Пример: func do() { x:=0; inc:=func(){x++}; inc() }.

Как профилировать аллокации от замыканий?
Профилирование кучи (pprof -alloc_space) покажет counter.func1 или подобное; также можно использовать -gcflags="-m".

Что такое указатель (pointer)?

Краткий ответ (30–60 секунд)

Указатель — это переменная, хранящая адрес памяти другой переменной. В Go указатели типизированы (*T), поддерживают адресную арифметику только через unsafe.Pointer, и являются ключевым механизмом для косвенного доступа, избегания копирования и обеспечения мутабельности через границы функции.

Развёрнутый ответ

Указатели Go семантически похожи на C-указатели, но безопаснее: нет арифметики без unsafe, сборщик мусора отслеживает их, чтобы не допустить dangling pointers. Значение указателя может быть nil. Они используются для:

Передачи больших структур без копирования.
Изменения переданного значения (мутация).
Реализации рекурсивных типов (linked list, tree).
Контроля времени жизни (куча vs стек).

Указатель занимает 8 байт на 64-бит. Создаётся оператором & (взятие адреса) или new(T). Разыменование — *p.

Память, на которую указывает указатель, может быть на стеке или куче. GC сканирует указатели, чтобы найти живые объекты.

Под капотом (internals)

Указатель в Go — не просто адрес, он может содержать специальные тэги в младших битах для точечного GC (используется runtime'ом, но не для обычных указателей).
Внутренне компилятор различает unsafe.Pointer как *ArbitraryType, который может быть сконвертирован в любой другой указатель. Это используется в runtime для манипуляции с памятью.
Для указателей на стеке GC знает, какие регистры/стековые слоты содержат указатели, через таблицы типов (stack maps).

Типичные ошибки кандидатов

Разменование nil-указателя — паника во время выполнения. Нужно всегда проверять на nil, когда указатель приходит извне.
Использование указателей на малые типы (int) для «эффективности» — это может привести к обратному эффекту: сам указатель занимает больше памяти (8 байт), чем int (4–8), и создаёт дополнительный уровень косвенности, а также может вызвать escape в кучу, что замедлит код.
Неправильное сравнение указателей — p1 == p2 сравнивает адреса, а не значения. Это корректно, но надо помнить.
Передача nil-указателя в функцию, которая разыменовывает без проверки — в Go принято возвращать ошибку, если параметр не может быть nil.

Возможные дополнительные вопросы интервьюера

Чем указатель отличается от ссылки в C++ и зачем в Go именно указатели?
В Go нет ссылок, есть только указатели; отсутствие арифметики и перегрузки операторов делает их проще. Указатели в Go могут быть nil, что требует проверки, тогда как ссылки в C++ не могут быть null; указатели в Go передаются явно с & и *, что улучшает читаемость.

Как GC обрабатывает циклы указателей?
GC Go — tri-color, не страдает от циклических ссылок, так как использует обход всего графа достижимых объектов, начиная с корней.

Когда использовать указатель?

Краткий ответ (30–60 секунд)

Используйте указатель, когда: (1) нужно изменить переданную переменную; (2) структура велика (больше 64–128 байт) и копирование дорого; (3) реализуете рекурсивный тип; (4) хотите различать «нулевое значение» и отсутствие значения (nil vs zero struct). Не используйте для малых immutable типов (int, bool, string), для ссылочных типов (slice, map, chan) и для оптимизации «на всякий случай» — это может ухудшить производительность и увеличить аллокации.

Развёрнутый ответ

Критерии выбора семантики:

Мутация: если функция должна изменить оригинал — обязателен указатель.
Размер: правило большого пальца — порог ~64 байт на 64-битных системах. Копирование 100-байтовой структуры дешевле, чем разыменование и возможный cache miss? На самом деле с развитием CPU (SIMD, memcpy) копирование до нескольких сот байт может быть быстрее, чем преследование указателя. Но если структура содержит указатели (string, slices) или мьютексы, копирование может быть семантически неверным. Общее: избегайте копирования структур, содержащих sync.Mutex (поле mutex нельзя копировать после использования).
Семантика nil: nil-указатель может означать «не задано». Но часто лучше использовать отдельный bool или интерфейс.
Рекурсивные типы: type Node struct { next *Node } — обязателен указатель, иначе бесконечный размер.
Интерфейсы: хранят указатель на данные автоматически, передача указателя на структуру, удовлетворяющую интерфейсу, выполняется через указатель интерфейса (если метод с pointer receiver).

Пример бенчмарка: передача [1024]byte по значению — эффективно (копируется 1 КБ, но зато локальность), а *[1024]byte вызывает аллокацию массива в куче и разыменование. Но если массив часто изменяется и должен быть общим, нужен указатель.

Под капотом (internals)

При передаче значения компилятор вставляет memmove для копирования. При передаче указателя — просто один регистр (или стековое слово). Но затем доступ к полям идёт через разыменование, что сложнее для CPU-предсказания и может вызвать miss L1.
Если структура содержит указатели, копирование значения требует барьерных вызовов GC (write barrier) при присваивании полей в копии? Нет, только при записи в кучу, если структура на стеке — просто копирование.
Escape analysis часто отправляет в кучу, если берется адрес локальной переменной и передаётся дальше, что сводит на нет преимущества.

Типичные ошибки кандидатов

Использовать указатели для «ускорения» без бенчмарков — микрооптимизация с указателями часто делает только хуже из-за кучи, GC и cache misses.
Передавать *sync.Mutex всегда — встраивание mutex в структуру и передача по указателю — ок. Но копирование структуры с mutex (по значению) приводит к неопределённому поведению (гонка, deadlock). Компилятор не предупредит. Решение: использовать go vet с copylocks.
Забыть, что slice уже содержит указатель на массив, и дополнительный *[]int почти никогда не нужен — он добавляет косвенность и может сделать escape. Достаточно передавать слайс по значению (заголовок 24 байта).
Использовать указатель вместо значения для tiny struct, создавая allocation — например, type Point struct{ x, y int } размером 16 байт; передача по значению — в регистрах или на стеке, без аллокаций, быстро.

Возможные дополнительные вопросы интервьюера

Есть ли правило от команды Go по выбору семантики?
Да, рекомендации: используйте value-семантику по умолчанию, отходите к указателям только при необходимости мутации или размера. Это идиоматично и безопасно.

Что такое «pointer-like type» и когда его не следует копировать?
Слайс, мапа, канал, функция — они содержат неявный указатель на внутренние структуры. Копирование заголовка безопасно, но разделяет базовый массив. Опасно копировать sync.Mutex, sync.Cond, sync.WaitGroup, структуры с noCopy.

Что такое выравнивание памяти (memory alignment)?

Краткий ответ (30–60 секунд)

Выравнивание — требование размещать данные в памяти по адресам, кратным их размеру (для примитивов) или определённым границам (для структур). Это необходимо для эффективного доступа CPU (атомарные операции без разрыва через границу слова) и является обязательным на некоторых архитектурах. Go компилятор автоматически выравнивает поля, может добавлять padding.

Развёрнутый ответ

Процессор читает память словами (обычно 4 или 8 байт). Если 8-байтовое значение размещено по адресу, не кратному 8, процессор будет выполнять два чтения и собирать значение, что медленно, а на некоторых архитектурах (ARM, RISC-V) вызывает исключение. Поэтому компиляторы вставляют padding между полями структур, чтобы каждое поле начиналось с адреса, кратного его размеру (или требуемому alignment). Например:

type Example struct {
    a bool    // 1 байт
    b int64   // 8 байт, требует смещения 8
}

a займет 1 байт, затем 7 байт padding, чтобы b начался со смещения 8. Общий размер — 16 байт вместо 9.

Выравнивание также важно для атомарных операций (sync/atomic): они требуют alignment для 32/64-битных значений, иначе на некоторых архитектурах паника или неатомарность.

Под капотом (internals)

unsafe.Alignof(x) возвращает требуемое выравнивание типа. Гарантии: alignof(int64) == 8, alignof(string) == 8 (строка — 16 байт: pointer+len, выравнивается по 8).
Компилятор в cmd/compile/internal/gc/align.go рассчитывает offsets, вставляет padding.
Для гарантий атомарности, если переменная может передаваться в atomic, нужно использовать 64-битное выравнивание. На 32-битных платформах int64 выравнен по 4, но Go добавляет padding до 8 для атомарности.
Внутренняя структура MemStats тщательно выровнена для атомарных обновлений.

Типичные ошибки кандидатов

Полагать, что размер структуры равен сумме размеров полей — забывают про padding.
Игнорировать выравнивание при размещении int64 в структуре на 32-битных системах — может нарушиться атомарность, если не использовать atomic.Int64 с гарантиями или struct { _ [0]func(); pad [12]byte } для выравнивания.
Переупорядочивать поля структуры ради экономии памяти, но не учитывать кэш-линии — избыточное внимание к padding без учета false sharing.
Думать, что go vet предупредит о невыровненных атомарных доступах — go vet не проверяет alignment; за это отвечает компилятор и runtime panic.

Возможные дополнительные вопросы интервьюера

Как оптимально упорядочить поля структуры?
Размещайте поля с наибольшим выравниванием первыми, чтобы минимизировать padding. Инструмент fieldalignment (из golang.org/x/tools) анализирует и предлагает оптимальный порядок.

Какое выравнивание у пустой структуры struct{}?
1 байт, но адрес может быть runtime.zerobase, одинаковый для всех; иногда пустые структуры имеют размер 0 и не занимают места в массиве? Размер struct{} равен 0, но в структуре с полем типа struct{} оно занимает 0 и не требует padding к следующему полю. Однако массив из struct{} также занимает 0 байт (указатели на элементы все равны одному адресу).

Что такое заполнение (padding)?

Краткий ответ (30–60 секунд)

Padding (заполнение) — неиспользуемые байты, вставляемые компилятором между полями структуры или после последнего поля для соблюдения выравнивания следующего поля или общей длины структуры. Нужно для корректного и быстрого доступа к полям, а также для гарантии атомарности.

Развёрнутый ответ

Padding бывает двух видов:

Внутренний padding (между полями): чтобы поле с большим выравниванием начиналось с правильного адреса.
Завершающий padding (trailing padding): чтобы общий размер структуры был кратен её максимальному выравниванию; это нужно, если структуры располагаются в массиве — тогда начало каждого элемента будет выровнено правильно.

Пример с завершающим padding:

type S struct {
    a byte      // 1 байт
    // 7 байт padding для выравнивания b
    b int64     // 8 байт
    c byte      // 1 байт, после него 7 байт trailing padding для размера кратного 8
}
// Размер 24 байта (1+7+8+1+7)

Padding автоматически вставляется компилятором. Он не инициализируется — содержит «мусор» (или нули при выделении в куче). Чтение padding неопределённо, но безопасно, т.к. не влияет на программу (если не использовать unsafe для чтения напрямую).

Под капотом (internals)

В cmd/compile/internal/types/size.go вычисляется Sizeof. Поля проходят по списку, для каждого вычисляется смещение, добавляется padding до нужной границы.
reflect.Type.Size() возвращает размер с учётом padding.
unsafe.Offsetof(expr) показывает смещение поля.

Типичные ошибки кандидатов

Считать, что порядок полей не влияет на размер — расстановка полей может сократить память до 30% в структурах с полями разного размера.
Использовать unsafe.Sizeof для подсчёта сериализуемого размера — padding делает структуру больше, чем нужно для передачи по сети. Лучше использовать бинарную сериализацию с заданным порядком байт (encoding/binary) или flatbuffers.
Предполагать, что структуры с одинаковыми полями в разном порядке бинарно совместимы — из-за разного размещения padding, прямой каст памяти небезопасен.

Возможные дополнительные вопросы интервьюера

Можно ли вручную убрать padding?
Да, с помощью struct { _ [N]byte }, но это опасно для производительности и переносимости. Лучше переупорядочить поля.

Как encoding/binary.Write обходит padding?
Она читает поля по очереди и сериализует только их значения, без padding.

Что такое строка кэша (cache line)?

Краткий ответ (30–60 секунд)

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

Развёрнутый ответ

Иерархия кэшей (L1, L2, L3) работает с блоками фиксированного размера — cache lines. Когда ядро читает или записывает память, оно загружает 64-байтовый блок (на большинстве современных x86). Если две независимые переменные находятся в одной строке, и каждое ядро часто обновляет одну из них, происходит непрерывная инвалидация строки в кэшах других ядер — это false sharing, сильно снижающее производительность.

Понимание cache lines помогает:

Оптимизировать горячие структуры: размещать часто изменяемые поля в разных линиях (через padding _ [64]byte).
Упорядочивать обработку данных в порядке их расположения в памяти (data-oriented design).
Использовать выравнивание по границе 64 байт.

Под капотом (internals)

Размер кэш-линии можно узнать через syscall.Getpagesize? Нет, через cpu.CacheLineSize в Go 1.19+ (пакет internal/cpu). На x86/amd64 обычно 64 байта.
В рантайме Go: runtime.pcHeader и другие структуры выровнены и дополнены для предотвращения false sharing между P (процессорами).
Атомарные переменные лучше размещать на своих линиях.

Типичные ошибки кандидатов

Игнорировать false sharing при использовании sync.Mutex или atomic в смежных полях — часто изменяемые поля разных горутин в одной структуре могут оказаться в одной линии и вызвать деградацию.
Полагать, что размер кэш-линии везде 64 байта — на ARM (Apple M1) 128 байт, на PowerPC может быть 128. Нужна адаптивность или использование cpu.CacheLinePad.
Чрезмерное использование padding для разделения полей увеличивает размер структуры и может снизить скорость из-за большего количества промахов — нужно профилировать.

Возможные дополнительные вопросы интервьюера

Как проверить, что у меня есть false sharing?
Профилировать счётчики производительности (perf stat) — смотреть на cache-misses, LLC-load-misses. Также можно написать бенчмарк с последовательным и конкурентным доступом.

Влияет ли false sharing на атомарные операции?
Да, даже атомарный инкремент на одном ядре заставляет другую строку быть инвалидированной, что увеличивает задержку (bus locking? нет, MESI-протокол).

Краткий ответ (30–60 секунд)

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

Развёрнутый ответ

Механизм: протокол когерентности кэшей (MESI) отслеживает состояния линий. Когда ядро модифицирует свою переменную, оно должно получить эксклюзивное владение всей кэш-линией, что заставляет другие ядра сбросить свою копию (invalidate). При следующем доступе другого ядра — промах, обращение к L3 или памяти. Если обновления частые, возникает «пинг-понг» линии между ядрами, снижая пропускную способность в десятки раз.

Пример на Go:

type Counters struct {
    A int64
    B int64 // если A и B часто обновляются разными горутинами и находятся в одной 64-байтовой линии, будет false sharing
}

Решение — разнести поля на разные кэш-линии с помощью padding:

type PaddedCounters struct {
    A int64
    _ [56]byte // на 64-байтовой системе заполнение до 64 байт
    B int64
}

Под капотом (internals)

Go runtime использует cpu.CacheLinePad (внутренний тип, доступный через internal/cpu.CacheLinePad) для горячих структур, таких как поля в runtime.m, runtime.p, чтобы избежать false sharing между P.
В runtime/sema.go и runtime/mheap.go есть padding-массивы.
Инструменты: perf c2c (cache-to-cache) анализирует false sharing.

Типичные ошибки кандидатов

Путать false sharing с true sharing (когда действительно одна переменная разделяется) — это разные вещи. False sharing скрыт, его трудно заметить без профилирования.
Добавлять padding, но не учитывать фактический размер строки (например, на Apple Silicon 128 байт) — padding должен соответствовать реальной длине кэш-линии.
Использовать [64]byte как padding, забывая про выравнивание самой структуры — лучше поместить padding перед полем или использовать поле-массив с оговоркой, что оно выровнено по границе поля за ним.

Возможные дополнительные вопросы интервьюера

Как измерить влияние false sharing на производительность?
Написать бенчмарк, где N горутин обновляют N отдельных переменных, сначала размещённых в одном массиве без отступов, затем с отступами 64 байта. Сравнить ns/op и масштабирование.

Может ли компилятор Go автоматически вставить padding для предотвращения false sharing?
Нет, это задача разработчика или специализированных линтеров. Компилятор только выравнивает поля для корректности доступа, но не для кэш-оптимизации.

Краткий ответ (30–60 секунд)

Разместите часто модифицируемые переменные, используемые разными потоками, в разных кэш-линиях. Для этого добавьте padding (массив байт) до границы следующей линии (обычно 64 байта). В Go 1.19+ можно использовать cpu.CacheLinePad. Также помогает минимизировать обновления (атомарные операции только когда необходимо), перейти на локальные переменные с периодической агрегацией.

Развёрнутый ответ

Конкретные приёмы:

Padding в структуре:
Go
```
type Stat struct {
    Requests int64
    _        [56]byte // заполнение до 64 байт
    Errors   int64
}
```
Либо выровнять по границе: использовать массив [64]byte перед полем.
Использовать cpu.CacheLinePad (Go 1.19+):
Go
```
import "internal/cpu"
type Stat struct {
   _         cpu.CacheLinePad
   Requests  int64
   _         cpu.CacheLinePad
   Errors    int64
}
```
CacheLinePad — это тип struct { _ [CacheLinePadSize]byte }, который гарантирует выравнивание по размеру линии.
Разделить горячие данные по отдельным объектам, доступ к которым индивидуален.
Уменьшить частоту записи — агрегировать локальные счётчики на горутине, сбрасывать в общий счётчик периодически.
Использовать sync.Pool или thread-local кэши для снижения общих модификаций.

Под капотом (internals)

internal/cpu.CacheLinePadSize определён в internal/cpu/cpu_amd64.go как 64, в arm64 как 128 (на некоторых).
Расположение полей в рантайме: runtime.m содержит _ cpu.CacheLinePad между procid и g0 для разделения часто используемых полей разных P.

Типичные ошибки кандидатов

Применять padding без понимания паттернов доступа — padding увеличивает размер, может вытеснить полезные данные из кэша, что снизит производительность. Нужно профилировать.
Использовать фиксированный размер 64 байта на всех платформах — на некоторых ARM это 128, что приведёт к неэффективности.
Размещать padding в начале структуры, не убедившись, что это не нарушит выравнивание последующих полей — это безопасно, но может сбить с толку анализаторы.

Возможные дополнительные вопросы интервьюера

Какие инструменты помогают обнаружить false sharing?
Linux perf c2c, Valgrind --tool=cachegrind, в Go можно написать детектор на основе сэмплирования счётчиков. Также полезны бенчмарки.

Стоит ли добавлять padding в структуры, которые сериализуются в JSON?
Нет, это увеличит размер бинарного представления и не нужно для JSON; но сериализация игнорирует неэкспортируемые поля, так что _ не повлияет. Однако увеличивается занимаемая память в куче, что может быть нежелательно.

Что такое zero allocation?

Краткий ответ (30–60 секунд)

Zero allocation — техника написания кода, при которой на горячем пути не происходит выделений памяти в куче (heap allocations). Цель — минимизировать работу GC и увеличить пропускную способность. Достигается использование стековых переменных, sync.Pool, pre-allocation слайсов/мап, избегание boxing и замыканий.

Развёрнутый ответ

Понятие часто встречается в высокопроизводительных библиотеках (HTTP роутеры, сериализаторы, логи). Каждая heap-аллокация добавляет работу GC (mark/scan) и может привести к увеличению частоты GC циклов. Zero allocation означает, что на каждую операцию (например, обработку HTTP-запроса) не вызывается mallocgc. Это не абсолютный ноль на всю программу, а именно на критическом пути.

Основные приёмы:

Возвращать значения вместо указателей, где возможно.
Принимать []byte буферы из sync.Pool и возвращать обратно.
Использовать copy для работы со строками/байтами без создания новых слайсов.
Передавать io.Writer вместо конкатенации строк.
Применять strconv.AppendInt для форматирования в предоставленный буфер.
Применять strings.Builder с Grow.
Избегать ...interface{}.

Пример zerolog — zero-allocation логгер: все события сериализуются в переиспользуемый байтовый буфер, не создавая строк и интерфейсов.

Под капотом (internals)

Бенчмарк: testing.B.ReportAllocs() показывает allocs/op. Zero allocation означает 0 allocs/op.
Компилятор может оптимизировать создание небольших слайсов на стеке, если длина и ёмкость константны и невелики (до 64 байт?).
runtime.slicebytetostring обычно выделяет память, если не оптимизировано с помощью unsafe.

Типичные ошибки кандидатов

Пытаться сделать всю программу без аллокаций — это невозможно (например, чтение из сети всегда аллоцирует). Правильно: zero allocation на горячем пути.
Использовать unsafe для превращения []byte в string без копирования, чтобы избежать аллокации — это опасно, если исходный слайс может быть изменён позже (нарушается immutable строка). Только для короткоживущих сценариев и с документированием.
Забыть, что возвращение через channel или defer может добавить аллокаций — нужно профилировать.
Считать, что sync.Pool всегда даёт zero allocation — сам Get может не аллоцировать, но если придётся создавать новый объект при пустом пуле, будет аллокация. Нужно правильно настраивать New.

Возможные дополнительные вопросы интервьюера

Как проверить, что функция действительно не делает heap-аллокаций?
go test -bench . -benchmem покажет allocs/op. Также go build -gcflags="-m" и анализ escape.

Может ли zero allocation навредить читаемости кода?
Да, агрессивное переиспользование буферов, ручное управление слайсами усложняет код. Нужен баланс между производительностью и поддерживаемостью, профилирование должно подтверждать необходимость.

Как уменьшить количество аллокаций?

Краткий ответ (30–60 секунд)

Минимизация heap-аллокаций включает: использование value-семантики вместо указателей для малых структур, предварительное выделение ёмкости слайсов/мап (make с cap), переиспользование объектов через sync.Pool, отказ от временных строк и конкатенации (strings.Builder, []byte), избегание интерфейсного боксинга и замыканий на горячем пути, а также копирование вместо разделяемых ссылок на подслайсы больших массивов.

Развёрнутый ответ

Практические шаги:

Pre-allocate capacity: s := make([]byte, 0, expectedSize), m := make(map[string]int, expectedSize). Это снижает количество перевыделений при append.
Использовать strings.Builder с Grow для построения строк.
Передавать io.Writer напрямую, не создавая промежуточных []byte.
Избегать создания замыканий в циклах; вместо этого использовать локальные переменные и обычные функции.
Применять sync.Pool для дорогих объектов (буферы, большие структуры).
Копировать нужные данные из большого слайса: buf := make([]byte, len(small)); copy(buf, big[start:end]), чтобы не удерживать всю большую память.
Избегать fmt.Sprintf; использовать strconv.AppendInt и аналоги в существующий буфер.
Разбиение горячих структур на поля, размещаемые на стеке, с помощью escape analysis.
Применять функции семейства strings.Trim с возвратом подстроки, но быть осторожным: они могут ссылаться на исходный большой массив? Нет, strings.Trim и подобные возвращают слайс из исходной строки (не копируют), что экономит аллокации, но может удерживать исходную строку. Это trade-off.
Использовать array фиксированной длины на стеке (var arr [1024]byte) вместо слайса.

Под капотом (internals)

make с cap вызывает runtime.makeslice с заданным cap, который выделяет ровно cap*sizeof(T) байт.
sync.Pool очищается во время GC, поэтому объекты переиспользуются между GC-циклами, что сглаживает пики.
Размещение буфера на стеке возможно, если его размер константен и не превышает определённого лимита. Компилятор может проверить -gcflags="-m".

Типичные ошибки кандидатов

Слишком ранняя оптимизация — убирать аллокации, не доказав профилированием, что они являются узким местом.
Неудаление ссылок на большой массив — после срезания слайса может остаться ссылка на исходный массив, не давая GC собрать его. Корректно: делать copy в новый слайс нужного размера.
Забывать о неявных аллокациях в reflect и encoding/json — для unmarshal’а в map[string]interface{} создаётся много объектов. Использовать easyjson или структурную десериализацию.
Неограниченное использование ... для передачи слайса в форматирование — fmt.Println(a...) приводит к boxing и аллокации []interface{}.

Возможные дополнительные вопросы интервьюера

Как эффективно собирать строку из частей, не выделяя память на каждой итерации?
Использовать []byte буфер и append, или strings.Builder с предварительным Grow. После окончания можно получить строку через string(builder.Bytes()) как unsafe zero-copy? Нет, strings.Builder.String() копирует внутренний буфер (с Go 1.18), поэтому это одна аллокация. Чтобы избежать копии, можно взять builder.Bytes() и использовать как []byte, но тогда нельзя изменять буфер.

Как sync.Pool уменьшает аллокации?
Пул сохраняет уже выделенные объекты, которые могут быть повторно использованы. При Get объект извне без аллокации возвращается (если есть в пуле). После использования Put возвращает объект. Таким образом, частота выделения новых объектов падает, сглаживая нагрузку на GC.

Как посмотреть escape analysis с помощью `go build -gcflags="-m"`?

Краткий ответ (30–60 секунд)

Флаг -gcflags="-m" передаётся компилятору Go и включает вывод диагностики escape analysis. Чем больше чисел m, тем детальнее вывод: -m=1 показывает, какие переменные сбежали и почему; -m=2 выводит дополнительную информацию о встраивании (inlining); -m=3 — ещё более подробно. Команда: go build -gcflags="-m" ./... или для конкретного файла.

Развёрнутый ответ

Пример:

package main

func f() *int {
    x := 1
    return &x
}
func main() {
    f()
}

Запустим go build -gcflags="-m" main.go. Вывод:

TEXT

# command-line-arguments
./main.go:5:6: moved to heap: x
./main.go:3:6: can inline f
./main.go:8:6: can inline main
./main.go:4:9: &x escapes to heap

Видим, что x переместился в кучу. Для детального понимания, почему:
-gcflags="-m -m" покажет:

TEXT

./main.go:4:9: &x escapes to heap
./main.go:4:9:         from ~r0 (return) at ./main.go:4:2

Уровни:

-m=1: отображает escape-решения и inline-возможности.
-m=2: показывает, почему некоторые функции не были встроены.
-m=3: предоставляет детальный трейс потока ссылок (полезно для отладки сложных случаев).

Под капотом (internals)

Код escape analysis в cmd/compile/internal/escape. При -m функция note выводит сообщения.
Вывод содержит строки, ссылающиеся на позиции исходного кода.

Типичные ошибки кандидатов

Понимать «escapes to heap» как ошибку — это диагностика, не ошибка компиляции.
Не указывать -gcflags="-m" для тестов или бенчмарков — можно использовать go test -bench . -gcflags="-m", но вывод будет смешан с бенчмарк-результатами. Лучше отдельно.
Забывать, что инлайнинг может изменить результат escape анализа — при включенном инлайнинге (по умолчанию) переменная может остаться на стеке. Отключение инлайнинга (-l) при анализе может дать ложное представление. Лучше смотреть с дефолтными настройками.

Возможные дополнительные вопросы интервьюера

Можно ли заставить компилятор не перемещать переменную в кучу?
Нет, но можно рефакторить код, чтобы ссылки не убегали. Существует аннотация //go:noescape (неофициальная, для internal), которая говорит компилятору считать, что параметр-указатель не убегает; используется в рантайме, но в пользовательском коде не рекомендуется.

Как отфильтровать вывод только для определённых функций?
go build -gcflags="-m" 2>&1 | grep functionName.

Что такое профилирование памяти (memory profiling)?

Краткий ответ (30–60 секунд)

Профилирование памяти — сбор и анализ метрик использования кучи: сколько памяти выделено (allocs) и сколько живо (inuse), с детализацией до строки кода. В Go оно встроено в пакет runtime/pprof, предоставляет данные о аллокациях (объём и количество) и позволяет находить утечки, избыточные аллокации и оптимизировать потребление.

Развёрнутый ответ

Go поддерживает два профиля памяти:

heap — профиль кучи: pprof.Lookup("heap") или http://.../debug/pprof/heap. Имеет два варианта представления: alloc_space (суммарные аллокации) и inuse_space (текущий живой объём). По умолчанию go tool pprof показывает inuse_space.
allocs — псевдоним для heap с alloc_space. Показывает частоту и объём выделений за время профилирования.
Можно собирать профили через HTTP, сигналы, ручной вызов pprof.WriteHeapProfile.

Пример анализа: go tool pprof -alloc_space app heap.prof и команда top показывает функции, где больше всего байт выделено. list functionName покажет строки. web — граф.

Профилирование помогает выявить:

Функции с большим числом аллокаций.
Утечки (растущий inuse).
Источники фрагментации кучи.

Под капотом (internals)

Сэмплирование: по умолчанию каждая аллокация размером >= 128 КБ записывается полностью, меньшие аллокации записываются с вероятностью 1/runtime.MemProfileRate (по умолчанию 512 КБ средний интервал). Это снижает overhead.
Rate можно изменить runtime.MemProfileRate.
Профиль содержит call stack с помощью runtime.Callers и размер аллокации.
Структура профиля: []runtime.MemProfileRecord.

Типичные ошибки кандидатов

Смотреть только inuse, забывая про alloc_space — при поиске горячих аллокационных точек alloc_space важнее, так как показывает агрегированные выделения, даже если память уже освобождена.
Не учитывать сэмплирование при интерпретации — маленькие аллокации могут быть пропущены, искажая картину. Для точного подсчёта всех аллокаций можно задать MemProfileRate=1, но это сильно замедлит.
Путать утечку памяти с высоким потреблением из-за аллокаций — растущий HeapInuse при стабильном HeapAlloc может быть признаком того, что GC недостаточно часто возвращает память ОС, это не утечка. Смотреть HeapIdle, HeapReleased.
Игнорировать флаг --inuse_space vs --alloc_space — в go tool pprof нужно явно указывать, иначе будет показан не тот вид.

Возможные дополнительные вопросы интервьюера

Как собрать профиль кучи работающего приложения без HTTP?
Через сигнал SIGUSR1 или вручную вызвать pprof.WriteHeapProfile(f). Или подключиться через go tool pprof http://localhost:6060/debug/pprof/heap.

Что делать, если профиль показывает большую аллокацию в runtime?
Смотреть, вызывается ли она из пользовательского кода; возможно, это создание слайса или мапы. Использовать list для точного определения строки.

Чем отличается аллокация на стеке от аллокации в куче с точки зрения GC?

Краткий ответ (30–60 секунд)

Стековые переменные не участвуют в работе GC вообще: они не сканируются как корни (GC знает о них через стековые карты, но они не считаются heap-объектами) и не требуют освобождения. Объекты в куче GC отслеживает, сканирует указатели внутри них, помечает живые и освобождает недостижимые. Аллокация в куче увеличивает HeapAlloc, потенциально запускает GC, а стековая — нет.

Развёрнутый ответ

GC в Go управляет только кучей. Стек каждой горутины содержит указатели на кучу, и GC использует эти указатели как корни (roots) для обхода графа живых объектов. Но сами переменные на стеке не являются частью кучи, их не нужно собирать. Когда функция завершается, стековый фрейм автоматически освобождается, GC не вызывается.

Ключевые отличия:

Стек: память освобождается немедленно при возврате, без затрат на mark/scan/sweep.
Куча: объект будет жить, пока достижим; GC должен пройти весь граф, что требует времени CPU, может вызывать паузы (STW). Освобождение происходит асинхронно после mark-фазы.
Write barrier: GC требует барьеров при записи указателей в кучу, чтобы корректно работать конкурентно. При операциях со стеком барьеры не нужны (только при сохранении указателей в кучу).
Давление на GC: чем больше heap-аллокаций, тем чаще циклы GC, особенно при малом GOGC.

Следовательно, минимизация heap allocations напрямую улучшает производительность и снижает задержки GC.

Под капотом (internals)

GC roots включают глобальные переменные, регистры, стеки всех горутин. Сканирование стека происходит в runtime.markroot.
Во время сканирования стек приостанавливается, scanstack обходит все фреймы, используя stack maps, чтобы найти живые указатели.
Но сами стековые слоты не добавляются в рабочую очередь для обхода как heap-объектов; GC просто проверяет их, чтобы найти указатели на кучу.
Завершившаяся горутина освобождает свой стек через stackfree.

Типичные ошибки кандидатов

Считать, что стековые переменные вообще не сканируются GC — их сканируют, но только для поиска указателей на кучу, не для сбора. наличие указателя на стеке на объект кучи удерживает объект живым.
Полагать, что аллокация в куче всегда плоха — без неё невозможны структуры с динамическим временем жизни. Главное — сбалансировать.
Игнорировать, что большие стековые переменные могут заставить GC дольше сканировать стек — да, но это намного дешевле, чем heap-объект.

Возможные дополнительные вопросы интервьюера

Может ли GC собрать объект кучи, указатель на который хранится только на стеке спящей горутины?
Нет, GC считает все стеки горутин при mark (даже спящие), так что объект останется живым.

Как GC обрабатывает указатели в регистрах?
Регистры также сканируются как корни; Go runtime сохраняет или делает дамп регистров, чтобы найти живые указатели.

Как работает `unsafe.Pointer`?

Краткий ответ (30–60 секунд)

unsafe.Pointer — это специальный тип, способный хранить указатель любого типа и конвертироваться между любыми типами указателей, обходя типовую безопасность. Он используется для низкоуровневых операций: прямого доступа к памяти, конвертации между []byte и string, взаимодействия с C. Является ключевым механизмом для cgo, reflect и runtime, но требует крайней осторожности из-за возможных нарушений безопасности памяти и поддержки GC.

Развёрнутый ответ

unsafe.Pointer определён как type Pointer *ArbitraryType. Его можно:

Преобразовать в любой другой тип указателя: (*int)(unsafe.Pointer(p)).
Преобразовать в uintptr для арифметики.
Сравнивать с nil.

Но с ним связаны строгие правила, описанные в пакете unsafe:

Конвертация между unsafe.Pointer и *T допустима.
Конвертация в uintptr и обратно допустима, но нужно использовать в том же выражении или немедленно, иначе GC может переместить объект и адрес станет недействителен. Безопасно только при использовании в syscall.Syscall аргументе или если указатель удерживается в течение всего вызова.
Арифметика на uintptr возможна, но результат обязан указывать внутрь выделенного объекта или на следующий байт за ним, иначе поведение не определено.
Нельзя использовать unsafe.Pointer для произвольного чтения/записи произвольного адреса.

Пример безопасного преобразования слайса байт в строку без копирования (но с риском):

func bytesToString(b []byte) string {
    return *(*string)(unsafe.Pointer(&b))
}

Это небезопасно, если исходный слайс будет изменён (строка станет мутабельной).

Под капотом (internals)

Внутренне unsafe.Pointer — просто нетипизированный указатель, без информации о типе.
GC считает, что unsafe.Pointer может указывать на любой объект, поэтому при сканировании он не разыменовывает его (не следует). Это означает, что объект, на который ссылается только unsafe.Pointer, будет собран как мусор! Чтобы сохранить объект живым, нужно сохранить типизированный указатель или гарантировать, что unsafe.Pointer удерживается как корневой и GC видит типизированную ссылку где-то.
Фактически, GC не распознаёт unsafe.Pointer как сильную ссылку? Нет, распознаёт, если указатель хранится в переменной unsafe.Pointer — GC считает его живым, но не знает, на какой тип, и не сканирует поля. Объект останется живым, но его внутренние указатели не будут автоматически обрабатываться... Это сложно. Практически, если вы храните единственную ссылку на объект как unsafe.Pointer, GC может его собрать в некоторых версиях? По документации, unsafe.Pointer является ссылкой, и объект не будет собран, пока указатель жив.

Типичные ошибки кандидатов

Использование uintptr для хранения адреса на долгое время — объект может быть перемещён GC, адрес изменится, и uintptr станет висячим. Правильно: немедленно преобразовывать в unsafe.Pointer обратно и только для временных вычислений.
Нарушение выравнивания при кастах — если преобразовать *int16 в *int32 через unsafe.Pointer, разыменование может вызвать панику на некоторых архитектурах или привести к невыровненному доступу.
Создание string из []byte через unsafe и последующее изменение слайса — изменяет содержимое строки, которая должна быть неизменяемой, что нарушает инварианты и может вызвать странные баги.
Полагаться на unsafe.Pointer для обхода аллокаций, но не учитывать, что GC по-прежнему может перемещать объекты.

Возможные дополнительные вопросы интервьюера

Почему unsafe.Pointer нельзя использовать для арифметики напрямую?
Потому что указатель типизирован и его размер неизвестен. Для арифметики нужно преобразовать в uintptr, выполнить смещение, и сразу конвертировать обратно.

В каких случаях unsafe.Pointer используется в стандартной библиотеке?
В reflect, sync, runtime: для рефлективных доступов к полям, реализации atomic операций к произвольным ячейкам, десериализации бинарных данных (encoding/binary использует unsafe для быстрых копий).

Когда использование `unsafe.Pointer` может привести к проблемам с GC?

Краткий ответ (30–60 секунд)

Проблемы с GC возникают, когда указатель на объект сохраняется только как uintptr (не unsafe.Pointer), потому что GC не считает uintptr живой ссылкой и может освободить объект. Также если unsafe.Pointer указывает внутрь объекта, а не на его начало, GC не сможет корректно отследить (но не всегда). Ещё опасно длительное хранение uintptr между вызовами — при перемещении объекта адрес становится недействительным.

Развёрнутый ответ

Конкретные сценарии:

Хранение адреса в uintptr:

var addr uintptr = uintptr(unsafe.Pointer(p))
// здесь объект p может быть собран или перемещён, addr станет мусором
*(*int)(unsafe.Pointer(addr)) = 10 // fatal error: bad pointer

Решение: хранить сам unsafe.Pointer, а не uintptr.

Вычисление смещения и последующее использование:
Go
```
p := unsafe.Pointer(&x)
addr := uintptr(p) + offset
// GC может переместить x между этими строками
y := (*int)(unsafe.Pointer(addr)) // небезопасно
```
Правильно: делать всё в одном выражении: y := (*int)(unsafe.Pointer(uintptr(p) + offset)).
Создание string из []byte через unsafe и последующая передача в CGO — если GC перемещает массив, строка повисает.
Использование unsafe.Pointer для доступа к внутренним полям runtime структур, которые GC интерпретирует особым образом — может сломать инварианты.

Также есть правило: если unsafe.Pointer указывает на выделенный объект, GC сохраняет объект живым. Но если вы храните unsafe.Pointer в структуре, которая невидима GC как указатель (например, через uintptr), объект умрёт.

Под капотом (internals)

GC корни определяются через битовые маски; unsafe.Pointer поля считаются указателями, uintptr — нет.
runtime.KeepAlive(p) можно использовать, чтобы гарантировать, что объект p не будет собран до определённой точки.
В ассемблере MOVQ (AX), BX, если AX — unsafe.Pointer, GC будет знать.

Типичные ошибки кандидатов

Возвращать uintptr как указатель — совершенно небезопасно.
Забывать про runtime.KeepAlive — если объект больше не используется в коде после извлечения uintptr, компилятор может посчитать его мёртвым, и GC соберёт.
Использовать unsafe.Pointer для хранения данных в sync.Pool — Pool использует interface{}, что безопасно; но если внутри структуры хранить unsafe.Pointer на объекты кучи, GC может не распознать вложенные указатели, если они скрыты за uintptr.

Возможные дополнительные вопросы интервьюера

Как отлаживать проблемы с GC и unsafe.Pointer?
Использовать GODEBUG=gccheckmark=1, GOGC=off для обнаружения умирающих объектов. Также -race помогает найти гонки, но не GC-корректность.

Что делает runtime.KeepAlive?
Это пустая функция, которая магическим образом указывает компилятору, что переменная всё ещё жива до точки вызова, предотвращая преждевременную сборку.

Что такое `uintptr` и чем он отличается от `unsafe.Pointer`?

Краткий ответ (30–60 секунд)

uintptr — это целочисленный тип достаточно большого размера, чтобы вместить значение указателя. Он не является указателем с точки зрения GC — GC не отслеживает его, считает просто числом. unsafe.Pointer — это обобщённый указатель, который GC воспринимает как живую ссылку. uintptr используется для арифметики, но должен немедленно конвертироваться обратно в указатель.

Развёрнутый ответ

unsafe.Pointer: указатель, может быть nil, поддерживает конвертацию в типизированные указатели, удерживает объект живым (если переменная с ним жива).
uintptr: беззнаковое целое, размером с указатель (8 байт на 64-бит). Не имеет свойств указателя. Его можно хранить сколь угодно долго, но адрес при этом становится ненадёжным из-за перемещения объекта GC.

Различие критично для безопасности. Основное правило: «Не храните адреса в uintptr, всегда преобразуйте обратно сразу». Единственное исключение — передача в аргументы системного вызова (syscall.Syscall) через uintptr — runtime гарантирует, что объект не переместится в течение вызова.

Под капотом (internals)

Тип uintptr встроен, как uint подходящего размера.
В SSA-форме unsafe.Pointer - это OpConvert с особым смыслом, uintptr - обычное целое.
Пакет reflect использует unsafe.Pointer для адресов полей, а uintptr для смещений.

Типичные ошибки кандидатов

Использовать uintptr для обхода массива структур:
Go
```
p := uintptr(unsafe.Pointer(&arr[0]))
for i := 0; i < n; i++ {
    elem := (*T)(unsafe.Pointer(p + uintptr(i)*unsafe.Sizeof(T{}))) // опасно: arr может быть перемещён
}
```
Решение: держать базовый указатель unsafe.Pointer и вычислять смещение на каждой итерации заново.
Прямое присвоение uintptr значению из не-указателя — создание висячего целого.
Забыть про возможное копирование стека — адрес локальной переменной на стеке может измениться при росте стека; использование uintptr для адреса на стеке также небезопасно, если между вычислением и использованием стек может вырасти. Это редко, но возможно.

Возможные дополнительные вопросы интервьюера

Почему unsafe.Pointer можно сравнивать с nil, а uintptr — да, тоже можно, но это бессмысленно?
uintptr(0) значит адрес 0, совпадает с nil-указателем, но GC не различает.

Как безопасно выполнять арифметику указателей?
Только через unsafe.Pointer в одном выражении: unsafe.Add(p unsafe.Pointer, n int) unsafe.Pointer (Go 1.17+), который атомарно вычисляет новый указатель, избегая промежуточного uintptr. Это предпочтительный способ.

Как интерфейсы влияют на размещение переменных в памяти (interface boxing)?

Краткий ответ (30–60 секунд)

Интерфейсное значение (interface value) состоит из двух указателей: на таблицу методов (type) и на данные. Когда конкретное значение присваивается переменной интерфейса, оно «заворачивается» (boxing): если значение больше размером, чем помещается в указатель, или содержит указатели, оно копируется в кучу, а интерфейс хранит указатель на эту копию. Это вызывает heap-аллокацию и может заставить переменную убежать, даже если она была на стеке.

Развёрнутый ответ

Любая переменная интерфейсного типа в Go — это структура iface или eface (пустой интерфейс). Для непустого интерфейса используется iface:

type iface struct {
    tab  *itab
    data unsafe.Pointer
}

При присваивании var i interface{} = x компилятор вставляет вызов runtime.convT2E или аналогичный, который:

Если x — скалярный тип размером <= 8 байт и не содержит указателей (например, int64), он может быть скопирован в стековое выделение? На самом деле convT64 аллоцирует в куче 8-байтовый блок и копирует значение. Даже для маленьких типов выполняется аллокация (однако Go 1.15+ имеет оптимизации: если значение маленькое и не убегает, компилятор может разместить его на стеке и передать указатель? Проверим: фактически convT32/64 вызывают mallocgc, так что heap-аллокация есть. Но компилятор может иногда оптимизировать, если знает, что значение не покинет функцию — тогда boxing не нужен. Однако в общем случае boxing = heap allocation.
Для больших структур или строк — точно аллокация в куче.

Следовательно, использование интерфейсов на горячем пути влечёт аллокации. Именно поэтому fmt-функции аллоцируют много.

Под капотом (internals)

Функции runtime.convT2E, runtime.convT2I, runtime.convTslice и др. определены в src/runtime/iface.go.
Для байтовых и строковых конвертаций в interface{} есть оптимизированные версии convTstring, convTbytes — они аллоцируют копию.
Go 1.15+ встроенный devirtualization иногда может убрать boxing при вызове метода интерфейса, если компилятор знает конкретный тип.

Типичные ошибки кандидатов

Полагать, что передача в interface{} не создаёт копию — создаётся копия в куче, поэтому изменение оригинала после передачи в интерфейс не повлияет на значение внутри интерфейса (для значимых типов).
Хранить большие структуры в интерфейсах, думая, что это эффективно — каждая структура копируется в кучу, вызывая аллокацию.
Игнорировать, что слайсы и мапы уже являются ссылочными типами, и их boxing всё равно копирует заголовок в кучу — всё равно 24 байта копируются.
Забывать, что возврат интерфейсного типа из функции вызывает escape захваченного значения — если вы создаёте локальный int и возвращаете его как interface{}, значение убежит в кучу.

Возможные дополнительные вопросы интервьюера

Как избежать боксинга при вызове методов?
Использовать функции, принимающие конкретные типы через параметры типа (generics), либо явно вызывать методы на структуре, а не через интерфейс.

Почему var a interface{} = "hello" аллоцирует?
Строка — ссылочный тип (16 байт, содержит указатель), копируется в кучу через convTstring, которая выделяет память под string и копирует header, но не содержимое (т.к. содержимое уже в куче). Так что всё равно одна аллокация под 16 байт.

Почему передача больших структур по указателю может быть эффективнее?

Краткий ответ (30–60 секунд)

При передаче по значению вся структура копируется побайтово в стек вызываемой функции (или в регистры). Если структура большая (сотни байт или более), копирование может быть дорогим и увеличивать размер фрейма. Указатель же передаётся как одно машинное слово (8 байт), экономя время копирования и стековое пространство. Однако необходимо учитывать, что указатель может вызвать escape в кучу, нивелируя выигрыш.

Развёрнутый ответ

Порог «большой» зависит от процессора и контекста. Обычно копирование до ~128 байт сравнимо с передачей указателя (с учётом последующего разыменования). Но если структура содержит много полей, особенно если они редко используются в функции, копирование тратит пропускную способность шины и размер стека. Пример:

type Large struct { data [4096]byte }
// передача по значению
func processVal(l Large) { ... } // копирует 4 КБ в стек
func processPtr(l *Large)  { ... } // 8 байт

Однако! Если функция processVal вызывается с локальной переменной var l Large, то l остаётся на стеке, копирование в другой фрейм — просто memmove, и escape нет. В случае указателя &l может заставить l переместиться в кучу (если указатель убегает), что гораздо дороже. Поэтому правило: использовать указатель для больших структур, только если нет риска escape, или если структура уже выделена в куче.

Под капотом (internals)

Ассемблер для вызова с большим значением: SUBQ под фрейм, серия MOVUPS или REP MOVSB. Для указателя — LEAQ и MOVQ в регистр.
Пролог функции с большим значением параметра может выделять больше стекового пространства, что увеличивает шанс роста стека.
При передаче по значению отсутствует write barrier для полей-указателей, если структура на стеке; при передаче указателя — нет, но последующее присваивание в куче (если структура в куче) потребует барьеров.

Типичные ошибки кандидатов

Передавать по указателю структуры любого размера для «производительности» — для маленьких структур это добавляет разыменование и может вызвать escape.
Копировать структуры с mutex — даже если структура небольшая, копирование mutex создаёт копию блокировки, что ведёт к гонкам. Выход — использовать указатель или noCopy.
Не учитывать, что передача по указателю лишает гарантии неизменности — если функция должна только читать, лучше передавать по значению, чтобы исключить сайд-эффекты.

Возможные дополнительные вопросы интервьюера

При каком размере структуры имеет смысл переходить на указатель?
Эмпирически около 128–256 байт, но обязательно профилировать. Также важна алокация: если структура уже в куче — указатель дешев.

Как узнать, копируется ли структура при передаче или компилятор оптимизирует?
Смотреть ассемблер: go build -gcflags="-S".

Почему передача маленьких структур по значению может быть эффективнее?

Краткий ответ (30–60 секунд)

Маленькие структуры (до ~128 байт) копируются очень быстро (несколько машинных инструкций), остаются на стеке и не требуют дополнительного разыменования. Передача по указателю для них добавляет косвенность, может заставить структуру переместиться в кучу (escape) и увеличивает нагрузку на GC. Значение даёт лучшую локальность и потокобезопасность.

Развёрнутый ответ

Стек эффективен для небольших типов: копия помещается в регистры или соседние стековые слоты, отлично предсказуемо. При передаче указателя:

Необходимо взять адрес &x; если x было на стеке, и этот адрес передаётся в неинлайновую функцию, EA часто помещает x в кучу.
Разыменование при доступе — лишняя нагрузка на кэш.
Указатель занимает слово, но и структура могла бы занять 1-2 слова.
Меньше вероятность false sharing.

Правило идиоматического Go: “Передавайте значения, если вам не нужна мутация”. Это улучшает производительность и читаемость.

Пример:

type Point struct{ X, Y int } // 16 байт
func dist(p Point) float64 { ... }

Передача Point по значению — оптимально.

Под капотом (internals)

Компилятор может разместить структуру в регистрах (несколько целочисленных регистров). Спецификация Go допускает передачу аргументов в регистрах с Go 1.17 (register calling convention).
Если структура содержит указатели, копирование может требовать осторожности, но всё равно быстро.

Типичные ошибки кандидатов

Брать указатель на маленькую структуру «на всякий случай» — приводит к escape в кучу и замедлению.
Опасаться, что копирование маленькой структуры вызывает множество аллокаций — копирование на стеке не считается аллокацией с точки зрения GC.
Путать размер структуры и количество полей — много полей, но каждое маленькое — всё равно размер невелик.

Возможные дополнительные вопросы интервьюера

Что изменилось с переходом на register-based calling convention в Go 1.17?
Маленькие структуры теперь могут передаваться через регистры, что ещё больше уменьшает стоимость передачи по значению.

Может ли копирование маленькой структуры нарушить инварианты (например, sync.Mutex)?
Да, поэтому нельзя копировать структуры, содержащие состояния синхронизации.

Что такое «агрессивное встраивание» (inlining) функций и как оно связано с escape analysis?

Краткий ответ (30–60 секунд)

Инлайнинг — встраивание тела функции в место вызова во время компиляции. Go компилятор применяет его для небольших функций. Это устраняет overhead вызова, расширяет контекст для других оптимизаций и, что важно, меняет границы фрейма для escape analysis: то, что было возвращением указателя из встраиваемой функции, может стать локальным, и переменная останется на стеке. Агрессивное встраивание может значительно снизить количество heap-аллокаций.

Развёрнутый ответ

Инлайнинг в Go управляется эвристиками (размер функции, сложность). Есть «mid-stack inlining» (Go 1.12+), который также позволяет встраивать функции, вызывающие другие. Когда функция встраивается, её локальные переменные становятся частью вызывающей функции, и escape analysis пересматривает их. Например:

func newInt() *int { x := 1; return &x } // x escapes

Если newInt() встраивается в main, то в контексте main возврата из функции нет — просто код, который присваивает указатель и возвращает? Возврат *int из main всё равно потребует выживания x за пределами main (возврат в рантайм). Но в другом контексте:

func inc(p *int) { *p++ }
...
x := 1
inc(&x) // если inc встраивается, то &x может не убегать, т.к. указатель не сохраняется.

Без инлайнинга передача &x в неинлайновую inc заставила бы x сбежать, потому что параметр-указатель считается убегающим. С инлайнингом вызов исчезает, и x остаётся на стеке.

Под капотом (internals)

Инлайнинг выполняется в cmd/compile/internal/inline. Анализ стоимости: функция, содержащая более ~80 узлов AST, не встраивается.
При встраивании происходит копирование узлов и перепривязка переменных.
Директива //go:noinline запрещает инлайнинг; //go:inline (экспериментальная) может предлагать.
-gcflags="-l" отключает инлайнинг.

Типичные ошибки кандидатов

Считать, что если функция вызывается с указателем, переменная всегда убегает — инлайнинг может это предотвратить.
Проверять escape analysis с отключенным инлайнингом и делать выводы — результаты могут измениться при включении.
Пытаться улучшить производительность, раздувая функции вручную, вместо того чтобы полагаться на компилятор — современный Go хорошо встраивает, ручное разворачивание ухудшает читаемость.

Возможные дополнительные вопросы интервьюера

Почему большие функции не встраиваются?
Рост размера кода (code bloat) снижает эффективность кэша инструкций. Компилятор балансирует.

Как узнать, была ли функция встроена?
go build -gcflags="-m" показывает: can inline f или inlining call to f.

Как работает garbage collector для переменных в куче?

Краткий ответ (30–60 секунд)

GC в Go — конкурентный tri-color mark-sweep с поддержкой нескольких поколений? Нет, без поколений, но с приоритетом на время паузы. Он работает циклично: при достижении порога (target heap size) запускается mark phase (конкурентная с остановками мира для начальной настройки), затем sweep. Объекты, не достижимые из корней, помечаются как мусор, и позже их память возвращается в пулы аллокатора.

Развёрнутый ответ

Подробный механизм:

Sweep termination — короткая STW для подготовки.
Mark phase — конкурентная: находит все живые объекты, начиная с корней (глобальные переменные, стеки горутин, регистры). Используется tri-color: белый (не посещён), серый (посещён, но не просканирован), чёрный (посещён и просканирован). В конце все белые — мусор.
Mark termination — короткая STW для завершения.
Sweep — асинхронно освобождает белую память, добавляя спаны обратно в аллокатор.

GC работает конкурентно, используя write barrier (смотри Что такое write barrier и зачем он нужен?). Паузы стремятся быть < 0.5 мс. Параметр GOGC управляет частотой: по умолчанию 100 означает, что следующий GC начнётся, когда куча вырастет вдвое относительно живого объёма после предыдущего GC. Также есть GOMEMLIMIT (Go 1.19) для ограничения общего объёма памяти.

Под капотом (internals)

Основной код в src/runtime/mgc.go. Глобальная машина gcController следит за целевым размером.
gcStart запускает цикл. Рабочие горутины (assist workers) помогают mark во время мутаторных аллокаций, чтобы не отставать.
Sweep выполняется при выделении новых объектов (lazy) и отдельными горутинами.
Используются битовые карты (heap bitmap) для отслеживания указателей.

Типичные ошибки кандидатов

Утверждение, что GC останавливает мир на всё время mark — нет, только на короткие setup/termination.
Путать поколения (generational GC) — Go не использует поколения (хотя есть эксперименты), что влияет на поведение: короткоживущие объекты не собираются быстрее.
Не понимать влияния GOGC — низкое значение (например, 10) заставляет GC работать чаще, уменьшая потребляемую память, но увеличивая CPU. Высокое (1000) — наоборот.

Возможные дополнительные вопросы интервьюера

Как избежать длительных STW пауз?
Уменьшить количество живых указателей, избегать больших циклов с аллокациями внутри mark assist, настраивать GOMEMLIMIT.

Что такое assist time и как его уменьшить?
Assist — когда горутина помогает маркировке, чтобы успеть до окончания памяти. Уменьшить можно, снизив темп аллокаций или выделив больше памяти.

Что такое write barrier и зачем он нужен?

Краткий ответ (30–60 секунд)

Write barrier — это небольшой фрагмент кода, вставляемый компилятором при записи указателя в кучу. Он нужен для поддержания корректности конкурентной сборки мусора: гарантирует, что GC не пропустит объекты, созданные или изменённые во время mark-фазы. Без него конкурентный GC был бы невозможен без остановки мира.

Развёрнутый ответ

Во время mark фазы GC обходит граф объектов. Если мутатор изменяет указатель в уже просканированном объекте (чёрном) на белый объект, GC может не заметить это изменение и ошибочно освободить белый объект. Write barrier решает это двумя способами (в Go используется смешанный barrier: Dijkstra и Yuasa):

Dijkstra barrier: при записи указателя *slot = ptr чёрный слот становится серым (объект, содержащий слот, помечается для повторного сканирования).
Yuasa barrier: сохраняет предыдущее значение, чтобы гарантировать, что перезаписанный указатель не потерян (объект, на который указывал слот ранее, остаётся достижимым).

Конкретно Go runtime использует гибридный barrier, который добавляет записываемый объект в рабочую очередь или затеняет его. Write barrier активен только во время mark фазы. Он срабатывает для всех записей указателей в кучу, но не для записей в стек (стек обрабатывается сканированием).

Барьеры снижают производительность записи указателей, поэтому после mark они отключаются.

Под капотом (internals)

Функции runtime.gcWriteBarrier, runtime.wbBufFlush.
Компилятор вставляет проверку runtime.writeBarrier.enabled и вызывает барьерные функции.
В ассемблере: CMPB runtime.writeBarrier(SB), $0; JEQ skip; ...
Барьер включает помещение объекта в буфер (gcWriteBarrier) и последующую флашинг.

Типичные ошибки кандидатов

Считать, что write barrier нужен только для записи в кучу указателей, но забывать про запись в глобальные переменные — также вставляется, потому что глобальные переменные могут быть корнями.
Думать, что барьеры всегда замедляют код — они активны только короткое время во время GC, в остальное время накладные расходы минимальны (условный переход практически не исполняется).
Полагать, что компилятор сам решает, где вставить барьер, и это не влияет на производительность — действительно компилятор вставляет, но оптимизация кода для уменьшения доли записей указателей в горячих циклах может ускорить GC фазы.

Возможные дополнительные вопросы интервьюера

Как отключить write barrier для высокопроизводительного кода?
Никак, он встроен компилятором. Можно минимизировать запись указателей в кучу во время GC, но это сложно контролировать.

Почему барьеры не нужны для стека?
Потому что стек сканируется в фазе mark termination после краткой остановки, и все указатели в стеке проверяются явно, без необходимости барьеров.

Как устроен менеджер памяти Go (TCMalloc)?

Краткий ответ (30–60 секунд)

Менеджер памяти Go основан на многопоточной модели TCMalloc: иерархия кэшей mcache (привязан к P), mcentral (общий для классов размера) и mheap (глобальная куча страниц). Эта архитектура минимизирует блокировки при маленьких аллокациях и эффективно работает с многопоточностью.

Развёрнутый ответ

Дизайн заимствован из TCMalloc (Thread-Caching Malloc). Компоненты:

mcache: локальный кэш для каждого P (логического процессора). Содержит предварительно выделенные span-ы для малых объектов (tiny, small). Без блокировок обслуживает маленькие аллокации (< 32 КБ).
mcentral: центральный кэш для каждого size class. Содержит списки неполных и пустых span’ов. Когда mcache исчерпан, он пополняется из mcentral (требует блокировки, но это реже).
mheap: глобальная куча, управляет памятью на уровне страниц ОС (8 КБ). Выделяет новые span’ы через mmap. Управляет большими объектами (> 32 КБ) напрямую.
span: непрерывный участок памяти из нескольких страниц, разделённый на объекты одного класса размера.

Аллокация: для малых объектов mallocgc находит свободный слот в mcache, обновляет указатель свободного списка. При необходимости запрашивает span у mcentral, потом у mheap. Освобождение: sweep-фаза возвращает свободные ячейки в span, а span может вернуться в mcentral или mheap.

Под капотом (internals)

Структуры определены в runtime/malloc.go, runtime/mcache.go, runtime/mcentral.go, runtime/mheap.go.
Size classes: около 67 классов (таблица class_to_size).
mheap использует mheap_.pages — глобальный реестр всех span’ов, а также heapArena для управления памятью.

Типичные ошибки кандидатов

Путать mcache с горутиной — mcache привязан к P, а не к горутине. Если горутина мигрирует между P, она будет использовать mcache нового P.
Полагать, что аллокация большого объекта (large) обходится без блокировок — large-объекты идут напрямую в mheap, что требует блокировки mheap_.lock, но это амортизировано.
Игнорировать tiny-аллокации — они объединяются в один блок, но всё равно требуют правильного учёта.

Возможные дополнительные вопросы интервьюера

Как происходит выделение span'а?
mheap.allocSpan ищет свободные страницы, возможно, объединяет смежные свободные span'ы, или запрашивает у ОС новый участок.

Что делает mheap_.scavenge?
Освобождает неиспользуемую память обратно ОС через madvise с MADV_DONTNEED.

Что такое `mcache`, `mcentral`, `mheap`?

Краткий ответ (30–60 секунд)

Это три уровня аллокатора Go: mcache — потоколокальный кэш быстрого выделения, привязанный к P; mcentral — кэш для каждого класса размера, обеспечивающий пополнение mcache; mheap — глобальная куча, управляющая страницами ОС и большими объектами. Вместе они образуют масштабируемый менеджер памяти.

Развёрнутый ответ

mcache (per-P):

Содержит alloc массив для каждого size class — указатель на свободный объект в span.
Имеет tiny-аллокатор для объектов < 16 байт (без указателей) — объединяет их в один tiny-объект.
Выделение: просто берёт следующий свободный, двигает указатель.
Нет блокировок, очень быстро.
При исчерпании вызывает mcentral.cacheSpan().

mcentral:

Глобальный на каждый класс размера. Два списка span'ов: nonempty (есть свободные) и empty.
Предоставляет span'ы для mcache под локальной блокировкой (mcentral.lock).
Забирает пустые span'ы у mcache и, если нужно, возвращает в mheap.

mheap:

Центральная структура. Содержит central массив mcentral для малых классов.
Управляет большими объектами напрямую: выделяет span'ы размером, кратным страницам (8 КБ).
Имеет arenas — регионы виртуальной памяти.
Блокировка mheap_.lock глобальная, но используется реже.
Отвечает за возврат памяти ОС (scavenge).

Под капотом (internals)

mcache аллоцируется при создании P.
Размер mcache около 80 КБ.
При GC mcache сбрасывается (освобождает неиспользуемые span'ы).

Типичные ошибки кандидатов

Считать, что mcache принадлежит горутине — это не так, он у P.
Думать, что маленькая аллокация никогда не вызывает блокировок — если mcache пуст, идёт обращение к mcentral (с локом), но это редко.
Не различать large-аллокации (>32 КБ): они минуют mcache, используя mheap напрямую — это важно для производительности.

Возможные дополнительные вопросы интервьюера

Как mcache взаимодействует с GC?
Во время GC все mcache освобождаются (возвращают span'ы в mcentral/mheap) для корректного sweep.

Что такое allocCache в mcache?
Битовая карта свободных ячеек для быстрого поиска.

Как работает аллокация для объектов разных размеров (tiny, small, large)?

Краткий ответ (30–60 секунд)

Go классифицирует объекты: tiny (1–16 байт, без указателей) — размещаются микро-аллокатором внутри одного tiny-блока; small (до 32 КБ) — выделяются из mcache с использованием свободных списков span’а соответствующего size class; large (>32 КБ) — идут напрямую в mheap, получая кратные размеру страницы span’ы.

Развёрнутый ответ

Tiny-аллокации: для объектов ≤ 16 байт без указателей (например, int32, byte). Комбинируются в один tiny-объект размером 16 байт в mcache. При запросе, если есть место в текущем tiny-слоте, объект размещается по смещению. Если нет – выделяется новый 16-байтовый tiny-слот из соответствующего size class’а (class 2). Эффективно для структур вроде маленьких строк.
Small: размер ≤ 32 КБ. Округляется до ближайшего size class’а (например, 64 байта, 80, 96...). Выделение: mcache.alloc[class] даёт указатель на свободный объект из связанного списка в span’е. Если список пуст, mcache запрашивает span у mcentral или далее.
Large: > 32 КБ. Выделяется напрямую через mheap.alloc, который выделяет span с числом страниц = (size + pageSize - 1) / pageSize. Span выделяется из свободных или запрашивается у ОС. Large-объекты не кэшируются в mcache.

Под капотом (internals)

Таблица классов: runtime.class_to_size, runtime.class_to_allocnpages.
Tiny-аллокация управляется полями mcache.tiny, mcache.tinyoffset.
Освобождение после GC: объекты возвращаются в span; sweep обновляет битовую карту.

Типичные ошибки кандидатов

Недооценивать tiny-аллокации — даже множество крошечных аллокаций создают нагрузку на GC, хотя сгруппированы.
Считать, что все small-аллокации без блокировок — при заполнении mcache требуется синхронизация с mcentral.
Не учитывать выравнивание при tiny — tiny-аллокатор обеспечивает выравнивание для размещаемых типов (например, int64 будет выровнен по 8, что может оставить дыры).

Возможные дополнительные вопросы интервьюера

Как посмотреть распределение аллокаций по классам?
Через профилировщик с runtime.MemProfileRecord. AllocObjects.

Влияет ли тип объекта (содержит указатели) на tiny?
Да, объекты с указателями не обслуживаются tiny, потому что GC должен сканировать их индивидуально. Они идут как обычные small.

Что такое стек горутины и как он растет и сжимается?

Краткий ответ (30–60 секунд)

Стек горутины — сегмент памяти, начинающийся с 2 КБ. При переполнении runtime выделяет новый, вдвое больший стек, копирует данные и освобождает старый (ранее использовался сегментированный стек со связными списками). Сжатие происходит во время GC, если используется менее ¼ стека, стек уменьшается вдвое, но не меньше начального размера. Это обеспечивает эффективное использование памяти миллионами горутин.

Развёрнутый ответ

Go 1.3+ использует копирующий стек (contiguous stack with copying). Детали:

В начале g0 (главная горутина) имеет больший стек, обычные горутины стартуют с StackMin = 2048 байт.
В прологе каждой функции вставлена проверка CMP SP, stackguard. Если SP ниже границы (стек растёт вниз, переполнение), вызывается runtime.morestack_noctxt, который запускает расширение.
runtime.newstack выделяет новый сегмент в 2 раза больше (до maxstackceiling, ~1 ГБ), копирует все фреймы, обновляет указатели внутри стека (с помощью карт указателей и adjustinfo), переключает g.stack на новый, старый помечает stackfree.
Сжатие: в начале GC shrinkstack проверяет использование: если занято меньше ¼ StackMin, стек уменьшается до максимального из StackMin и 2*используемого размера. Это освобождает память.

Под капотом (internals)

adjustinfo содержит карту старых адресов, чтобы корректировать указатели в куче? Нет, только указатели внутри стека. Указатели на стек из кучи должны корректироваться через write barrier? Их нет, так что проблем нет.
Функция copystack в runtime/stack.go.
Stack trace: runtime.Callers использует стек для обхода.

Типичные ошибки кандидатов

Утверждать, что стек растёт до бесконечности — есть ограничение ~1 ГБ.
Полагать, что сжатие происходит немедленно при уменьшении использования — нет, только при GC.
Считать, что горутина может делить стек с другой — каждый стек изолирован.

Возможные дополнительные вопросы интервьюера

Может ли горутина увеличить стек до лимита и упасть с OOM?
Да, если рекурсивно вызывать функции и аллоцировать большие фреймы, может упереться в лимит 1 ГБ и упасть.

Что такое «stack poisoning»?
При освобождении стека память может быть заполнена специальным значением (0xfb) для отладки.

Какие проблемы могут возникнуть при использовании `cgo` с точки зрения управления памятью?

Краткий ответ (30–60 секунд)

При использовании cgo возникают проблемы: указатели Go, переданные в C, могут быть перемещены GC, если не зафиксированы, что ведёт к dangling pointers. Также необходимо вручную управлять памятью C (malloc/free), избегать утечек. Объекты C не видны GC Go, а объекты Go могут быть собраны, пока C код использует ссылку. Требуется осторожное использование runtime.Pin (Go 1.21+) или копирование данных.

Развёрнутый ответ

Ключевые опасности:

Перемещение указателей Go: если передать unsafe.Pointer (или *T) в C-функцию, а Go GC переместит объект, C-указатель станет недействительным. Раньше использовали runtime.KeepAlive или удерживали ссылку, но полностью исключить перемещение нельзя. С Go 1.21 появился runtime.Pin для временной фиксации объекта (запрет перемещения и сборки). До этого приходилось копировать данные в C-память.
Сборка мусора: если C-код сохраняет указатель на Go-объект, а в Go ссылки на него нет, GC может собрать. Важно хранить Go-ссылку, пока C владеет.
Утечки C-памяти: выделение через C.malloc требует явного C.free. Если путь исполнения сложен, легко забыть.
Сложности с указателями в структурах: передача структуры с указателями в C требует особого внимания.
Стек vs куча: C-функция может ожидать, что переданный указатель указывает на кучу (стабильный), а на самом деле это адрес на стеке горутины, который может быть скопирован.

Под капотом (internals)

cgo генерирует glue-код, трансформирующий вызовы.
runtime.cgocall переключает контекст на системный стек, чтобы избежать проблем с маленьким стеком горутины.
runtime.Pin добавляет объект в специальный список pinned, предотвращая его перемещение.

Типичные ошибки кандидатов

Передача *byte строки напрямую в C без копирования — если далее строка модифицируется или собирается, крах.
Забывать вызывать C.free — стандартная утечка.
Использовать defer C.free(ptr) с указателем на Go-память — вызов free на Go-указателе ведёт к undefined behavior.
Не учитывать, что cgo вызовы имеют overhead ~40-70 нс на вызов — дорого для горячих путей.

Возможные дополнительные вопросы интервьюера

Как передать большой буфер Go в C без копирования?
Использовать C.CBytes или unsafe.Pointer с runtime.Pin, но если C будет долго использовать, лучше копировать, потому что Pin блокирует перемещение GC, что может ухудшить фрагментацию.

Что такое GoString в C?
Структура {char* p; GoInt n}, указывающая на Go-строку, но p может быть перемещён. Безопасно только при условии, что строка не убегает, или через копирование.

Как бороться с утечками памяти (memory leak) с помощью профилировщика?

Краткий ответ (30–60 секунд)

Для обнаружения утечек используйте pprof heap profile (inuse_space), снимайте несколько снимков через интервалы и сравнивайте (-base). Ищите функции, чей inuse растёт со временем. Анализируйте граф вызовов, идентифицируйте глобальные кэши, забытые ссылки на большие объекты, незакрытые ресурсы. Детектор утечек также может помочь: runtime.SetFinalizer или специальные линтеры.

Развёрнутый ответ

Подход:

Включите HTTP-обработчик pprof или сохраняйте профили по сигналу.
Снимите heap профиль после старта (базовый) и после некоторой работы (например, через 10 минут нагрузки).
Загрузите оба в go tool pprof, используйте -base base.prof для просмотра разницы (pprof -base base.prof current.prof).
Команда top покажет функции с наибольшим приростом inuse_space.
list functionName укажет конкретные строки, где память выделяется и не освобождается.
Ищите: глобальные переменные, накапливающие слайсы/мапы без сброса; горутины, которые блокируются и удерживают ссылки; забытые callback-и, таймеры, time.Ticker без Stop.
Используйте runtime.ReadMemStats для отслеживания HeapInuse в динамике.
Профиль goroutine помогает найти горутины, которые не завершаются и держат память.

Под капотом (internals)

pprof сэмплирует аллокации; inuse основывается на текущем состоянии span-ов.
Можно включить детальный учёт: runtime.MemProfileRate=1 (не рекомендуется для прода).
Сравнение двух профилей показывает дельту inuse — непрямые утечки.

Типичные ошибки кандидатов

Считать, что рост HeapAlloc всегда означает утечку — это может быть нормальное поведение, пока GC не соберёт. Смотреть HeapInuse и тренд на длительном промежутке.
Забывать проверять корневые ссылки — утечка может быть из-за глобальной переменной, хранящей ссылку на большой слайс.
Игнорировать утечку через sync.Map или map внутри долгоживущего объекта — ключи не удаляются, память увеличивается.
Полагать, что закрытие http.Response.Body не важно — забытое закрытие может удерживать соединение и буфер.

Возможные дополнительные вопросы интервьюера

Как автоматически находить утечки в CI?
Использовать бенчмарки с мониторингом NumGoroutine и HeapInuse, или инструменты типа goleak (проверка незавершённых горутин).

Что такое «утечка горутин» и как её профилировать?
Горутины, которые никогда не завершаются. Профиль goroutine покажет стек и количество. Искать по растущему числу.

Что такое "раздувание кучи" (heap fragmentation) и как оно влияет на производительность?

Краткий ответ (30–60 секунд)

Фрагментация кучи — это ситуация, когда свободная память состоит из множества мелких несмежных блоков, что мешает аллокатору выделять большие непрерывные регионы, приводит к увеличению количества используемой памяти и замедлению аллокаций. В Go аллокатор на основе span’ов и size classes минимизирует фрагментацию, но она всё равно возможна при частых аллокациях/освобождениях объектов разного размера.

Развёрнутый ответ

Виды фрагментации:

Внутренняя: из-за округления до size class’а (например, запрос 100 байт, аллокация 128) — небольшое перерасходование.
Внешняя: между span’ами появляются небольшие свободные области, которые нельзя объединить в большой span.

GC в Go со сборкой мусора приводит к освобождению целых span’ов (если все объекты в span’е мёртвые), которые возвращаются в mcentral или mheap, и mheap может объединять смежные свободные span’ы (coalescing). Однако при активных аллокациях могут оставаться частично заполненные span’ы, блокируя объединение. Это вызывает рост RSS (resident set size) больше, чем живые объекты.

Влияние: увеличение пикового потребления памяти, больший адресный пространственный охват, промахи TLB.

Под капотом (internals)

mheap объединяет span’ы в mheap_.coalesce при освобождении.
Span’ы, не возвращённые в mheap, могут создавать дыры.
mheap.reclaim старается восстанавливать память.

Типичные ошибки кандидатов

Полагать, что в Go нет фрагментации из-за GC — собираемость не исключает фрагментацию.
Не использовать sync.Pool для переиспользования объектов — это помогает уменьшить фрагментацию, снижая общее количество выделений.
Игнорировать влияние GOGC — слишком высокое значение откладывает GC, что может увеличить фрагментацию.

Возможные дополнительные вопросы интервьюера

Как измерить фрагментацию?
Сравнить HeapInuse и HeapAlloc (inuse минус alloc даёт некоторое представление о накладных расходах). Ещё MemStats.HeapFragmentation? Такого поля нет; можно смотреть HeapIdle - HeapReleased.

Как уменьшить фрагментацию?
Предварительное выделение ёмкости, использование объектных пулов, минимизация кол-ва мелких временных объектов, настройка GOGC и GOMEMLIMIT.

Как размер страницы памяти ОС влияет на аллокатор Go?

Краткий ответ (30–60 секунд)

Аллокатор Go управляет памятью страницами (обычно 8 КБ, кратно размеру страницы ОС). Размер страницы ОС (4 КБ на x86, 4/16/64 КБ на ARM) влияет на granularity выделения span’ов у ОС и на эффективность возврата памяти. Большие страницы уменьшают TLB промахи, но могут увеличить внутреннюю фрагментацию. Go подбирает physPageSize при запуске и использует её для выравнивания.

Развёрнутый ответ

ОС выделяет память через mmap с кратностью странице (обычно 4 КБ).
Go определяет physPageSize через syscall.Getpagesize() или из auxv.
Единица управления в mheap — pageSize = 8 КБ по умолчанию на большинстве платформ, но может быть и 64 КБ на некоторых (ppc64).
При выделении span’ов размер округляется до страниц. Если размер страницы ОС меньше pageSize, аллокатор может использовать несколько OS-страниц.
Возврат памяти ОС (scavenge) работает с OS страницами: madvise(MADV_DONTNEED) на целых страницах.
Большие страницы (huge pages, 2 МБ) могут быть прозрачно использованы ОС для улучшения производительности, но Go специально не запрашивает huge pages (можно включить через GODEBUG=scavenge=1 и настройками ОС).

Под капотом (internals)

runtime.mheap инициализирует mheap_.pages с размером pageSize, который обычно 8 КБ, но может быть 64 КБ на ppc64.
sysAlloc вызывает mmap с требованием выравнивания по physPageSize.
mheap.grow увеличивает кучу.

Типичные ошибки кандидатов

Утверждать, что Go всегда использует 8 КБ страницы — на некоторых архитектурах иное.
Игнорировать разницу между страницей аллокатора (8 КБ) и страницей ОС (4 КБ) при анализе RSS — из-за выравнивания RSS может быть больше ожидаемого.
Предполагать, что увеличение страницы аллокатора уменьшает фрагментацию — это может увеличить внутреннюю фрагментацию для малых объектов.

Возможные дополнительные вопросы интервьюера

Как настроить huge pages для Go?
Можно попробовать окружение GODEBUG=madvdontneed=0 и включить прозрачные huge pages в ОС, но прямых API нет.

Влияет ли размер страницы ОС на число аллокаций?
Непосредственно нет, но влияет на эффективность scavenging.

Что такое "arena allocation" (Go 1.20+) и какие проблемы она решает?

Краткий ответ (30–60 секунд)

Arena allocation (экспериментальная фича) позволяет выделить участок памяти (арену) и размещать в ней множество объектов, а затем освободить всю арену одним действием, минуя GC для этих объектов. Решает проблему дороговизны сборки мусора для большого количества временных объектов с коротким временем жизни, снижая GC overhead и фрагментацию.

Развёрнутый ответ

Доступно через GOEXPERIMENT=arenas (Go 1.20). API: arena.NewArena, arena.Make, arena.Free.

Арена — большой блок памяти, полученный от ОС. Внутри неё объекты выделяются последовательно (bump allocator), не подлежат GC, и GC игнорирует указатели внутри арены, если они не ссылаются на объекты вне арены.
При завершении жизненного цикла группы объектов арена освобождается целиком, вся память возвращается ОС. Это исключает необходимость mark/scan для этих объектов.
Подходит для серверов, обрабатывающих запросы, где много temporary объектов, связанных с одним запросом, которые можно выделить в арене и выбросить после ответа.

Проблемы, которые решает: снижение GC pause, CPU на mark, уменьшение нагрузки на аллокатор, контроль за временем жизни.

Под капотом (internals)

Реализация в runtime/marena.go. Арены управляются mheap.
Аллокация в арене не требует синхронизации (per-thread или per-arena).
Указатели на объекты арены должны храниться только внутри арены или не сохраняться после её освобождения, иначе dangling pointers. Это накладывает ограничения: нельзя передавать указатели из арены в глобальные переменные или return.
GC не сканирует арену, но во время mark арена должна быть проверена? Нет, GC просто игнорирует её, считая всю память арены достижимой? На самом деле, если арена не освобождена, она жива; указатели внутри не сканируются, но объекты внутри арены могут ссылаться на внешнюю кучу; такие указатели считаются корнями? Это сложная тема.

Типичные ошибки кандидатов

Полагать, что арена позволяет полностью отказаться от GC — нет, только для ограниченных участков.
Возвращать указатель на объект арены за её пределы — неопределённое поведение/крах.
Забывать, что объекты из арены нельзя использовать в интерфейсах (детали могут варьироваться).

Возможные дополнительные вопросы интервьюера

Когда arena allocation будет стабильным?
Эксперимент, возможно, появится в 1.22+ или позже. Пока за флагом.

Чем arena отличается от sync.Pool?
Pool переиспользует объекты между запросами, требует GC для очистки пула; arena же выделяет и сразу освобождает всю группу, без участия GC.

Как вручную освободить память в Go (кроме сборщика мусора)?

Краткий ответ (30–60 секунд)

В Go нет прямого free, но можно: (1) освобождать память C через C.free; (2) использовать runtime.SetFinalizer для отложенной очистки внешних ресурсов; (3) применять sync.Pool для возврата объектов под управление GC; (4) arena allocation (экспериментально) — arena.Free. Саму Go-память вручную удалить нельзя, но можно обнулить ссылки (присвоить nil), чтобы GC собрал.

Развёрнутый ответ

Go управляет памятью автоматически. Однако есть косвенные способы:

Обнуление указателей: если глобальная переменная хранит большой слайс, присвоение nil позволяет GC его собрать.
Удаление элементов из map с последующим runtime.GC() для гарантии — но обычно достаточно потерять ссылки.
sync.Pool: временно отдаётся объект, который остаётся в пуле и может быть переиспользован, но не освобождается до GC.
runtime.SetFinalizer: регистрирует функцию, которая вызовется перед сборкой объекта; можно освободить C-память.
cgo: явное выделение и освобождение через C.malloc/C.free.
Arena allocation (Go 1.20+): arena.Free(a *Arena) освобождает все объекты арены разом.
runtime.GC(): принудительный запуск GC для немедленной сборки мусора (но не ручное освобождение отдельных объектов).

Под капотом (internals)

runtime.GC() выполняет синхронный GC, блокируя все горутины на время sweep termination и mark termination.
SetFinalizer добавляет запись в specialfinalizer, GC перед сборкой вызывает финализатор.

Типичные ошибки кандидатов

Пытаться «освободить» Go-объект через обнуление указателя, но забыть, что на объект остались другие ссылки — объект не соберётся.
Использовать runtime.SetFinalizer как деструктор для обязательного освобождения ресурсов — финализатор может никогда не вызваться (если объект остаётся живым) или вызваться с задержкой. Лучше явные Close() методы.
Вызывать runtime.GC() в коде для «оптимизации» — обычно вредно, вызывает лишние STW паузы.

Возможные дополнительные вопросы интервьюера

Как гарантированно освободить C-память, связанную с Go-объектом?
Использовать runtime.SetFinalizer и KeepAlive, но надёжнее предоставить метод Destroy, который вызывается вручную.

Можно ли переиспользовать память без GC?
sync.Pool не освобождает, но переиспользует. Arena allocation освобождает сразу.

Как работает `runtime.SetFinalizer` и какие риски с ним связаны?

Краткий ответ (30–60 секунд)

runtime.SetFinalizer(obj, finalizer) назначает функцию, которая будет вызвана GC перед тем, как объект obj будет освобождён (когда он становится недостижимым). Используется для очистки внешних ресурсов (файлы, C-память). Риски: финализатор может никогда не выполниться (если объект остаётся достижимым), вызывается в отдельной горутине с непредсказуемой задержкой, может помешать повторному использованию памяти и замедлить сборку.

Развёрнутый ответ

Финализатор — аналог деструктора, но крайне ненадёжный. Свойства:

Вызывается только один раз.
Порядок вызова не гарантирован.
Объект может быть «оживлён» внутри финализатора (если сохранить ссылку), тогда финализатор не будет повторно вызван.
Не следует использовать для критичных ресурсов (например, разблокировка мьютекса) — потому что нет гарантии времени вызова и может не вызваться вообще, если GC не запустится или объект не будет собран.
Замедляет GC, т.к. финализатор требует дополнительной работы.

Пример:

type FileWrapper struct { f *os.File }
func NewFile(name string) *FileWrapper {
    f, _ := os.Open(name)
    w := &FileWrapper{f}
    runtime.SetFinalizer(w, func(w *FileWrapper) { w.f.Close() })
    return w
}

Лучше реализовать Close() и вызывать вручную.

Под капотом (internals)

runtime.SetFinalizer добавляет объект в mheap.specialfinalizeralloc.
Во время GC, при обнаружении мёртвого объекта с финализатором, объект помещается в очередь finq, и специальная горутина bgsweep или runFinalizer вызывает финализатор позже.

Типичные ошибки кандидатов

Использовать финализатор для синхронизации — финализатор может никогда не сработать, что приведёт к deadlock’у из-за неснятого мьютекса.
Полагать, что финализатор вызывается сразу после потери ссылки — он может быть отложен на неопределённое время.
Создавать циклы ссылок с финализаторами — объекты могут никогда не быть собраны? Нет, GC распознаёт циклы, но финализатор может помешать.

Возможные дополнительные вопросы интервьюера

Можно ли гарантировать вызов финализатора при завершении программы?
Нет, при выходе из main финализаторы не выполняются. Использовать defer или atexit-подобные механизмы.

Как отменить финализатор?
Вызвать SetFinalizer(obj, nil).

Что такое `sync.Pool` и как он помогает переиспользовать память?

Краткий ответ (30–60 секунд)

sync.Pool — пул временных объектов, предназначенный для повторного использования выделенной памяти без выделения новой. При Get возвращает объект из пула (если есть), иначе создаёт новый через New. При Put объект помещается обратно. Между циклами GC пул очищается, чтобы избежать удержания большого объёма неиспользуемой памяти. Это снижает давление на GC и скорость аллокаций.

Развёрнутый ответ

Использование:

var bufPool = sync.Pool{
    New: func() interface{} { return make([]byte, 1024) },
}

buf := bufPool.Get().([]byte)
// use buf
bufPool.Put(buf)

Важно: объекты в пуле могут быть удалены GC в любое время (обычно в начале GC, но не гарантируется). Поэтому не следует полагаться на сохранность объектов.

Пул привязан к каждому P (аналогично mcache) для конкурентности без блокировок.
Подходит для буферов, временных структур запросов.
Не подходит для объектов, содержащих состояние, которое должно быть очищено между использованиями (нужно сбрасывать вручную).

Под капотом (internals)

Структура sync.Pool содержит локальный кэш на P poolLocal, цепочку shared.
Get сначала проверяет локальный кэш текущего P, потом shared, потом New. Put кладёт в локальный кэш.
Во время сборки мусора вызывается poolCleanup, который удаляет все объекты из всех пулов (сбрасывает в nil). Это предотвращает удержание ссылок и позволяет GC собрать их.

Типичные ошибки кандидатов

Забывать сбрасывать объект перед возвратом в пул — например, в буфере остаются старые данные, которые могут «утечь».
Хранить в пуле объекты, которые сами содержат ссылки на другие большие объекты — после очистки пула GC не сможет собрать большие объекты, пока пул не опустеет.
Использовать sync.Pool как кэш-предзагрузку — он не для этого, он только для временного повторного использования.
Положить nil в пул — Get вернёт nil, и проверки не будет, если поле New не задано.

Возможные дополнительные вопросы интервьюера

Почему sync.Pool очищается при каждом GC?
Чтобы не накапливать неиспользуемые объекты и не создавать утечек памяти при спаде нагрузки.

Как реализовать pool без очистки GC?
Существуют сторонние библиотеки типа bytebufferpool, которые используют собственные механизмы.

Как проверить, что слайс или мапа не ссылаются на старый большой массив после обрезания?

Краткий ответ (30–60 секунд)

Проверить можно с помощью профилирования кучи (inuse_space) и анализа того, удерживается ли большой массив после обрезания. Основной симптом: после того как слайс должен освободить большой базовый массив, память не уменьшается. Решение: явно скопировать нужные данные в новый слайс через copy или append([]T(nil), s...). Для мап — удаление ключей или пересоздание мапы.

Развёрнутый ответ

Слайс — это view над массивом. Если взять подслайс small := big[1:2], то small продолжает ссылаться на огромный массив big, и GC не может его освободить, пока small жив. Аналогично, при усечении слайса s = s[:newLen] старый массив не обрезается. Так происходит утечка памяти.

Способы обнаружения:

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

Решение:

small := make([]T, length)
copy(small, big[start:end])
// или
small := append([]T(nil), big[start:end]...)

Для мап: если мапа сильно уменьшилась, старая хеш-таблица не уменьшается автоматически. Чтобы освободить память, нужно создать новую мапу и скопировать элементы, либо просто удалить все ключи (но память всё равно не возвращается ОС). В Go 1.21+ есть maps.Clone с перераспределением.

Под капотом (internals)

Заголовок слайса (reflect.SliceHeader) содержит указатель на начало массива. При срезе копируется заголовок с тем же указателем.
Map: структура hmap с buckets — при удалении элементов количество buckets не сокращается.

Типичные ошибки кандидатов

Предполагать, что newSlice := oldSlice[:0] освободит память — не освободит, базовый массив тот же.
Забывать, что strings.Trim и тому подобное возвращают подстроку, ссылающуюся на исходную строку — если исходная строка большая, а подстрока маленькая, память удерживается. Можно использовать string([]byte(small)) для создания новой строки с копированием (аллокация).
Игнорировать утечку в map после удалений — map не сжимается.

Возможные дополнительные вопросы интервьюера

Как очистить map и освободить память без создания новой?
Никак, нужно либо создать новую, либо использовать пакет maps.Clone (Go 1.21), который выделяет новую map подходящего размера.

Можно ли принудительно обрезать массив слайса?
Нет, нужно копирование.

Что такое "live heap" и как его анализировать?

Краткий ответ (30–60 секунд)

Live heap — объём памяти, занятый живыми (достижимыми) объектами в куче в данный момент. Это значение HeapInuse (или HeapAlloc минус мусор, ожидающий сборки). Анализируется профилями inuse_space в pprof. Показывает реальное потребление памяти работающим приложением.

Развёрнутый ответ

runtime.MemStats содержит:

HeapAlloc — байты, занятые живыми объектами (аналог Inuse).
HeapInuse — общее количество памяти в span’ах, которые содержат живые объекты (включает неиспользуемые слоты).
HeapIdle — память в span’ах, не используемых ни под какие объекты.
HeapReleased — память, возвращённая ОС.

Live heap лучше всего ассоциировать с HeapAlloc (живой). Профиль inuse_space показывает распределение HeapAlloc по функциям.
Анализ:

Если HeapAlloc неуклонно растёт при стабильной нагрузке — возможна утечка.
Сравнивая несколько heap-профилей (-base), можно увидеть, какие объекты удерживаются.
go tool pprof -inuse_space top.

Под капотом (internals)

HeapAlloc поддерживается атомарно с учётом аллокаций и освобождений.
Профиль inuse строится на основе mheap_.allspans — обходим все span’ы, суммируем занятые объекты.

Типичные ошибки кандидатов

Путать HeapInuse и HeapAlloc — HeapInuse больше из-за округления до size class.
Игнорировать HeapReleased — память может быть освобождена ОС, но не отражена в HeapInuse.
Смотреть только на текущий live heap, не учитывая историю — нужно отслеживать тренд.

Возможные дополнительные вопросы интервьюера

Как интерпретировать резкое падение HeapAlloc после GC?
GC освободил мёртвые объекты, HeapAlloc уменьшился.

Что такое «memory overhead» в куче?
Разница между HeapInuse и HeapAlloc + HeapIdle.

Как работает сборщик мусора в условиях нехватки памяти?

Краткий ответ (30–60 секунд)

Когда куча приближается к лимиту (GOMEMLIMIT или системный OOM), GC запускается чаще и может использовать assist-механизмы, заставляя мутаторные горутины помогать маркировке. Если памяти всё равно не хватает, runtime вызывает runtime.GC() повторно, пытаясь освободить мусор. При полном исчерпании и невозможности выделить новую страницу у ОС — паника OOM, программа завершается.

Развёрнутый ответ

GOGC определяет, когда начинать GC относительно размера live heap.
GOMEMLIMIT (Go 1.19) задаёт мягкий лимит общей кучи (live + scavenged). При превышении GC работает агрессивнее, возможно, с уменьшением GOGC динамически.
Если при аллокации mallocgc не может выделить память после GC (из-за фрагментации или живых объектов), он пытается scavenge и запускает еще цикл GC. Если всё равно нет — программа падает с fatal error: out of memory.
В условиях нехватки также увеличивается использование mark assist, что замедляет приложение, давая больше ресурсов GC.

Под капотом (internals)

gcController следит за целевым размером и скоростью аллокаций. gcAssistAlloc заставляет горутину выполнять работу по маркировке.
mheap.alloc при невозможности выделить span вызывает grow (mmap), если и это неуспешно — паника.

Типичные ошибки кандидатов

Утверждение, что Go не может упасть из-за нехватки памяти — может.
Полагать, что достаточно установить GOMEMLIMIT и приложение не упадёт — лимит мягкий, приложение может замедлиться до неприемлемого уровня, но падение всё равно возможно при быстром выделении.
Игнорировать настройку лимитов ОС (ulimit) — даже если OOM-killer не сработает, процесс может аварийно завершиться.

Возможные дополнительные вопросы интервьюера

Что такое assist time и как он растёт при нехватке памяти?
Assist time — время, потраченное горутиной на помощь GC. При нехватке памяти это время может резко возрасти, замедляя обработку запросов.

Как предотвратить OOM в Go?
Мониторить HeapSys и HeapInuse, установить GOMEMLIMIT, ограничивать параллелизм, использовать sync.Pool, контролировать размеры кэшей.

Как `escape analysis` работает с дженериками?

Краткий ответ (30–60 секунд)

Escape analysis работает после мономорфизации дженериков (компилятор создаёт конкретную версию для каждого типа или использует shape-реализацию). Анализ применяется к уже специализированному коду, поэтому поведение может зависеть от типа параметра: если тип — указатель или содержит указатели, то переменные могут убегать. В случае shape-реализации с косвенными параметрами могут возникать дополнительные escape из-за передачи через указатель на тип.

Развёрнутый ответ

В Go 1.18+ дженерики компилируются двумя способами:

Мономорфизация (специализация) для каждого уникального типа (int, string).
Shape-based (используется, когда типы идентичны по form/shape) — для указателей, слайсов, мап и т.д., чтобы избежать комбинаторного взрыва. Shape-функции принимают параметры через указатели (runtime передаёт *int вместо int), что может вызывать escape переменных там, где специализированная версия его не имела бы.

Пример: generic функция, возвращающая значение:

func Identity[T any](v T) T { return v }

При Identity[int] — int копируется, стек. При Identity[*int] — копируется указатель, тоже стек. Но если T является интерфейсом, работающим через указатель на shape? Сложно. В некоторых случаях из-за необходимости боксинга в shape-функциях случается escape.

EA анализирует каждую конкретную инстанциацию отдельно, так что поведение может отличаться для разных типов.

Под капотом (internals)

В cmd/compile/internal/typecheck/generic.go происходит создание конкретных функций.
Shape-реализация: cmd/compile/internal/typecheck/subr.go создаёт shape-функции с параметрами *shape.Type.
Для этих shape-функций EA может быть более консервативен.

Типичные ошибки кандидатов

Предположить, что дженерики не влияют на escape — влияют, особенно через shape.
Использовать дженерики для «нулевых аллокаций» без проверки — нужно смотреть -gcflags="-m" для каждой инстанциации.
Не учитывать, что ограничения типа (interface{ ... }) могут требовать передачи через интерфейс и вызывать boxing — в generic коде это тоже может быть.

Возможные дополнительные вопросы интервьюера

Как профилировать аллокации в дженериках?
Аналогично обычному коду, go test -benchmem. Профили покажут инстанциации с суффиксами типа.

Может ли инлайнинг дженерик-функций убрать escape?
Да, если функция встраивается, shape-проблемы могут исчезнуть.

Что такое «аллокация на стеке с динамическим размером» и возможна ли она?

Краткий ответ (30–60 секунд)

Стековая аллокация с динамическим размером означает выделение памяти на стеке, размер которой определяется во время выполнения (например, alloca в C). В Go это невозможно напрямую, так как размер стекового фрейма должен быть известен компилятору. Слайсы с переменной длиной уходят в кучу, если длина не константна. Однако make для слайса с константным малым размером может оставить массив на стеке, если он не убегает. В общем случае динамические массивы на стеке не поддерживаются.

Развёрнутый ответ

Компилятор выделяет стековый фрейм фиксированного размера (смещение SP). Вся память локальных переменных известна на этапе компиляции. Исключения:

make([]T, constant_size) с небольшим размером и без escape может быть размещён на стеке (это не динамический размер, а константный).
Нельзя сделать n := someFunc(); arr := [n]int — это запрещено синтаксисом (размер массива должен быть константой).
var x [1 << 20]byte может быть размещён на стеке, если не убегает, но размер фиксирован 1 МБ, что может вызвать рост стека.
Go не имеет аналога alloca. Любая память, размер которой неизвестен компилятору, выделяется в куче.

Следовательно, «аллокация на стеке с динамическим размером» в Go отсутствует.

Под капотом (internals)

SSA-операции для локальных переменных используют OFFSET от SP, известный в compile-time.
Даже var s []int; s = make([]int, n) — массив в куче.
Рантайм morestack проверяет, хватает ли фиксированного размера фрейма, определённого компилятором.

Типичные ошибки кандидатов

Ошибочно считать, что append на стеке динамически расширяет массив — append создаёт новый массив в куче, если ёмкости не хватает, или использует имеющийся стековый массив, только если массив был на стеке.
Думать, что Go поддерживает VLA (variable-length arrays) — нет.
Пытаться оптимизировать цикл, создавая слайс переменной длины внутри функции, думая, что он останется на стеке — если размер переменный, он уйдёт в кучу.

Возможные дополнительные вопросы интервьюера

Как эмулировать динамический стековый массив?
Использовать фиксированный буфер на стеке достаточного размера и слайс на него: var buf [128]byte; s := buf[:n], но n не может превышать 128.

Что произойдёт, если объявить очень большой массив на стеке?
Компилятор может решить отправить его в кучу, чтобы избежать огромного стека.

Как профилирование кучи помогает найти источники аллокаций?

Краткий ответ (30–60 секунд)

Профилирование кучи (alloc_space) показывает, из каких функций и строк кода было выделено больше всего памяти (в байтах или количестве) за время профилирования. Анализируя top и list, мы видим конкретные вызовы make, new, append, конвертации, которые генерируют аллокации. Это позволяет точно определить горячие точки и оптимизировать их.

Развёрнутый ответ

Методика:

Запустить приложение с pprof (HTTP или сохранение профиля).
Собрать профиль кучи с фокусом на аллокации: curl http://.../debug/pprof/heap?debug=1, либо через runtime.WriteHeapProfile.
Для go tool pprof использовать флаг -alloc_space или открывать профиль allocs.
Команда top покажет функции с наибольшим количеством аллоцированных байт.
list FuncName покажет построчный вклад.
Граф web отобразит caller/callee.

Инструмент go test -bench . -benchmem тоже показывает аллокации на операцию.

Под капотом (internals)

Сэмплирование записывает стек вызовов и размер при каждом выделении с определённой вероятностью.
Структура профиля хранит []runtime.MemProfileRecord, содержащая AllocBytes, AllocObjects и стек.

Типичные ошибки кандидатов

Анализировать только inuse, когда интересует общее количество аллокаций — для поиска источников нужен alloc_space.
Не учитывать, что alloc_space накапливается за всё время профилирования — можно сделать delta-профиль.
Игнорировать влияние MemProfileRate на точность — малые аллокации могут быть пропущены, но общая картина верна.

Возможные дополнительные вопросы интервьюера

Как увидеть аллокации в реальном времени?
Использовать debug.SetMemoryLimit? Нет, через trace можно увидеть события аллокаций.

Что делать, если профиль показывает аллокации в runtime?
Обычно это вызвано вашим кодом (создание слайсов, мап). Используйте list для уточнения.

Как использование `string` vs `[]byte` влияет на аллокации?

Краткий ответ (30–60 секунд)

Строки в Go неизменяемы, поэтому конкатенация или построение создают новые строки, часто с аллокациями. []byte позволяет изменять содержимое и использовать переиспользуемые буферы, что снижает количество выделений. Конвертация из string в []byte и обратно копирует данные (аллокация), если не используется unsafe. Выбор зависит от сценария: для неизменяемых ключей или передачи в интерфейс строки удобны, для обработки потоков байт лучше []byte.

Развёрнутый ответ

Создание строки из литерала или из другого слайса: s := "hello" — заголовок указывает на read-only память, аллокации нет.
s := string(b) — аллокация и копирование, если b — []byte.
b := []byte(s) — тоже копирование.
Конкатенация строк s1 + s2 создаёт новую строку (аллокация). Многократная конкатенация в цикле — множество аллокаций.
Построение строки с помощью strings.Builder или bytes.Buffer с предварительным Grow — одна аллокация на весь результат (при String()).
При работе с io.Reader/Writer обычно используют []byte для избежания лишних копий.
string как ключ мапы: если строка уже существует, копирования нет; если создаётся из byte, будет копирование.

Оптимизация: использовать []byte буферы из sync.Pool, проводить все манипуляции как []byte, в конце конвертировать в string для ответа.

Под капотом (internals)

runtime.slicebytetostring выделяет память под строку.
stringtoslicebyte также аллоцирует.
Неизменяемые строки могут использовать базовый массив без копии при создании подслайса (но GC будет держать весь массив).

Типичные ошибки кандидатов

Постоянно конвертировать туда-сюда без необходимости — лишние аллокации.
Использовать string для накопления данных в буфере в высоконагруженном коде — лучше []byte.
Считать, что []byte(s) безопасно и быстро, если s большая, а нужен маленький кусочек — всё равно копируется весь кусок? Нет, []byte(s) копирует всю строку, а не подслайс. Если делать []byte(s[100:200]), то скопируется только 100 байт? Да, но при индексации строки сначала создаётся подстрока без копирования, а потом []byte копирует только её. Это лучше, чем копия всей строки.

Возможные дополнительные вопросы интервьюера

Как реализовать zero-allocation конвертацию string в []byte?
Через unsafe.Pointer, но это опасно, так как полученный слайс может изменять строку, что недопустимо.

Почему strings.Builder.String() аллоцирует?
Потому что возвращаемая строка должна быть неизменяемой, а внутренний буфер может быть изменён позже. Поэтому копируется.

Что такое "heap dump" и как его проанализировать?

Краткий ответ (30–60 секунд)

Heap dump — снимок всех объектов в куче с их типами и графом ссылок. В Go можно получить через debug.WriteHeapDump или pprof (в формате pprof, не полный граф). Для полного дампа используется GOHEAPDUMP (Go 1.21+ экспериментально), создающий бинарный файл, который можно проанализировать с помощью утилиты go tool pack или сторонних инструментов (например, heapdump). Позволяет детально выявить, какие объекты удерживают память и почему они не собираются.

Развёрнутый ответ

Классический heap dump включает все объекты, их размеры, типы и связи. В Go стандартный pprof heap profile предоставляет сводку, а не полный граф. Но с флагом GOHEAPDUMP=1 (Go 1.21, с -tags=goexperiment.heapdump) можно записать дамп в файл, который затем загружается в среду анализа (например, go tool dump или графический анализатор). Анализ:

Поиск больших объектов.
Поиск путей до корней (почему объект жив).
Обнаружение утечек по типам.

В продакшене чаще используют pprof с -inuse_space и -base, что достаточно для большинства задач.

Под капотом (internals)

runtime.WriteHeapDump записывает бинарный формат со структурами span’ов, объектов, типов.
go tool pprof не читает такой дамп; нужна утилита heapdump (x/arch).
Экспериментальный GOHEAPDUMP интегрирован в runtime/debug.

Типичные ошибки кандидатов

Пытаться проанализировать heap dump стандартными средствами pprof — pprof не загрузит такой файл.
Считать, что heap dump показывает только живые объекты — да, но также может содержать информацию о span’ах.
Снимать heap dump на продакшене без остановки мира — может вызвать паузу и большой файл.

Возможные дополнительные вопросы интервьюера

Как получить граф всех объектов?
Через debug.WriteHeapDump и затем визуализировать в golang.org/x/debug/internal/graph.

Какие инструменты для анализа heap dump?
Внутренние пакеты Go, golang.org/x/debug, delve (частично).

Что такое weak.Pointer в Go 1.24?

Краткий ответ (30–60 секунд)

Пакет weak в Go 1.24 вводит тип weak.Pointer[T] — слабую ссылку на объект, выделенный в куче. В отличие от обычного («сильного») указателя *T, наличие слабой ссылки не продлевает время жизни объекта: сборщик мусора (GC) имеет право освободить память при следующем цикле сборки, если на объект нет других сильных ссылок. Метод wp.Value() возвращает *T (если объект жив) или nil (если объект уже собран).

Развёрнутый ответ

Пример создания и проверки:

import (
    "fmt"
    "weak"
)

type UserSession struct {
    UserID string
    Token  string
}

func main() {
    session := &UserSession{UserID: "42", Token: "secret"}
    wp := weak.Make(session)

    // Пока жива сильная ссылка:
    if s := wp.Value(); s != nil {
        fmt.Println("Сессия активна:", s.UserID)
    }

    // Удаляем сильную ссылку:
    session = nil

    // После отработки GC (например, runtime.GC()):
    // wp.Value() начнёт возвращать nil
}

Основные сценарии применения:

Кэши в оперативной памяти без утечек (Memory-sensitive caches): Объекты кэшируются, но при нехватке памяти GC может свободно их удалить.
Дедупликация и каноникализация (пакет unique): Построен целиком на базе слабых указателей.
Циклические графовые структуры: Предотвращение сохранения циклических цепочек ссылок.

Под капотом (internals)

Слабый указатель инкапсулирует хэндл internal/abi.WeakHandle. Во время фазы concurrent mark сборщик мусора Go сначала находит все живые объекты по сильным ссылкам. Если объект помечен белым (недостижим), рантайм зануляет все слабые ссылки на него, после чего освобождает память в фазе sweep. Вызов wp.Value() атомарен и защищён барьером чтения (read barrier), исключая race condition между GC и кодом пользователя.

Типичные ошибки кандидатов

Разыменование без проверки на nil: Значение wp.Value() может стать nil в любой произвольный момент времени между тактами выполнения. Обязательна идиома if ptr := wp.Value(); ptr != nil { ... }.
Путаница с unsafe.Pointer: unsafe.Pointer отключает типобезопасность компилятора, но остаётся для GC сильной ссылкой. weak.Pointer типобезопасен (weak.Pointer[T]), но прозрачен для GC.

Возможные дополнительные вопросы интервьюера

Можно ли создать слабую ссылку на значение на стеке? — Нет, weak.Make форсирует побег объекта в кучу (escape to heap).