Как Go управляет памятью? Каков алгоритм сборщика мусора?

Стек vs куча

Каждая горутина стартует с небольшим стеком (~2–8 KB), который автоматически растёт и сжимается (segmented stack до Go 1.3, contiguous stack начиная с Go 1.4). Компилятор проводит escape analysis: если переменная не «убегает» за пределы функции, она размещается на стеке и не нагружает GC. Переменные, убегающие в другие горутины или возвращаемые как указатели, попадают в кучу.

// Не попадает в кучу — escape analysis ограничивает стеком
func sum(a, b int) int {
    result := a + b  // стек
    return result
}

// Попадает в кучу — указатель «убегает» из функции
func newCounter() *int {
    c := 0    // heap
    return &c
}

Управление памятью в Go

Go использует автоматическое управление памятью с трёхцветным конкурентным сборщиком мусора (GC). Разработчик не вызывает malloc/free вручную — рантайм Go берёт это на себя. Память делится на два основных пространства: стек горутины и кучу (heap).

Алгоритм GC: трёхцветная маркировка

Go применяет алгоритм tri-color mark-and-sweep с конкурентной маркировкой (большая часть работы идёт параллельно с программой):

• Белые объекты — ещё не посещены; в конце цикла будут собраны.
• Серые объекты — достижимы, но их потомки ещё не просмотрены.
• Чёрные объекты — достижимы и все потомки обработаны; останутся в памяти.

Цикл GC состоит из четырёх фаз:

• Mark Setup (STW) — короткая «stop-the-world» пауза для включения write barrier. С Go 1.14 паузы обычно <1 мс.
• Mark (concurrent) — GC-горутины параллельно обходят граф объектов из корней (стеки горутин, глобальные переменные, регистры процессора).
• Mark Termination (STW) — финальная короткая пауза, флашинг write barrier, подтверждение что всё чёрное.
• Sweep (concurrent) — освобождение белых объектов; работает лениво параллельно с программой.

Write Barrier

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

Настройка и мониторинг

package main

import (
    "fmt"
    "runtime"
    "runtime/debug"
)

func main() {
    // GOGC задаёт целевой коэффициент роста кучи (default=100 => +100%)
    // GOGC=50 — GC запускается при росте кучи на 50%; агрессивнее, меньше память
    // GOGC=200 — запускается реже, выше пиковое потребление памяти
    debug.SetGCPercent(100)

    // GOMEMLIMIT (Go 1.19+) — жёсткий лимит кучи
    debug.SetMemoryLimit(512 * 1024 * 1024) // 512 MB

    // Ручной запуск GC (для тестов, не для продакшена)
    runtime.GC()

    var ms runtime.MemStats
    runtime.ReadMemStats(&ms)
    fmt.Printf("Alloc=%.2f MB  NumGC=%d  PauseTotalNs=%d\n",
        float64(ms.Alloc)/1e6, ms.NumGC, ms.PauseTotalNs)
}

Переменная окружения GODEBUG=gctrace=1 выводит строку на каждый GC-цикл с длительностью пауз, размером кучи и процентом CPU.

Оптимизационные приёмы

• Переиспользуйте объекты через sync.Pool — снижает давление на аллокатор.
• Передавайте срезы и строки по значению (заголовок — 3 слова на стеке), не как *[]byte.
• Используйте //go:noescape и unsafe.Pointer лишь при доказанной необходимости.
• Прогоняйте go build -gcflags='-m' для анализа escape-decisions компилятора.

Подводные камни

• Срезы с большой ёмкостью: если хранить маленький подсрез большого массива, весь массив остаётся в куче. Используйте copy для обрезки.
• Глобальные переменные как кеши: объекты в глобалах никогда не собираются — утечка нарастает незаметно.
• Замыкания захватывают переменные по ссылке: горутина может удерживать большую структуру дольше, чем ожидается.
• GOGC=off полностью отключает GC — допустимо только в short-lived CLI-инструментах, в серверах ведёт к OOM.
• runtime.ReadMemStats — STW операция: вызов в hot path останавливает мир на время сбора статистики.
• finalizer не заменяет деструктор: runtime.SetFinalizer не гарантирует порядок и время вызова, не использовать для освобождения файловых дескрипторов.
• Игнорирование GOMEMLIMIT в контейнерах: без лимита Go не знает о cgroup-ограничении и допускает OOM-kill от ядра.

• Описывать GC без связи с аллокациями и lifetime объектов.
• Игнорировать pprof heap/allocs при анализе памяти.
• Не замечать удержание backing arrays и долгоживущих ссылок.

• Знает, что GC конкурентный и mark-and-sweep, но не обещает невозможных нулевых пауз.
• Связывает GC с live heap, allocation rate и latency.
• Предлагает сначала оптимизировать shape аллокаций, а не только runtime flags.