Цвета

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

Сам цвет не поле объекта. Физически есть биты маркировки в метаданных спана (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». Так в тестах и находят утечки ресурсов.