Механика и тюнинг GC: трёхцветный mark-sweep, пейсер, GOGC и GOMEMLIMIT без мифов

Трёхцветный mark-sweep, работающий параллельно с вашим кодом

Сборщик Go — конкурентный mark-sweep: он находит живые объекты и освобождает остальное, причём почти вся работа идёт, пока ваши горутины продолжают выполняться. Фаза маркировки описывается трёхцветной моделью: каждый объект белый (ещё не увиден — презумпция мусора), серый (увиден, содержимое не просканировано) или чёрный (увиден и полностью просканирован). Маркировка стартует с корней — глобальных переменных и стека каждой горутины, — красит их в серый и затем вычерпывает серое множество: просканировать указательные поля объекта, посереть всё, на что они ссылаются, зачернить сам объект. Когда серых не осталось, всё достижимое — чёрное, а всё ещё белое — мусор. Sweep возвращает белые спаны аллокатору лениво, амортизированно в последующие аллокации.

Цикл обрамляют две stop-the-world паузы, обе обычно короче миллисекунды, как правило десятки–сотни микросекунд: одна запускает маркировку (включить барьер записи на каждом P), вторая её завершает (убедиться, что серой работы не осталось). Этот заголовочный показатель честный — но это не цена GC. Цена конкурентна: ~25% GOMAXPROCS зарезервированы под фоновую маркировку во время цикла, плюс mark assist — горутину, аллоцирующую быстрее, чем фоновые воркеры успевают сканировать, мобилизуют маркировать пропорционально её аллокациям. Субмиллисекундные паузы не бесплатны; это паузы, конвертированные в налог на пропускную способность.

Когда встречаете описание GC как «low-pause», помните: пауза не исчезла — она просто сменила форму.

Барьер записи: почему конкурентная маркировка не теряет объекты

У маркировки, идущей одновременно с мутациями, есть классическая опасность: код может скопировать указатель на белый объект в уже чёрный объект и стереть единственную другую ссылку. Сборщик, закончивший с чёрным объектом, никогда к нему не вернётся — белый объект сметут, хотя он достижим. Go закрывает дыру барьером записи: во время маркировки каждая запись указателя проходит через маленький хук рантайма. Гибридный барьер Go (с 1.8) затеняет старый затираемый указатель (deletion-стиль, Yuasa), а для записей в стек — и новый (insertion-стиль, Дейкстра) — комбинация гарантирует, что ни один достижимый объект не останется белым, и именно она избавила от повторного сканирования стеков горутин на завершении, ограничив финальную паузу. Цена: каждая запись указателя в программе чуть дороже, пока идёт цикл. Структуры, плотные по указателям (связные списки, деревья мелких узлов, map[string]*Thing), облагаются дважды — больше работы барьеру, больше погони маркировщику. Это механический аргумент за value-ориентированный дизайн: []Item лучше []*Item не из идеологии, а из экономики барьера и сканирования.

Пейсер, GOGC и GOMEMLIMIT — две ручки, два режима

Когда стартует цикл? Пейсер стремится закончить маркировку ровно к моменту, когда куча достигнет цели: примерно живая куча × (1 + GOGC/100) (плюс стеки и глобальные в современной формуле). С дефолтным GOGC=100 сервис с 1 GiB живых данных запускает GC около 2 GiB — потолок памяти примерно вдвое больше живой кучи. Поднимите GOGC (200, 400) — циклы станут реже: меньше CPU на GC, больше RAM; опустите — обмен в другую сторону. Пейсер самокорректируется по обратной связи от прошлых циклов и мобилизует аллоцирующие горутины через mark assist, когда они его обгоняют, — поэтому у аллокационно-тяжёлого кода латентность деградирует раньше, чем память начинает пугать.

GOMEMLIMIT (Go 1.19+) — второй режим: мягкий лимит на всю память рантайма (куча, стеки, структуры рантайма — но не аллокации C). По мере приближения к нему GC работает агрессивнее, чем диктовал бы один GOGC, пытаясь удержаться ниже. Используйте его, когда настоящее ограничение — контейнер: GOMEMLIMIT на ~90–95% лимита пода превращает «OOMKilled в два ночи» в «больше GC под давлением». Режим отказа — пролог: живая куча у самого лимита не оставляет GC ничего освобождать, и он работает непрерывно. Рантайм ограничивает GC половиной CPU, гарантируя прогресс, — осознанное проектное решение, предотвращающее полный клин, но всё равно означающее, что сервис может законно тратить половину процессора на маркировку. Оставляйте запас: при живой куче 1,3 GiB лимит 1,4 GiB — ловушка; 2 GiB — бюджет.

// Честное наблюдение за GC в проде:
// GODEBUG=gctrace=1 печатает строку на каждый цикл в stderr —
// gc 412 @1572.337s 2%: 0.06+312+0.04 ms clock, ...,
//        1290->1310->1190 MB, 1400 MB goal, ...
// читается так: 2% CPU на GC с момента старта; 0.06 и 0.04 мс STW вокруг
// 312 мс конкурентной маркировки; куча 1290 MB на старте, живых 1190 после;
// цель 1400 — живое составляет 85% цели: сервис у края спирали.

debug.SetGCPercent(200)                    // GOGC, в рантайме
debug.SetMemoryLimit(1900 << 20)           // GOMEMLIMIT, байты
var m runtime.MemStats
runtime.ReadMemStats(&m)                   // m.NumGC, m.PauseNs, m.GCCPUFraction

Мифы: нет компактизации, нет поколений — и почему

Две вещи, которые инженеры «знают» про GC и которые сборщик Go сознательно не делает. Нет компактизации: объекты никогда не переезжают после аллокации. Фрагментацию вместо этого сдерживает аллокатор с размер-классами (~70 классов; объект на 18 байт живёт в слоте на 24 байта, в спане, выделенном под этот класс, — внутренние потери ограничены в худшем случае). Неперемещающий дизайн покупает дешёвый и стабильный интероп (указатели, отданные в syscall или cgo, остаются валидными) и отсутствие фазы копирования, конкурирующей за пропускную способность памяти. Нет поколений: нет «ясель»; каждый цикл сканирует весь живой набор. Генерационная гипотеза — большинство объектов умирает молодыми — в Go в значительной мере обработана заранее escape-анализом: самые молодые и короткоживущие значения вообще не доходят до кучи, бесплатно умирая на стеках. Команда Go прототипировала генерационный сборщик и обнаружила, что выигрыш не оправдывает цену: поколениям нужен ещё более дорогой барьер записи для отслеживания указателей из старого в молодое, что усложняет конкурентный дизайн, удерживающий паузы под миллисекундой. Это компромиссы, а не пробелы — но они означают, что GC Go вознаграждает маленький живой набор и низкую скорость аллокаций и не даёт «ясель», за которыми можно спрятать дизайн с высоким churn.