Память, GC и производительность

Стек

У каждой горутины свой стек (стартует с 2 КБ в Go 1.4+ и растёт удвоением до maxstacksize, по умолчанию 1 ГБ на 64-битных). Память под кадр функции резервируется в прологе одним вычитанием из указателя стека, освобождается в эпилоге одним сложением. Списков свободных блоков, поиска подходящего размера и блокировок здесь нет: стек не разделяется между горутинами. Данные кадра почти наверняка горячие в L1: адреса, к которым только что обращались.

Куча

Куча одна на процесс и устроена как TCMalloc. Путь аллокации: mcache (локальный кэш текущего P, без блокировок) → mcentral (общий на размерный класс, наборы спанов в нём lock-free) → mheap (страницы, глобальный лок) → mmap у ОС. Объекты раскладываются по 68 размерным классам до 32 КБ, всё крупнее идёт как large object напрямую из mheap. Плюс tiny-аллокатор: несколько объектов меньше 16 байт без указателей упаковываются в один блок. Свежая деталь на добивку: с Go 1.27 мелкие аллокации (до 80 байт) идут через процедуры, специализированные по размерному классу на этапе компиляции, и это экономит до 30 % на самом горячем пути аллокатора.

Что где оказывается

• Всегда на стеке: аргументы, возвращаемые значения (часто вообще в регистрах благодаря register ABI с Go 1.17) и локальные переменные, если компилятор доказал их «неутечку». Параметр, чей адрес убегает, компилятор переносит в кучу, как и локальную переменную.
• Всегда в куче: глобальные переменные (технически они в сегменте данных, но сканируются как корни), всё, на что ссылаются из кучи, всё непрозрачного размера, кроме мелочи: с Go 1.25 слайс переменного размера до 32 байт остаётся на стеке.
• Решает компилятор: всё остальное, этим и занимается escape analysis. При этом new() и &T{} не гарантируют кучу, а литерал структуры не гарантирует стек.

Почему «дешевле» — по пунктам

1. Выделение: одна арифметическая операция против mallocgc с поиском размерного класса, проверкой кэша и (иногда) с уходом в mcentral. С Go 1.27 этот разрыв немного сократился: для объектов до 80 байт компилятор подставляет процедуру, специализированную под конкретный размерный класс, и мелкая аллокация дешевеет до 30 % (ценой ~60 КБ размера бинаря).
2. Освобождение: бесплатно и мгновенно, против отложенной работы sweeper-а.
3. Работа GC: стек сканируется один раз за цикл целиком, объекты в куче обходятся по графу.
4. Локальность: кадры лежат подряд, объекты в куче разбросаны, отсюда больше промахов кэша.

Формально компилятор строит граф «кто на кого может ссылаться»: вершины — переменные и аллокации, рёбра — присваивания с весом derefs (число разыменований минус взятий адреса). Затем ищет пути, по которым адрес попадает в кучу или переживает свою переменную. Для каждой функции получается сводка по параметрам, которая уезжает в export data пакета, поэтому анализ работает и через границы пакетов. Отсюда строки вида leaking param: name в выводе -m.

Правила побега (в порядке частоты)

1. Возврат указателя на локальную переменную, например return &User{}. Ссылка по определению живёт дольше кадра.
2. Запись указателя в объект, который сам в куче: global = &x, s = append(s, &x), obj.F = &x. Рантайм держит инвариант: из кучи нельзя ссылаться на стек, иначе перемещение стека всё сломает.
3. Упаковка в интерфейс: fmt.Println(x), var a any = x. Интерфейс хранит указатель на данные, а метод вызывается непрозрачно, значит, компилятор обязан считать, что данные утекают. Исключение бывает, когда компилятор девиртуализует вызов и видит тело.
4. Захват замыканием, которое переживает функцию, как в go func(){ use(x) }() или return func(){...}. Объект-замыкание уезжает в кучу; мелкие неизменяемые переменные копируются в него, а те, что замыкание меняет, переезжают в кучу отдельно.
5. Отправка в канал (ch <- &x): читатель сидит на другом стеке.
6. Неизвестный на компиляции размер: make([]byte, n) с переменной n, make(map[K]V, n). В кадре нельзя зарезервировать «сколько-нибудь», поэтому на стеке есть только запас на мелкий случай: 32 байта у слайса (с Go 1.25), одна группа на 8 элементов у мапы.
7. Слишком большой объект. У компилятора есть лимиты: 128 КБ (до Go 1.24 было 10 МБ) для явных локальных переменных и 64 КБ для неявных аллокаций (new, &T{}, литералы, make с константой).
8. Непрозрачный вызов через переменную-функцию или интерфейс: тела не видно, поэтому считаем, что параметры утекают. Рекурсия к этому не относится: рекурсивные функции компилятор анализирует вместе и видит их тела, так что параметры вполне могут не утекать.

func a() *int   { x := 1; return &x }        // moved to heap: x
func b()        { x := 1; sink = &x }        // moved to heap: x
func c(v int)   { fmt.Println(v) }            // v escapes to heap (интерфейс)
func d() func() { x := 1; return func(){ x++ } } // moved to heap: x + func literal escapes to heap
func e(n int)   { _ = make([]byte, n) }       // does not escape: до 32 байт на стеке (Go 1.25+), больше — куча
func f()        { _ = make([]byte, 4096) }    // does not escape: константа, влезает в кадр
func g(p *T)    { p.X = 1 }                   // p does not escape: только читаем/пишем поля

// go build -gcflags="-m -l", вывод go1.27 дословно:
//   ./m.go:9:19: moved to heap: x
//   ./m.go:10:19: moved to heap: x
//   ./m.go:11:30: ... argument does not escape
//   ./m.go:11:31: v escapes to heap
//   ./m.go:12:19: moved to heap: x
//   ./m.go:12:34: func literal escapes to heap
//   ./m.go:13:27: make([]byte, n) does not escape
//   ./m.go:14:27: make([]byte, 4096) does not escape
//   ./m.go:15:8: p does not escape
//
// Про e(): «does not escape» тут значит только «указатель наружу не
// уходит». Размер n на компиляции неизвестен, кадр под него заранее
// не зарезервируешь. С Go 1.25 компилятор держит на стеке буфер в 32 байта
// и идёт в кучу, только если n больше. Целиком на стеке живёт f() с константой.
// Проверено на go1.27: e(16) — 0 аллокаций, e(64) — одна.

$ go build -gcflags="-m" ./...            # свои пакеты
$ go build -gcflags="-m -m" ./...         # с цепочкой причин
$ go build -gcflags="all=-m" ./...        # включая зависимости
$ go build -gcflags="-m -l" ./pkg         # без инлайна
$ go test -gcflags="-m" -bench=. ./pkg    # то же для бенчей
$ go build -gcflags="-m" ./... 2>&1 | grep 'escapes to heap' | sort | uniq -c | sort -rn

Что читать в выводе

Чем добить

Одного -m мало: он показывает решения, а не стоимость. В пару к нему берут:

• go test -bench=. -benchmem покажет allocs/op и B/op, то есть сколько это стоит на самом деле.
• go build -gcflags="-m=2" эквивалентен -m -m.
• -gcflags="-d=ssa/check_bce/debug=1" найдёт, где остались проверки границ (bounds check).
• go tool pprof -alloc_objects ответит, кто реально аллоцирует в проде, а не в теории.

Приёмы, которые реально работают

1. Отдавать буфер снаружи. func F(dst []byte, ...) []byte вместо func F(...) []byte. Так устроены strconv.AppendInt, time.Time.AppendFormat, fmt.Appendf (Go 1.19).
2. Принимать указатель на результат вместо возврата указателя: func Parse(b []byte, out *Msg) error.
3. Не пропускать значение через any в горячем пути: fmt.Sprintf боксит каждый аргумент. Вместо него бери strconv, strings.Builder, дженерики (для типов с одинаковой GC-формой инстанцирование не создаёт интерфейс).
4. Ограничить область жизни: не сохранять указатель в глобальную структуру «на всякий случай», не передавать в горутину то, что можно передать копией.
5. Константные размеры: make([]byte, 4096) остаётся на стеке, а make([]byte, n) больше 32 байт нет. Иногда помогает верхняя граница: var buf [256]byte; b := buf[:n] при n <= 256.

Чего делать не надо

• Для оптимизации Go-кода //go:noescape не годится. Это обещание компилятору про ассемблерную функцию (объявленную без тела), что она не сохраняет переданные указатели. Если соврать, при перемещении стека память испортится.
• sync.Pool не отменяет побег: объект по-прежнему в куче, он просто переиспользуется.
• unsafe ради «оставить на стеке» почти всегда хуже аллокации, которую ты пытался убрать.

Три силы

1. Стоимость копии. С Go 1.17 на amd64 (с Go 1.18 и на arm64) работает register-based ABI: на amd64 9 целочисленных регистров и 15 float-регистров под аргументы и результаты, на arm64 по 16. Структура из 2–4 машинных слов возвращается вообще без записи в память.
2. Стоимость аллокации. Возврат *T из функции почти всегда заканчивается строкой escapes to heap, а за ней стоят mallocgc и будущая работа сборщика.
3. Стоимость для GC потом. Слайс []T из структур без указателей помечен как noscan и не сканируется вообще. []*T на миллион элементов даёт сборщику миллион объектов, которые он обходит каждый цикл. Разница тут на порядки, и она важнее копий.

type Point struct {
    X, Y float64
}   // 16 байт, noscan

// хорошо: возврат в регистрах, аллокаций 0
func Mid(a, b Point) Point { return Point{(a.X+b.X)/2, (a.Y+b.Y)/2} }

// плохо в горячем пути: что ни вызов, то mallocgc и работа GC
func MidPtr(a, b *Point) *Point { return &Point{...} }

// а ещё важнее, как хранить:
pts := make([]Point,  1_000_000)  // 1 объект, спан noscan, GC его не обходит
ptr := make([]*Point, 1_000_000)  // 1_000_001 объект, каждый цикл GC обходит миллион

Механика

1. Пролог почти каждой функции сравнивает SP с полем stackguard0 в структуре g. Проверка занимает пару инструкций, ветка предсказуемая.
2. Места не хватило: вызывается runtime.morestack, горутина попадает в newstack.
3. Выделяется новый блок как минимум вдвое большего размера (стеки берутся из пулов по размерам: 2, 4, 8, 16 КБ и дальше из mheap).
4. memmove копирует старые кадры в новый блок.
5. Рантайм проходит по кадрам, по stack maps находит все слоты-указатели и прибавляет дельту к тем, что указывали внутрь старого стека. Плюс правит указатели в defer-записях и в g.
6. Старый блок освобождается, выполнение продолжается с того же места.

Сжатие тоже есть: если при сканировании стека в фазе маркировки занято меньше четверти, рантайм может скопировать стек в блок вдвое меньше (shrinkstack). Верхний предел задаёт runtime/debug.SetMaxStack, по умолчанию 1 ГБ на 64 битах; превысишь его и получишь fatal error: stack overflow (это не паника, её не поймать).

Почему это возможно в Go и невозможно в C

В Go указатели точно типизированы, а адресной арифметики нет. Компилятор для каждой точки вызова знает, какие слоты кадра содержат указатели, и записывает это в метаданные, так что рантайм может найти и переписать каждую ссылку. В C указатель неотличим от long: «починить» его невозможно, поэтому размер стека фиксируется заранее (типично 8 МБ на поток), а переместить его нельзя. Отсюда прямое следствие: миллион горутин по 2 КБ реален, а миллион потоков по 8 МБ нет.

Цвета

• Белый — бит маркировки не стоит, объекта нет в очереди: кандидат в мусор.
• Серый — бит стоит, объект в очереди работы: нашли, но поля ещё не прочитали.
• Чёрный — бит стоит, поля просканированы, из очереди вынут.

Сам цвет не поле объекта. Физически есть биты маркировки в метаданных спана (gcmarkBits) и распределённая очередь работы: у каждого P свой буфер gcWork, при переполнении он отдаётся в глобальную очередь, откуда его крадут другие воркеры. За счёт этого маркировка и масштабируется по ядрам.

Ход цикла

1. Корни (глобальные переменные, стеки всех горутин, регистры) красятся в серый.
2. Пока очередь не пуста: достать объект, просканировать его поля по карте указателей типа, все белые дети — в серый и в очередь, сам объект — чёрный.
3. Очередь пуста → всё белое недостижимо → sweep возвращает эти блоки в спаны.

Что назвать, чтобы ответ был сильным

• Неперемещающий: адреса стабильны, барьера чтения нет, cgo и unsafe.Pointer работают; платить приходится фрагментацией и невозможностью уплотнения.
• Без поколений: роль young generation исполняет стек, куда escape analysis отправляет почти весь короткоживущий мусор, и там он умирает бесплатно.
• Стоимость пропорциональна живым данным, а не мусору: гигабайт []byte (noscan-спан) сборщик не сканирует вообще, а map[string]*Item на 10 млн записей обходится каждый цикл.
• Цель — latency, а не throughput. Go сознательно отдал пропускную способность ради коротких пауз: 25% CPU во время цикла и есть эта плата, заложенная в дизайн.
• Green Tea — маркировка по умолчанию с Go 1.26. Экспериментом был в 1.25 (GOEXPERIMENT=greenteagc), теперь включён сам; выключается GOEXPERIMENT=nogreenteagc. Суть: для мелких объектов (до 512 байт) единицей работы стал спан, а не отдельный объект. Старый обход прыгал по указателям в случайные места памяти и упирался не в вычисления, а в промахи кэша; Green Tea ставит в очередь спан целиком и сканирует все накопившиеся в нём помеченные объекты разом. Доступ становится последовательным, работает предвыборка, метаданные читаются пачкой. Итог: −10…40 % накладных расходов GC, плюс ещё около 10 % на свежих amd64 (Intel Ice Lake и новее, AMD Zen 4 и новее) за счёт векторных инструкций. Сам алгоритм не изменился: те же три цвета, тот же инвариант, тот же барьер записи, поменялся только порядок обхода.

Какую гонку он ловит

Беда случается, когда совпадают два события: ссылку на белый объект записали в уже чёрный, и одновременно удалили ту ссылку, по которой сборщик до белого собирался дойти. Чёрный объект повторно не сканируется, значит, белый останется белым, будет подметён, и приложение получит указатель в освобождённую память. Барьер перехватывает саму запись и красит нужный объект в серый.

Три варианта

// то, что компилятор подставляет вместо obj.field = ptr во время маркировки
func gcWriteBarrier(slot *unsafe.Pointer, ptr unsafe.Pointer) {
    if writeBarrier.enabled {     // вне цикла GC это одна предсказуемая ветка
        shade(*slot)              // Yuasa: спасаем старую цель
        if stackIsGrey(getg()) {  // упрощение: рантайм кладёт в буфер оба указателя всегда
            shade(ptr)            // Dijkstra: спасаем новую цель
        }
    }
    *slot = ptr
}

Ключевое следствие гибрида (то, ради чего его сделали)

Записи в стек барьером не покрываются, иначе каждое присваивание локальной переменной стало бы дорогим. При чистом Dijkstra это означало, что стеки нельзя считать окончательно чёрными, и в конце цикла их пересканировали под stop-the-world: пауза росла с числом горутин и доходила до сотен миллисекунд. Yuasa-часть даёт «снимок на начало цикла»: всё, что было достижимо в момент старта, переживает этот цикл. Поэтому стек сканируется один раз и красится в чёрный навсегда, а mark termination стал занимать десятки микросекунд и перестал зависеть от размера кучи.

1. Sweep termination (STW). Домести спаны, оставшиеся от прошлого цикла (sweep ленивый, хвост мог не разобраться), включить write barrier, перевести все P в режим маркировки.
2. Mark (конкурентно). Сканируются корни: глобальные переменные и стек каждой горутины (ровно один раз за цикл; горутина при этом коротко приостанавливается, но общего STW нет). Затем обход графа. Работают dedicated воркеры (25% от GOMAXPROCS), fractional-воркер на дробную часть и mark assist у аллоцирующих горутин.
3. Mark termination (STW). Проверить, что очередь работы пуста, выключить write barrier, посчитать цель следующего цикла, сбросить статистику.
4. Sweep (конкурентно и лениво). Спаны подметает фоновая горутина, а недометённый спан подметается в момент, когда mcache просит новый. Значит, стоимость размазана по времени и аллокациям и отдельного пика в профиле не даёт.

Как физически реализуется STW

stopTheWorld выставляет у каждого P флаг преемпции и ждёт, пока все горутины дойдут до безопасной точки. До Go 1.14 такой точкой был только вызов функции, поэтому «горячий цикл без вызовов» мог задержать весь STW на неопределённое время. Отсюда знаменитый баг с зависанием на for {}. С 1.14 работает асинхронная преемпция: рантайм шлёт потоку сигнал SIGURG и останавливает горутину практически где угодно.

1. Цель кучи и pacer

GOGC задаёт процент прироста относительно живых данных прошлого цикла (с Go 1.18 к ним прибавляются стеки и глобальные переменные). При GOGC=100 и live set 100 МБ следующий цикл целится примерно в 200 МБ. Но pacer не ждёт достижения цели буквально: он оценивает скорость аллокации и скорость маркировки и стартует заранее, чтобы маркировка успела закончиться ровно к тому моменту, как куча дорастёт до цели. Если pacer ошибся и приложение аллоцирует быстрее, включается mark assist, который тормозит аллокаторов и не даёт куче перелететь цель.

// живых данных 100 МБ, стеки и глобальные ничтожны:
GOGC=100  -> цель 200 МБ   // по умолчанию
GOGC=50   -> цель 150 МБ   // циклов больше, память ниже, CPU выше
GOGC=400  -> цель 500 МБ   // циклов меньше, память выше, CPU ниже
GOGC=off  -> цели нет      // GC не запускается по росту кучи

debug.SetGCPercent(200)    // то же самое из кода, возвращает старое значение

2. Принудительно

runtime.GC() блокирует вызывающую горутину до завершения полного цикла; если цикл уже идёт, сначала дожидается его, потом запускает свой. Звать его законно перед снятием heap-профиля (чтобы inuse отражал реально живое), в тестах на утечки, перед долгой паузой в работе демона. В обычном коде такой вызов почти всегда ошибка. Есть ещё debug.FreeOSMemory(): он делает runtime.GC() и вдобавок агрессивно возвращает страницы ОС.

3. По таймеру

Системный монитор sysmon форсирует цикл, если с последнего прошло больше 2 минут (константа forcegcperiod в runtime/proc.go). Простаивающий сервис не аллоцирует, цель кучи не достигается никогда, и без таймера он бесконечно держал бы мусор и не отдавал память ОС.

Проблема, которую он закрыл

Под с лимитом 1 ГБ. Живых данных обычно 300 МБ, GOGC=100 → цель 600 МБ, всё хорошо. Приходит всплеск трафика, live set подскакивает до 600 МБ → цель 1.2 ГБ → OOM-kill до того, как сборщик успел что-то предпринять. До 1.19 выкручивались через ballast: выделить make([]byte, 1<<30), никогда его не трогать (страницы не коммитятся, RSS не растёт) и тем самым искусственно задрать базу для расчёта цели. Костыль работал, но был хрупким и непонятным. GOMEMLIMIT сделал это штатной ручкой.

Что именно ограничивается

В лимит входит больше, чем куча: куча + стеки горутин + метаданные GC + внутренние структуры рантайма, то есть всё, что в runtime/metrics называется /memory/classes/total:bytes, минус то, что уже возвращено ОС. Вне лимита остаётся память, о которой рантайм не знает: cgo, mmap руками, память драйверов. Поэтому лимит ставят с запасом.

# лимит пода 1Gi -> оставляем 20% запаса
GOMEMLIMIT=800MiB
GOGC=off        # GC срабатывает только у потолка: максимум throughput, минимум циклов
GOMAXPROCS=2    # до Go 1.25 (или при go ниже 1.25 в go.mod) — automaxprocs или вручную

import "runtime/debug"

func main() {
    // то же из кода, в байтах; лимит cgroup лежит в /sys/fs/cgroup/memory.max
    debug.SetMemoryLimit(800 << 20)
    debug.SetGCPercent(-1)  // GOGC=off
}

Сценарии, где он реально нужен

• Контейнер с жёстким лимитом, основной случай: OOM-kill превращается в замедление.
• Сервис с большим кэшем в памяти: кэш растёт, но не должен утащить под за границу.
• Batch/CLI-задачи: GOGC=off + лимит = максимум скорости при известном потолке.
• Сервис с маленьким live set и высоким темпом аллокаций: GOGC побольше, лимит как страховка.

debug.SetGCPercent(-1)        // выключить, как GOGC=off
old := debug.SetGCPercent(400) // изменить, вернуть предыдущее
runtime.GC()                   // синхронно прогнать полный цикл
debug.FreeOSMemory()           // цикл + агрессивно вернуть страницы ОС
debug.SetMemoryLimit(n)        // потолок; работает даже при GOGC=off

Когда выключение оправдано

• Короткоживущие CLI и batch-задачи: процесс живёт минуту, память заведомо влезает. Зачем платить за сборку того, что ОС всё равно освободит при выходе?
• Связка GOGC=off + GOMEMLIMIT, паттерн из официального руководства по GC (go.dev/doc/gc-guide): GC не мешает, пока памяти вдоволь, и включается ровно у потолка.
• Латентно-критичные окна (торговые системы): выключить на время сессии, прогнать runtime.GC() в паузе.
• Бенчмарки и профилирование: так из измерений уходит шум сборщика.

Когда оправдана настройка GOGC (без выключения)

1. Меньше объектов

• Преаллокация: make([]T, 0, n) убирает цепочку перевыделений; каждое из них порождает новый объект и отправляет старый в мусор. make(map[K]V, n) делает то же для мап и избавляет от серии рехэшей.
• Переиспользование буфера: buf = buf[:0] сохраняет ёмкость и обнуляет длину, так что после прогрева аллокаций нет.
• Батчинг: один слайс на N элементов вместо N отдельных объектов.

2. Меньше указателей

Спан, в котором лежат объекты без указателей, помечен как noscan, и сборщик в него не заглядывает. Отсюда:

// GC обходит 10 млн объектов каждый цикл
items := make([]*Item, 10_000_000)

// GC не сканирует ничего, если в Item нет указателей
items := make([]Item, 10_000_000)

// UUID как строка = указатель + длина, объект в куче
type Row struct {
    ID string
}
// UUID как массив = 16 байт внутри структуры, noscan
type Row struct {
    ID [16]byte
}

// ссылки заменяем индексами в плотный слайс
type Node struct {
    Left, Right int32
}
nodes := make([]Node, n)

3. sync.Pool — и его правила

var bufPool = sync.Pool{
    New: func() any { return new(bytes.Buffer) },
}

func handle(w http.ResponseWriter, r *http.Request) {
    b := bufPool.Get().(*bytes.Buffer)
    b.Reset()                 // обязательно: в пуле лежит грязный объект
    defer bufPool.Put(b)
    // ... пишем в b, отдаём ответ ...
}

• Пул не ограничивает число объектов и не служит кэшем: содержимое чистится каждый цикл GC (точнее, victim cache отдаёт объектам ещё один цикл жизни).
• Кладя объект обратно, обнуляй его, иначе данные утекут между запросами (реальный класс уязвимостей), а память останется занятой.
• Не клади в пул слайсы разного размера: один жирный буфер будет держаться вечно. Обычно в пул просто не возвращают то, что выросло больше порога.
• Пул выигрывает только на крупных объектах: Get/Put сами по себе стоят около десятка наносекунд, для мелочи это дороже аллокации.
• Значение из пула нельзя использовать после Put, но на этом регулярно попадаются.

Что грузит GC

gctrace — когда надо посмотреть здесь и сейчас

$ GODEBUG=gctrace=1 ./service 2>&1 | grep '^gc '
gc 43 @0.912s 1%: 0.028+1.6+0.013 ms clock, ..., 107->108->54 MB, 110 MB goal, 0 MB stacks, 0 MB globals, 8 P
#     |       |   |     |   |                    |    |    |      |
#     |       |   |     |   STW2                 |    |    live   цель pacer-а
#     |       |   |     конкурентная маркировка  |    куча в конце
#     |       |   STW1                           куча в начале цикла
#     |       доля CPU на GC с момента старта
#     время от старта

# полезные соседи:
$ GODEBUG=gctrace=1,scavtrace=1 ./service   # ещё и возврат памяти ОС
$ GODEBUG=inittrace=1 ./service             # долгие init(), частая причина медленного старта

Что экспортировать в Prometheus

samples := []metrics.Sample{
    {Name: "/gc/heap/live:bytes"},            // живые данные, главный признак утечки
    {Name: "/gc/heap/goal:bytes"},            // цель pacer-а
    {Name: "/gc/heap/allocs:bytes"},          // сколько всего нааллоцировано (счётчик)
    {Name: "/gc/cycles/total:gc-cycles"},     // частота циклов
    {Name: "/sched/pauses/total/gc:seconds"}, // гистограмма пауз, смотреть p99
    {Name: "/cpu/classes/gc/total:cpu-seconds"}, // доля CPU на GC
    {Name: "/memory/classes/total:bytes"},    // то, что ограничивает GOMEMLIMIT
    {Name: "/sched/goroutines:goroutines"},   // ловит утечку горутин
}
metrics.Read(samples)

Если сервис уже отдаёт promhttp, коллекторы collectors.NewGoCollector с WithGoCollectorRuntimeMetrics подтягивают это без ручного кода.

Как читать пилу

• Зубцы сами по себе нормальны: вершина = момент старта цикла, спад = освобождение. Отсутствие зубцов при активном трафике подозрительно сильнее, чем их наличие.
• Нижняя огибающая ползёт вверх, значит, растёт live set. Это либо утечка, либо прогрев кэша (у кэша рост выходит на плато, а у утечки нет).
• Зубцы стали чаще и мельче: то ли куча подошла к GOMEMLIMIT, то ли упал live set.
• RSS не падает вслед за heap, и это не утечка: рантайм отдаёт страницы ОС лениво, фоновым scavenger-ом, поэтому RSS отстаёт от кучи. На Linux Go по умолчанию отдаёт их через MADV_DONTNEED, и тогда они из RSS уходят; задержка тут не от разметки, а от неспешности возврата. MADV_FREE («можешь забрать, если понадобится», RSS остаётся высоким до нехватки памяти) включается только через GODEBUG=madvdontneed=0. Смотреть надо на /gc/heap/live, а не на RSS контейнера.

Корни, из которых тянутся ссылки

Глобальные переменные пакетов, стеки всех живых горутин, значения в sync.Pool, объекты, зарегистрированные в рантайме (таймеры, тикеры, финалайзеры), а также всё, что достижимо из этого транзитивно. Утечка = что-то из этого списка держит ссылку слишком долго.

Типовые причины

1. Глобальный кэш/мапа без вытеснения. Только пишем, никогда не удаляем. Есть и отдельный нюанс: delete из мапы память не возвращает, и мапа, разросшаяся до миллиона записей, после очистки держит таблицу прежнего размера. Вернуть память можно только одним способом: создать новую мапу.
2. Утечка горутин в проде встречается чаще всех. Горутина, навсегда вставшая на отправке в небуферизованный канал или на select без ctx.Done(), держит свой стек (минимум 2 КБ, часто больше) и всё, до чего дотягивается из него. Тысяча зависших горутин с телом запроса внутри съедает сотни мегабайт.
3. Подслайс держит весь массив. small := big[:10] — cap остался от big, значит жив весь исходный массив.
4. Подстрока держит исходную строку по той же механике.
5. «Хвост» слайса после удаления. s = s[:len(s)-1] оставляет указатель в подложке массива: элемент недоступен, но достижим.
6. Забытые time.Ticker / time.AfterFunc. Тикер без Stop() до Go 1.23 жил в рантайме вечно. С 1.23 недостижимые таймеры и Ticker собираются и без Stop, а вот AfterFunc до срабатывания по-прежнему держит замыкание со всем захваченным.
7. Не закрытый http.Response.Body держит соединение, буферы чтения и мешает переиспользованию keep-alive.
8. Замыкание, захватившее лишнее. Колбэк, положенный в долгоживущую структуру, тянет за собой весь контекст запроса.
9. Растущий контекст: цепочка context.WithValue в долгоживущем контексте.

// 1. Классическая утечка горутины: писатель без читателя
func leak() {
    ch := make(chan int)      // небуферизованный
    go func() { ch <- 42 }()  // навсегда: читателя не будет
    // забыли прочитать -> горутина, её стек и всё захваченное живут вечно
}

// 2. Подслайс
data, _ := os.ReadFile("10mb.bin")
head := data[:16]                            // жив весь 10 МБ массив
head = append([]byte(nil), data[:16]...)     // а так — только 16 байт

// 3. Хвост слайса
func remove(s []*Conn, i int) []*Conn {
    copy(s[i:], s[i+1:])
    s[len(s)-1] = nil          // без этой строки последний Conn недостижим, но жив
    return s[:len(s)-1]
}

// 4. Мапа не отдаёт память
delete(cache, k)               // память под таблицу остаётся
cache = make(map[string]V, 0)  // единственный способ реально освободить

Четыре режима heap-профиля

Разница принципиальная: функция, которая создала терабайт короткоживущих буферов, будет топ-1 в alloc_space и вообще не появится в inuse_space. И наоборот, утечка на 500 МБ может быть незаметна в alloc, если копится медленно. Ищешь утечку → inuse. Ищешь нагрузку на GC → alloc.

Пошагово

# 0. Профиль снимаем после полного цикла GC,
#    иначе в inuse попадёт ещё не собранный мусор.
$ curl -s 'localhost:6060/debug/pprof/heap?gc=1' > h1.pprof
$ sleep 600
$ curl -s 'localhost:6060/debug/pprof/heap?gc=1' > h2.pprof

# 1. Разница снапшотов показывает, что выросло за 10 минут
$ go tool pprof -base h1.pprof h2.pprof
(pprof) top20                 # кто вырос
(pprof) list ^myapp\.Cache    # построчно внутри подозреваемого
(pprof) traces                # полные стеки аллокаций
(pprof) peek NewBuffer        # кто вызывает

# 2. Веб-интерфейс с флеймграфом и графом вызовов
$ go tool pprof -http=:8080 -base h1.pprof h2.pprof

# 3. Параллельно всегда проверяй горутины
$ curl -s 'localhost:6060/debug/pprof/goroutine?debug=1' | head -40
$ go tool pprof -http=:8081 'localhost:6060/debug/pprof/goroutine'

Как читать результат

• flat — сколько аллоцировала сама функция, cum — она и всё, что она вызвала. Утечку ищут по cum сверху вниз, конкретную строку — по flat.
• list ФункцияName показывает исходник с байтами напротив каждой строки, и так быстрее всего находится конкретный append или Sprintf.
• Если в топе runtime.malg или runtime.newproc1, вопрос не к тебе, а к числу горутин.
• Стеки с chan receive / chan send и большим временем в goroutine?debug=2 прямо указывают на зависшую горутину.

Шесть причин не полагаться

1. Вызова может не быть вообще. При завершении программы финалайзеры не запускаются: если объект дожил до выхода, функция не выполнится.
2. Время не определено. Между смертью объекта и вызовом может пройти сколько угодно циклов GC. Для файловых дескрипторов и соединений это означает исчерпание лимита ОС задолго до срабатывания.
3. Объект живёт минимум на цикл дольше. Первый цикл обнаруживает недостижимость и ставит объект в очередь финалайзеров, откуда тот снова становится достижимым (воскрешение). Освободит его только следующий цикл.
4. Циклы не собираются. Если объекты с финалайзерами ссылаются друг на друга, не освободится ни один и не вызовется ни один финалайзер.
5. Легко случайно сделать объект бессмертным. Замыкание, захватившее сам obj, держит ссылку на него от корня очереди финалайзеров, и объект не умрёт никогда. Классический баг.
6. Выполняется в отдельной горутине и последовательно для всех объектов: медленный финалайзер блокирует остальные, а паника в нём валит процесс.

// так нельзя: объект никогда не умрёт
runtime.SetFinalizer(f, func(x *File) {
    log.Printf("closing %v", f)   // замыкание захватило f, ссылка вечная
    syscall.Close(f.fd)
})

// Go 1.24: заменяем на AddCleanup
runtime.AddCleanup(f, func(fd int) { syscall.Close(fd) }, f.fd)

Чем runtime.AddCleanup (Go 1.24) лучше

• Функция получает отдельный аргумент, а не сам объект, поэтому держать объект ей незачем. Но если замыкание или аргумент всё же ведут к объекту, хотя бы через третью структуру, он не умрёт никогда: паникой рантайм ловит только простые случаи, когда аргумент равен объекту или замыкание захватило его напрямую.
• Нет воскрешения: объект освобождается в том же цикле, cleanup выполняется после.
• Циклические структуры собираются нормально.
• На один объект можно повесить несколько cleanup-ов (SetFinalizer разрешает строго один).
• Работает с внутренними указателями объекта.
• С Go 1.25 очередь cleanup-ов разбирается параллельно, несколькими горутинами: раньше всё делала одна, и один медленный обработчик подвешивал остальные.
• SetFinalizer формально не удалён, но в новом коде считается устаревшим.

Где они всё-таки уместны

• Подстраховка в библиотеке: так os.File закрывает дескриптор, если пользователь забыл Close(). Именно подстраховка, а не основной путь.
• Освобождение памяти, выделенной вне Go (cgo, mmap): GC про неё не знает.
• Диагностика: повесить cleanup, который пишет в лог «объект X собран без Close». Так в тестах и находят утечки ресурсов.

Профили

• cpu: сэмплирование стеков по SIGPROF 100 раз в секунду. Снимается за интервал, обязательно под нагрузкой.
• heap про аллокации, у него четыре режима: inuse_space, inuse_objects, alloc_space, alloc_objects. Сэмплирование по умолчанию раз в 512 КБ.
• goroutine даёт полный снимок стеков всех живых горутин. Долго был главным инструментом против утечки горутин.
• goroutineleak 1.27 показывает только те горутины, которые заблокированы навсегда: ждут канал, мьютекс или WaitGroup, до которого из живой части программы уже не дотянуться. Эвристики «висит подозрительно долго» тут нет, недостижимость считает сборщик мусора. Экспериментом был в 1.26, с 1.27 лежит в pprof.Profiles() и на /debug/pprof/goroutineleak. На практике раньше в проде смотрели растущий счётчик горутин и вручную разбирали goroutine?debug=2, а теперь есть готовый список виновных.
• block: где горутины ждали синхронизацию; ожидания дольше заданного rate пишутся все, короткие выборочно. Включается runtime.SetBlockProfileRate.
• mutex ловит контеншен: кто заставил других ждать. Включается runtime.SetMutexProfileFraction.
• threadcreate объясняет, почему рантайм создал ОС-поток (cgo, блокирующие сисколлы).
• trace вообще не профиль, а полный лог событий на таймлайне.

Как снять с прода

import _ "net/http/pprof"
// отдельный слушатель на loopback, а не публичный порт приложения
go func() { log.Println(http.ListenAndServe("127.0.0.1:6060", nil)) }()

$ kubectl port-forward pod/api-7f9 6060:6060
$ go tool pprof -http=:8080 'http://localhost:6060/debug/pprof/profile?seconds=30'
$ go tool pprof -http=:8080 'http://localhost:6060/debug/pprof/heap?gc=1'
$ curl -s 'http://localhost:6060/debug/pprof/goroutine?debug=1' | head -30

Как читать

top -cum отвечает на вопрос «в каком поддереве проблема», top (по flat) на вопрос «в какой конкретно функции», list Func на «в какой строке», peek на «кто это вызывает». Флеймграф: ширина = доля выборок, высота = глубина стека, а ось X к времени отношения не имеет. Ищем широкие плато на стороне листьев (в pprof это низ картинки, корень там сверху): там процессор реально работает; узкий длинный шпиль означает глубокий, но дешёвый стек.

Много CPU

1. Подтвердить: kubectl top pod, user-time именно нашего процесса, не iowait, не сосед по ноде, не throttling из-за CPU-лимита (container_cpu_cfs_throttled).
2. Снять CPU-профиль под нагрузкой: profile?seconds=30.
3. top -cum + флеймграф. Три диагноза по тому, что широкое:
   • gcBgMarkWorker, mallocgc, memmove → это аллокационная проблема, переходим к heap-профилю в режиме alloc_space;
   • encoding/json, reflect, mapaccess, growslice → сериализация и структуры данных;
   • futex, lock2, selectgo, chanrecv → синхронизация: снимаем mutex, block, trace.
4. list по функции, чтобы увидеть конкретные строки.
5. Написать бенчмарк на горячий путь, зафиксировать базу (-count=10).
6. Починить, сравнить benchstat, выкатить, снять профиль ещё раз.
7. Если код уже оптимален, подняться на уровень выше: кэш, батчинг, отказ от лишней работы, другой формат обмена. Быстрее всего выполняется работа, которую не делают.

Много памяти

1. Разделить три диагноза: растёт /gc/heap/live, или растёт только RSS (память просто не отдана ОС, и это не утечка), или это нормальный профиль нагрузки.
2. Сразу проверить горутины: goroutine?debug=1. Растущее число означает утечку горутин, и дальше ищи каналы без читателя и запросы без таймаута.
3. Два heap-снапшота с интервалом 10–30 минут, сравнить: go tool pprof -base h1.pprof h2.pprof, режим inuse_space.
4. Отличить кэш от утечки: кэш выходит на плато, утечка растёт линейно от числа запросов.
5. list / traces по подозреваемому: кто именно держит ссылку.
6. Пройтись по типовому списку: глобальные мапы без вытеснения, подслайсы большого массива, забытые Ticker, незакрытые resp.Body, хвост слайса, жирные замыкания.
7. Если утечки нет, снижать аллокации, ставить GOMEMLIMIT, крутить GOGC. Именно в таком порядке.

Что видно

• Goroutine analysis раскладывает время каждой горутины: выполнение, ожидание планировщика, ожидание сети, синхронизации, GC, сисколла. Это главный экран.
• Таймлайн по P: какая горутина на каком процессоре и когда; сразу видно, если вся работа села на один P.
• Фазы GC прямо на оси: STW-паузы, работа mark-воркеров, mark assist конкретных горутин.
• Scheduler latency: горутина готова, а P нет. Так проявляется нехватка GOMAXPROCS или длинные неотдающие участки.
• Syscall / Network blocking показывает, сколько ждали ОС и сеть.
• Пользовательские регионы и задачи: trace.NewTask, trace.WithRegion, trace.Log выводят свой код на ту же ось.

$ curl -so trace.out 'http://localhost:6060/debug/pprof/trace?seconds=5'
$ go tool trace trace.out       # откроет браузер

Когда именно

• «Латентность плавает, а CPU низкий»: почти всегда это случай для trace.
• Подозрение, что латентность коррелирует с циклами GC (mark assist).
• Подозрение на голодание горутин или на неудачную нарезку работы.
• Долгий сисколл / cgo-вызов, который блокирует M.
• Проверка, что worker pool реально загружает все ядра.

Как подбирается b.N

1. Первый прогон с b.N = 1.
2. Если прогон занял меньше benchtime, следующее N считается как N × (benchtime / elapsed) × 1.2 без округления (круглые числа были до Go 1.13) и не растёт больше чем в 100 раз за шаг.
3. Так до тех пор, пока прогон не дотянет до benchtime (потолок 1e9 итераций).
4. Отчёт печатается по последнему прогону: ns/op = elapsed / b.N. Все предыдущие прогоны выбрасываются, они и служат прогревом.

Практическое следствие для цикла по b.N: функция вызывается целиком несколько раз. Значит, глобальное состояние между прогонами надо сбрасывать, а дорогую подготовку нельзя делать внутри цикла, иначе она умножится на миллионы итераций.

Dead code elimination

// врёт: результат не используется, компилятор выкидывает вызов, получаем 0.3 ns/op
for i := 0; i < b.N; i++ { Hash("x") }

// старый рабочий приём: «слив» в пакетную переменную
var sink uint64
func BenchmarkHash(b *testing.B) {
    var acc uint64
    for i := 0; i < b.N; i++ { acc = Hash("x") }
    sink = acc
}

// Go 1.24: тело b.Loop() компилятор выкинуть не вправе
func BenchmarkHash(b *testing.B) {
    payload := makePayload()   // не попадёт в измерение: таймер стартует внутри Loop
    b.ReportAllocs()
    for b.Loop() { Hash(payload) }
}

b.Loop() решает сразу три вещи: результаты вызовов в теле не выкидываются оптимизатором, функция бенчмарка вызывается один раз, и подготовка до цикла автоматически исключается из времени (не нужен ResetTimer). От свёртки констант он не спасает: с Go 1.26 вызов с литералом в аргументах инлайнится и может посчитаться при компиляции, так что вход бери из переменной. И сам цикл не дешевле ручного: счётчик лежит в полях структуры B, и пустая итерация выходит в разы дороже, чем у цикла по b.N.

К ответу хорошо добавить уточнение по версиям: в Go 1.24–1.25 защита от DCE побочно выключала инлайн вызовов внутри тела цикла, и бенчмарк мерил неинлайненный вариант функции, так что расходились и ns/op, и allocs/op. С Go 1.26 это исправлено: тело for b.Loop() компилируется как обычный код, инлайн работает.

Инструменты вокруг

• b.ReportAllocs() добавляет B/op и allocs/op, как флаг -benchmem. Ставить всегда: аллокации важнее наносекунд, потому что за ними стоит будущая работа GC.
• b.ResetTimer() обнуляет таймер после подготовки (при b.Loop() не нужен).
• b.StopTimer()/b.StartTimer() ставят вокруг дорогой подготовки внутри цикла; сама пара стоит десятки микросекунд (каждый вызов делает ReadMemStats с остановкой мира), и для микроопераций это уже искажение.
• b.RunParallel гоняет тело в GOMAXPROCS горутин и так измеряет контеншен.
• b.SetBytes и b.ReportMetric добавляют MB/s и свои единицы.

$ go test -run='^$' -bench=Encode -benchmem -count=10 > old.txt
$ go test -run='^$' -bench=Encode -benchmem -count=10 > new.txt
$ benchstat old.txt new.txt      # golang.org/x/perf/cmd/benchstat

Что искажает результат

1. Dead code elimination. Результат не используется, поэтому вызова просто нет. Симптом: подозрительно круглые доли наносекунды.
2. Constant folding. Аргумент задан литералом, и компилятор посчитал всё на этапе компиляции. Лечится входом из переменной, которую компилятор не видит насквозь.
3. Инлайнинг, которого не будет в проде. В бенчмарке функция вызывается напрямую и инлайнится; в приложении она спрятана за интерфейсом: вызов косвенный, инлайна нет, и escape analysis решает иначе.
4. Идеальная локальность. Один и тот же вход миллион раз лежит в L1. В проде это промах в память: 1 нс против 80 нс. Разница в разы, и она не в коде.
5. Идеальный предсказатель ветвлений. Одинаковые данные делают все if бесплатными, а на реальном распределении получаешь mispredict на каждой второй итерации.
6. Прогретое состояние. sync.Pool, преаллоцированные буферы, заполненные мапы дают ноль аллокаций со второй итерации. В проде каждый запрос и есть первая итерация.
7. Подготовка внутри цикла: измеряешь генератор данных, а не функцию. И обратная ошибка: StopTimer/StartTimer на каждой итерации сами по себе дороже измеряемой операции.
8. Среда. Turbo boost, тепловой троттлинг, шумный CI, соседи по ноде, разный GOMAXPROCS, включённый профайлер. Отсюда обязательные -count=10 и benchstat.
9. Не тот масштаб. Функцию ускорили в 10 раз, но она занимала 0.5% профиля, и выигрыш составил 0.45%. Закон Амдала никто не отменял.

runtime.MemStats

Плоская структура: HeapAlloc (живые + ещё не подметённые байты), HeapInuse, HeapReleased (возвращено ОС), NumGC, PauseTotalNs, кольцо PauseNs[256], счётчики Mallocs и Frees. Читается через runtime.ReadMemStats, и это его главный минус: вызов останавливает мир на время копирования. На сервисе с тысячами горутин и экспортом раз в секунду мониторинг сам начинает создавать паузы.

runtime/metrics

samples := []metrics.Sample{
    {Name: "/gc/heap/live:bytes"},               // живые данные
    {Name: "/gc/heap/goal:bytes"},               // цель pacer-а
    {Name: "/sched/pauses/total/gc:seconds"},    // гистограмма пауз
    {Name: "/cpu/classes/gc/total:cpu-seconds"}, // доля CPU на GC
    {Name: "/memory/classes/total:bytes"},       // минус heap/released: то, что ограничивает GOMEMLIMIT
    {Name: "/sched/goroutines:goroutines"},      // число горутин
    {Name: "/sched/latencies:seconds"},          // задержка планировщика
    {Name: "/sched/goroutines/runnable:goroutines"}, // Go 1.26: стоят в очереди за P
    {Name: "/sched/threads/total:threads"},          // Go 1.26: число ОС-потоков рантайма
}
metrics.Read(samples)

• Имена версионированные, единицы измерения зашиты в имя после двоеточия.
• Кроме счётчиков, есть гистограммы, так что p99 пауз можно считать честно.
• metrics.All() перечисляет всё доступное в текущей версии Go с описаниями.
• Go 1.26 добавил разбивку по планировщику: /sched/goroutines/running, /runnable, /waiting, /not-in-go, счётчик созданных /sched/goroutines-created и число ОС-потоков /sched/threads/total:threads. До этого была одна цифра «сколько горутин живо», и по ней нельзя было отличить «ждут базу» от «стоят в очереди за P».
• Читается без STW, дёшево, годится для экспорта раз в секунду.
• В prometheus/client_golang подключается через collectors.NewGoCollector(collectors.WithGoCollectorRuntimeMetrics(...)).

expvar

Пакет отдаёт JSON на /debug/vars и по умолчанию публикует memstats и cmdline. Удобно для быстрого дебага и своих счётчиков (expvar.NewInt, expvar.Publish), но он тянет ReadMemStats со всеми последствиями, регистрируется в http.DefaultServeMux (та же проблема безопасности, что у pprof) и публикует командную строку. В проде его закрывают так же, как pprof.

Как растёт слайс

Когда len == cap, рантайм зовёт growslice. Правило с Go 1.18: если требуемая длина больше удвоенной ёмкости, берём её саму; иначе при cap < 256 ёмкость удваивается, а начиная с 256 растёт по формуле newcap += (newcap + 3*256) / 4, то есть коэффициент плавно съезжает с 2x к 1.25x. До Go 1.18 порог стоял на 1024, и переход шёл ступенькой. Потом полученный размер в байтах округляется вверх до класса размеров аллокатора (roundupsize), поэтому реальный cap часто больше расчётного и цифры в cap() иногда кажутся «странными».

var s []int
prev := -1
for i := 0; i < 2000; i++ {
    s = append(s, i)
    if cap(s) != prev { fmt.Print(cap(s), " "); prev = cap(s) }
}
// Реальный вывод go1.27:
// 4 8 16 32 64 128 256 512 848 1280 1792 2560
//
// Дальше удвоение до 256, затем ~1.25x и округление до size class (см. выше).
// А вот начало неожиданное: последовательность стартует не с 1, а с 4. Это работа
// компилятора (Go 1.26+): слайс не убегает из функции, и первый массив он берёт
// на стеке, 32 байта, то есть 4 int. Если тот же append спрятать за
// //go:noinline-функцию, слайс убежит, и вернётся честное 1 2 4 8 16. Для []byte
// стартовая ёмкость по той же причине 32. Мораль: конкретные первые числа —
// деталь реализации, а не гарантия; гарантирована только амортизированная O(1)
// на элемент.

При этом старый массив становится мусором. Рост обходится в копирование, работу для сборщика и всплеск RSS: в момент перевыделения живы оба массива сразу.

Что даёт преаллокация в цифрах

func BenchmarkNoCap(b *testing.B) {
    b.ReportAllocs()
    for b.Loop() {                      // Go 1.24
        out := []int(nil)
        for i := 0; i < 10000; i++ { out = append(out, i) }
        _ = out
    }
}
func BenchmarkWithCap(b *testing.B) {
    b.ReportAllocs()
    for b.Loop() {
        out := make([]int, 0, 10000)
        for i := 0; i < 10000; i++ { out = append(out, i) }
        _ = out
    }
}
// go test -bench=. на go1.27 (Apple M4 Pro, arm64):
// BenchmarkNoCap-14      31342   36412 ns/op   357625 B/op   19 allocs/op
// BenchmarkWithCap-14    63304   20332 ns/op    81920 B/op    1 allocs/op

Устойчиво воспроизводится выигрыш по памяти: 357 КБ против 82 КБ (в 4,4 раза) и 19 аллокаций против одной. Лишнего набегает много: скопировано и выброшено около 260 КБ, втрое больше, чем нужно самому результату. А вот выигрыш по времени сильно зависит от машины: в замере выше это всего 1,8x, потому что десять тысяч итераций append сами по себе стоят дороже, чем перевыделения. На более медленной памяти разрыв заметно больше, но обещать «в разы быстрее» не стоит, лучше аргументируй аллокациями и нагрузкой на GC.

Ловушки

• make([]T, n) вместо make([]T, 0, n) встречается чаще всех. Первый вариант создаёт n нулевых элементов, и последующий append дописывает после них: получаем 2n элементов, из которых первые n нулевые. Ловят на собесе именно на этом.
• Подслайс делит массив с оригиналом. b := a[:2] имеет cap(b) == cap(a), и append(b, x) молча затрёт a[2]. Лечится full slice expression a[:2:2], который обрезает ёмкость и вынуждает append копировать.
• Маленький срез держит большой массив. head := data[:16] от 10-мегабайтного файла удерживает все 10 МБ живыми: GC видит указатель на начало объекта, а не на «использованную часть». Спасает slices.Clone или явное копирование.
• append возвращает новый слайс, и результат обязательно присваивать. Классический баг: слайс передают в функцию, которая делает append, а новое значение не возвращают. Иногда изменения видны (влезло в cap), иногда нет.
• Преаллокация вслепую тоже вредна. make([]T, 0, 1e6) на всякий случай гарантированно аллоцирует в куче (объект больше 32 КБ идёт в large object span мимо кэшей) и раздувает RSS. Ёмкость должна быть обоснованной: len входных данных, LIMIT запроса, размер батча.

// вырастить заранее под известную добавку (Go 1.21)
s = slices.Grow(s, need)   // гарантирует место под need элементов, без лишних копий
s = slices.Clip(s)         // cap = len: append больше не пишет в общий хвост; память не освобождается

strings.Builder

Конкатенация s += x в цикле копирует O(n²) байт: строки неизменяемы, и каждая итерация создаёт новую. Внутри strings.Builder лежит обычный []byte, который растёт по правилам append, а String() отдаёт его без копирования через unsafe.String. Поэтому Builder нельзя копировать после первой записи: он хранит указатель сам на себя (copyCheck) и при копии паникует «strings: illegal use of non-zero Builder copied by value». go vet такую копию не ловит: его проверка copylocks знает только типы с методами Lock/Unlock вроде мьютексов.

var b strings.Builder
b.Grow(len(parts) * 8)          // одна аллокация вместо серии удвоений
for i, p := range parts {
    if i > 0 { b.WriteByte(',') }
    b.WriteString(p)
}
return b.String()               // без копии

// нужен []byte и переиспользование: bytes.Buffer или свой слайс
// склеить фиксированный набор: strings.Join (одна аллокация)

Разница с bytes.Buffer: Buffer умеет читать, а его Reset сохраняет выделенную память, поэтому он ложится в пул; Builder только пишет, его Reset память выбрасывает, зато String() бесплатен. Под «собрать строку и отдать» бери Builder, под «собрать байты, отправить, повторить» подойдёт Buffer или свой []byte.

Переиспользование буферов

// один буфер на весь цикл: cap сохраняется, аллокаций после прогрева ноль
buf := make([]byte, 0, 4096)
for _, r := range reqs {
    buf = buf[:0]
    buf = appendJSON(buf, r)
    w.Write(buf)
}

// Append-семейство вместо Sprintf: пишем в свой буфер, строку не создаём
buf = strconv.AppendInt(buf, id, 10)
buf = fmt.Appendf(buf, " %s\n", name)   // Go 1.19
// и на приёме тоже: json.Decoder/Encoder на потоке вместо Marshal в []byte

sync.Pool

Пул работает как кэш временных объектов, приколоченный к P: у каждого процессора есть приватный слот (доступ без синхронизации вообще) и разделяемая очередь, из которой другие P могут воровать. При сборке мусора пул не очищается сразу: живой набор уезжает в victim cache и умирает только на следующем цикле (Go 1.13), поэтому одна случайная сборка не обнуляет прогрев.

var bufPool = sync.Pool{
    New: func() any { return new(bytes.Buffer) },   // всегда указатель, не значение
}

func handle(w http.ResponseWriter, r *http.Request) {
    b := bufPool.Get().(*bytes.Buffer)
    b.Reset()                       // обязательно: пришёл чужой мусор
    defer func() {
        if b.Cap() <= 64<<10 {      // порог: раздутый буфер обратно не кладём
            bufPool.Put(b)
        }
    }()
    render(b, r)
    w.Write(b.Bytes())
}

• Только указатели. Put(buf) со значением-слайсом кладёт его в any, а упаковка сама по себе аллоцирует, и staticcheck ругается на это кодом SA6002. Кладём *bytes.Buffer или *[]byte.
• Reset обязателен, иначе данные утекают между запросами (в худшем случае в тело ответа попадёт чужой ответ, а это уже уязвимость).
• Порог на размер. Без него один запрос на 200 МБ оставит в пуле 200-мегабайтный буфер, и пока пул в работе, этот буфер ходит по кругу и держит память. Ровно этот приём есть в fmt и net/http.
• Пул не нужен для мелочи. Маленький объект из mcache выделяется за несколько наносекунд; Get/Put плюс промахи кэша могут стоить дороже. Пул окупается на крупных (килобайты), короткоживущих и часто создаваемых объектах.
• После Put объект использовать нельзя: его уже могла забрать другая горутина. Типичная ошибка: defer pool.Put(b) и возврат b.Bytes() наружу.

Конверсии string и []byte

Обычные []byte(s) и string(b) копируют, и это цена неизменяемости строк. Но компилятор знает несколько случаев, где копия не нужна, и убирает её сам. Знать этот список важнее, чем уметь писать unsafe:

m[string(b)]                       // лукап по []byte без аллокации строки
if string(b) == "ping" { }         // сравнение без аллокации
switch string(b) { case "get": }   // тоже
for i, c := range []byte(s) { }    // обход байтов без копии; range string(b) копирует
w.Write([]byte(s))                 // здесь копия будет; io.WriteString(w, s) - нет, если у w есть WriteString

// ручные конверсии без копии (Go 1.20+), только для горячего пути
func b2s(b []byte) string { return unsafe.String(unsafe.SliceData(b), len(b)) }
func s2b(s string) []byte { return unsafe.Slice(unsafe.StringData(s), len(s)) }

Откуда берётся padding

На amd64 и arm64 выравнивание 8 у указателей, int, int64, float64; 4 у int32/float32/rune; 2 у int16; 1 у byte, bool, int8. Смещение поля обязано быть кратно его выравниванию, а размер всей структуры кратен максимальному выравниванию среди полей (чтобы в массиве второй элемент тоже лёг ровно). Отсюда и «хвостовой» padding в конце.

type Bad struct {   // 24 байта
    A bool          // offset 0,  +7 padding
    B int64         // offset 8
    C bool          // offset 16, +3 padding
    D int32         // offset 20
}
type Good struct {  // 16 байт
    B int64         // 0
    D int32         // 8
    A bool          // 12
    C bool          // 13, +2 хвостового padding
}

fmt.Println(unsafe.Sizeof(Bad{}), unsafe.Sizeof(Good{}))   // 24 16
fmt.Println(unsafe.Offsetof(Bad{}.D), unsafe.Alignof(Bad{}))     // 20 8

$ go install golang.org/x/tools/go/analysis/passes/fieldalignment/cmd/fieldalignment@latest
$ fieldalignment ./...
/app/model.go:12:12: Order has size 24 but the optimal size is 16 leading to a waste of 8 bytes (33%)
$ fieldalignment -fix ./...       # переставит поля сам

$ go build -gcflags=-m=2 ./...    # подробно: почему убегает и почему не инлайнится

Когда это вообще имеет значение

Сэкономленные 8 байт на структуре, которых в программе три штуки, ничего не решают. Смысл появляется, когда таких значений миллионы: срез из миллиона Bad занимает 24 МБ против 16 МБ, то есть 8 МБ чистой пустоты и в полтора раза больше памяти, которую обход тянет через кэш. Второй случай: структура летит по сети или в очередь миллионами раз в секунду. В обычном бизнес-коде это микрооптимизация последнего уровня, и ломать логическую группировку полей ради 8 байт на десяти объектах не стоит: размен плохой.

Ловушки

• Пустая структура в конце. Поле типа struct{} последним в структуре получает padding до 1 байта: иначе указатель на него смотрел бы за границу объекта, а такие указатели рантайм не допускает. Если struct{} стоит не последним, размер не меняется.
• Размер не равен «сумме полей». У string 16 байт (указатель + длина), у []T 24, у interface{} и любого интерфейса 16, у map/chan/func 8. Их содержимое лежит отдельно в куче, unsafe.Sizeof его не считает.
• Не путать выравнивание с числом указателей. Иногда важнее не размер, а то, что структура вообще без указателей попадает в noscan-класс и не сканируется сборщиком.

Зачем это нужно

Сам вызов на современном процессоре стоит единицы наносекунд, и ради этого никто бы не старался. Инлайн ценен другим. Тело оказывается в контексте вызывающего, и дальше работают остальные проходы: escape analysis видит, что указатель никуда не утёк, и оставляет объект на стеке; константы сворачиваются; проверки границ (bounds check) удаляются, потому что индекс известен; мёртвые ветки выкидываются. Отсюда и типичная картина: убираешь //go:noinline, и заодно исчезает аллокация, которой в этой функции вроде бы неоткуда взяться.

Бюджет

Стоимость считают по узлам AST: обычная операция стоит 1, вызов другой функции целых 57 (inlineExtraCallCost), а лимит равен 80 (inlineMaxBudget). Выходит, функция с двумя неинлайнящимися вызовами внутри почти наверняка сама в бюджет не влезет. При этом с Go 1.12 работает mid-stack inlining: функцию, которая сама кого-то вызывает, всё равно заинлайнят, если её собственная стоимость (вместе с уже подставленными вызовами) укладывается в бюджет.

Что мешает

• Тело дороже 80 узлов, в выводе function too complex: cost N exceeds budget 80.
• Рекурсия ограничивает глубину: рекурсивную функцию подставят на один уровень, дальше цикл не разворачивается (до Go 1.25 прямая рекурсия запрещала инлайн совсем).
• recover() в теле.
• defer и go в теле (unhandled op DEFER).
• Вызов через интерфейс или через переменную-функцию: цель неизвестна на этапе компиляции, инлайнить нечего. Компилятор умеет девиртуализовать, когда конкретный тип очевиден локально, но в общем случае не справляется.
• Явный запрет //go:noinline: его ставят в бенчмарках, чтобы компилятор не выкинул измеряемый код целиком.
• Функции на ассемблере и часть рантайм-функций.

$ go build -gcflags='-m -m' ./pkg 2>&1 | grep -i inlin
pkg/h.go:10:6: can inline small with cost 6 as: func(int) int { return x * 2 + 1 }
pkg/h.go:18:6: cannot inline big: function too complex: cost 90 exceeds budget 80
pkg/h.go:24:6: cannot inline cleanup: unhandled op DEFER
pkg/h.go:31:6: can inline fact with cost 71 as: func(int) int { if n <= 1 { return 1 }; return n * fact(n - 1) }
pkg/h.go:26:14: inlining call to small
pkg/h.go:35:17: inlining call to fact

$ go build -gcflags='-m -l' ./pkg     # -l выключает инлайн: видно "честные" решения escape analysis
$ go build -gcflags='-l -l -l -l'     # наоборот, агрессивнее (для экспериментов)

Приём: быстрая обёртка плюс холодный хвост

// обёртка укладывается в бюджет и инлайнится в вызывающего
func (c *Cache) Get(k string) (V, bool) {
    if v, ok := c.fast[k]; ok { return v, true }   // горячий путь: пара операций
    return c.getSlow(k)                            // редкий путь вынесен
}

//go:noinline
func (c *Cache) getSlow(k string) (V, bool) {
    // блокировки, промах кэша, поход в БД - сколько угодно кода,
    // он не мешает инлайну Get, потому что живёт в другой функции
}

Ровно так устроены стандартные sync.Mutex.Lock (быстрый CAS плюс lockSlow) и sync.Once.Do (проверка флага плюс doSlow). Это единственная перестройка кода ради инлайна, которую стоит делать сознательно: она заодно и читается лучше, потому что быстрый путь видно сразу.

Как включить

# 1. снять профиль с прода под реальной нагрузкой
$ curl -so cpu.pprof 'http://localhost:6060/debug/pprof/profile?seconds=60'

# 2. положить рядом с main-пакетом под именем default.pgo и закоммитить
$ cp cpu.pprof ./cmd/api/default.pgo

# 3. всё; -pgo=auto включён по умолчанию с Go 1.21
$ go build ./cmd/api
$ go build -pgo=./cpu.pprof ./cmd/api    # явный путь
$ go build -pgo=off ./cmd/api            # выключить (например, для сравнения в бенчмарке)

# профили с нескольких подов лучше слить в один
$ go tool pprof -proto pod1.pprof pod2.pprof pod3.pprof > default.pgo

Что компилятор делает с профилем

• Инлайн горячих вызовов. Для call site, отмеченных в профиле как горячие, бюджет поднимается до 2000 против обычных 80, и «слишком сложные» функции в горячем месте всё-таки подставляются.
• Девиртуализация. Если в профиле видно, что 95% вызовов io.Writer.Write уходят в *os.File, компилятор ставит прямой вызов с проверкой типа и запасной веткой на общий случай. А прямой вызов дальше можно ещё и заинлайнить, так что эффекты складываются.
• Выравнивание горячих циклов. С Go 1.23 на amd64 и 386 заголовки горячих циклов выравниваются в коде, по замерам команды Go это ещё 1–1,5%. Переставлять блоки и функции по профилю, как BOLT, компилятор Go пока не умеет.

Оговорки, за которые ставят плюс

• Профиль должен быть репрезентативным. Снятый с ноутбука на синтетическом тесте профиль оптимизирует не тот код. Нужен прод (или staging с боевым трафиком) под нагрузкой, желательно усреднённый по нескольким инстансам и снятый не в момент деплоя.
• Устаревший профиль не ломает сборку. Если функции переименовали и код переписали, компилятор просто не найдёт совпадений и соберёт как обычно. Хуже не станет, пропадёт только выигрыш. Обычно профиль обновляют отдельной джобой в CI, например еженедельно.
• Итеративная стабильность. Профиль, снятый с PGO-сборки, годится для следующей PGO-сборки: команда Go специально проверяет, что бинарь не «расходится» от поколения к поколению.
• Платишь временем компиляции. С Go 1.23 это единицы процентов (раньше крупные сборки замедлялись вдвое и больше), немного растёт и размер бинарника. Кэш сборки при смене профиля инвалидируется целиком.

Порядок действий

1. Есть ли проблема? Нарушенный SLO, растущая стоимость железа, жалоба. Без цифры задачи нет. «Кажется, тут медленно» ещё не задача.
2. Где именно? Профиль, а не интуиция. По закону Амдала функция, занимающая 2% времени, даже ускоренная вдвое, даст 1%. Это не окупает ни дня работы, ни усложнения кода.
3. Алгоритм и архитектура. Убрать N+1 запрос, добавить индекс, закэшировать, сбатчить, не делать работу вовсе. Здесь лежат разы. Быстрее всего работает код, который не выполняется.
4. Аллокации. Преаллокация, переиспользование буферов, меньше указателей, меньше лишних копий. Здесь лежат десятки процентов, и заодно снижается нагрузка на GC.
5. Микрооптимизации. Порядок полей, инлайн, PGO, unsafe. Здесь лежат единицы процентов.
6. Проверить в проде. Бенчмарк доказывает, что функция стала быстрее; что стало быстрее приложение, доказывает только метрика после выката.

Измерять — значит измерять статистически

$ go test -run=^$ -bench=Encode -benchmem -count=10 > old.txt
# ... правка ...
$ go test -run=^$ -bench=Encode -benchmem -count=10 > new.txt
$ benchstat old.txt new.txt
          │   old.txt    │               new.txt               │
          │    sec/op    │   sec/op     vs base                │
Encode-14   128.65n ± 3%   36.98n ± 1%  -71.25% (p=0.000 n=10)

          │  old.txt   │              new.txt               │
          │    B/op    │   B/op     vs base                 │
Encode-14   80.00 ± 0%   0.00 ± 0%  -100.00% (p=0.000 n=10)

          │  old.txt   │               new.txt               │
          │ allocs/op  │ allocs/op   vs base                 │
Encode-14   5.000 ± 0%   0.000 ± 0%  -100.00% (p=0.000 n=10)

Один прогон «до» и один «после» ничего не доказывают: разброс на ноутбуке легко даёт 10–15%. Нужны -count и benchstat с p-value. Если p > 0.05 или дельта меньше разброса, изменения нет и правку откатываем, даже если она «явно быстрее по логике».

Компромисс с читаемостью

• Оптимизируй только измеренное. Горячего кода в сервисе обычно 1–2%; остальные 98% должны быть максимально скучными и понятными.
• Локализуй сложность. Хитрость прячется за обычным интерфейсом: снаружи Encode(w, v), а внутри пул, буфер и unsafe. Тогда её читает один человек, а не весь отдел.
• Комментарий с цифрами обязателен. Не «так быстрее», а «был Sprintf: 129 нс, 5 аллокаций; стало 37 нс, 0 аллокаций; см. BenchmarkEncode». Без этого следующий человек «упростит» код обратно и будет прав, потому что обоснования нет.
• Бенчмарк остаётся в репозитории. Он защищает от регрессии: без него оптимизация протухнет за пару рефакторингов.
• Ограничивай радиус. unsafe и ручные трюки держи внутри одного пакета, не в API и не в доменных типах.