> Почему куча медленнее стека (Go)

Короткий ответ

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

Подробное объяснение

Стек - это непрерывная область памяти, привязанная к горутине. Выделение памяти в стеке - это просто сдвиг указателя стека вверх или вниз, что занимает несколько инструкций процессора. Освобождение происходит автоматически при возврате из функции. Данные в стеке имеют высокую локальность и часто остаются в кэше процессора, что снижает latency доступа.

Куча - это динамическая область памяти, управляемая аллокатором. В Go используется tcmalloc-подобный аллокатор с size classes, mcache, mcentral и mheap. Выделение памяти в куче включает поиск подходящего size class, возможную блокировку, обновление метаданных и иногда системные вызовы для расширения heap. Освобождение памяти не мгновенно: сборщик мусора должен определить, что объект больше не достижим, и вернуть память аллокатору.

Кроме того, куча страдает от фрагментации и худшей локальности. Объекты могут быть разбросаны по разным страницам памяти, что увеличивает cache misses. Сборка мусора добавляет паузы и потребляет CPU, хотя в Go GC оптимизирован для низких задержек.

Escape analysis в Go анализирует, может ли объект быть доступен после возврата из функции. Если нет - объект размещается в стеке. Если да - в куче. Это ключевой механизм, который позволяет Go-программам быть эффективными, но он не всесилен: замыкания, интерфейсы, глобальные переменные и большие объекты часто уходят в кучу.

На практике

В backend-сервисах на Go важно минимизировать аллокации в куче на горячем пути. Используйте sync.Pool для переиспользования объектов, избегайте лишних указателей и интерфейсов, где это возможно. Профилируйте с помощью pprof и go build -gcflags=-m, чтобы видеть решения escape analysis. Помните, что преждевременная оптимизация вредна, но в высоконагруженных системах разница между стеком и кучей может быть критичной.

Пример кода

GO
package main

import "fmt"

type Point struct {
    X, Y int
}

//go:noinline
func stackAlloc() Point {
    p := Point{1, 2} // останется в стеке, если не вернуть указатель
    return p
}

//go:noinline
func heapAlloc() *Point {
    p := Point{1, 2} // уйдёт в кучу, так как возвращается указатель
    return &p
}

func main() {
    _ = stackAlloc()
    _ = heapAlloc()
    fmt.Println("done")
}

Запустите go build -gcflags=-m и увидите, что p в heapAlloc escaped to heap.

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

Сначала дайте короткий ответ про аппаратную поддержку и аллокатор. Затем углубитесь в escape analysis, tcmalloc-подобный аллокатор Go и сборку мусора. Упомяните, что стек не всегда применим: размер стека ограничен, а время жизни объекта может превышать время жизни функции. Приведите пример с возвратом указателя. Если спросят про оптимизации, расскажите про sync.Pool и профилирование.

Что проверяет интервьюер

Понимание модели памяти Go, работы аллокатора и сборщика мусора. Умение объяснить trade-off между стеком и кучей. Знание escape analysis и практических приёмов оптимизации. Способность связать теорию с реальными backend-сценариями.

Типичные ошибки

Говорить, что стек всегда быстрее, без учёта ограничений. Путать стек горутины с системным стеком. Считать, что escape analysis гарантирует размещение в стеке. Игнорировать влияние сборщика мусора на latency. Предлагать преждевременную оптимизацию без профилирования.