Сборщик мусора: почему пауза не растёт вместе с кучей, а GOGC ничего не ускоряет

Что здесь на самом деле спрашивают

Вопросов почти всегда три, и они идут по нарастающей:

1. «Какой в Go сборщик?» — проверяют, назовёте ли вы слово «конкурентный», а не только mark and sweep.
2. «Насколько велики паузы и от чего зависят?» — здесь ломается большинство: паузу путают со стоимостью сборки.
3. «Как его настраивать?» — и правильный ответ начинается со слова «обычно никак», а продолжается тем, чем именно платят за каждую ручку.

Спина у темы одна: сборщик Go оптимизирован под задержку, а не под пропускную способность. Он готов потратить больше процессорного времени, лишь бы не останавливать программу надолго. Всё остальное — следствия.

База: что вообще делает сборщик

Прежде чем считать паузы и крутить ручки, стоит назвать задачу. Она короткая и не содержит ни одного термина Go:

Найти объекты, до которых программа больше не может добраться, и вернуть их память.

Слово «не может добраться» здесь ключевое — и оно означает не «не будет использовать», а недостижим по ссылкам:

Сборщик не знает, «нужен» объект или нет. Он знает только, есть ли до него путь от корней. Отсюда сразу два следствия, которые дальше объясняют всё остальное: объект, на который осталась одна забытая ссылка, живёт вечно (это и есть утечка в Go), и работа сборщика пропорциональна числу ЖИВЫХ объектов, а не мусора — мусор он не трогает вовсе.

Обратите внимание, чего в этой постановке нет. Нет ни слова о том, когда сборщик приходит, сколько он работает и останавливает ли программу. Это всё вопросы устройства, и ответы на них разные у разных сборщиков и у разных версий одного.

Этого уже достаточно, чтобы ответить на базовый вопрос собеседования: сборщик ищет недостижимое и возвращает его память, а не следит за тем, что программе «ещё пригодится». Дальше — про то, как он умудряется делать это, почти не останавливая программу, и чем за это платят.

Механизм 1: один цикл сборки целиком

Теперь про то самое устройство — как сборщик обходит достижимое, не отбирая у программы процессор надолго. Цикл состоит из четырёх фаз, и мир останавливается только в двух из них, на короткое время:

▐ подготовка разметки          остановка мира, микросекунды
█████████ конкурентная разметка   программа РАБОТАЕТ, обход идёт параллельно
▐ завершение разметки           остановка мира, микросекунды
█████████ подметание              программа работает, память возвращается

Вот из этой картинки и следует всё, что урок дальше проверяет замером: паузы — это две узкие полоски, а работа — две широкие, и растут они по-разному.

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

Механизм 2: что не растёт вместе с кучей

Главное утверждение темы стоит проверить первым:

Прогон bench/gogc/internals.go печатает:

Куча выросла в шестнадцать раз — пауза не выросла: ×1,22 против ×16. Это и есть то самое свойство, ради которого сборщик Go устроен именно так: он работает одновременно с программой, а останавливает её дважды за цикл и ненадолго — на подготовку разметки и на её завершение.

Отдельно стоит сказать, что именно замерено. PauseNs из MemStats — это время остановки мира, а не длительность цикла. Длительность цикла с кучей как раз растёт, но программа в это время работает.

И оговорка про честность числа: замер шёл на двух ядрах и на одной конкретной версии рантайма, поэтому абсолютные микросекунды не значат ничего. Значение имеет одно — что столбец не растёт. И само это свойство — свойство реализации, а не языка: сборщик менялся от версии к версии и будет меняться дальше, поэтому и его поведение, и число потоков, которым разрешено выполнять код, называют вместе с версией Go, а не как всеобщий закон.

Последняя строка таблицы — не опечатка, а цена деления прибора. Это тот же замер на тех же 16 МБ, сделанный ещё раз: 54 мкс против 39. Расхождение двух повторов ОДНОГО размера оказалось больше, чем разница между 16 и 256 МБ, — а значит, обсуждать по этой таблице направление изменения нельзя вовсе. Она отвечает ровно на один вопрос: масштабируется ли пауза вместе с кучей. Ответ — нет: куча ×16, пауза ×1,22.

Строка эта появилась не сразу, и стоит сказать, зачем. Замер печатал медиану из восемнадцати циклов, и трёх прогонов подряд на этой машине хватило, чтобы на 16 МБ получить 55, 71 и 37 мкс: разброс больше, чем расстояние между строками таблицы. Пока повтора рядом не было, из таких чисел легко читалось направление — и читалось неверно. Теперь выборка поднята до двухсот циклов, повтор печатается рядом, а прогон сам печатает, различима ли разница строк его собственным прибором.

До медианы в этом замере печатался максимум, и он давал на 16 МБ 755 мкс против 34 на 256 — то есть таблицу, из которой следовало бы, что пауза с ростом кучи падает. Причина оказалась не в сборщике: максимум из двенадцати измерений на двухъядерной машине — это худший чужой процесс. Медиана отвечает на заданный вопрос, максимум — на другой.

А что тогда растёт? Работа разметки: чем больше живых объектов, тем больше указателей надо обойти. Это видно в доле процессорного времени, не в паузе. И путать их дорого — программу начинают оптимизировать под величину, которая не менялась.

Механизм 3: GOGC — не ускоритель, а ручка обмена

Определение в руководстве дано формулой, и это важно: в нём нет слова «память», есть отношение.

Прогон подтверждает арифметику и показывает цену:

Читать таблицу надо по двум столбцам сразу. Работа во всех строках одна и та же — двести тысяч выделений по килобайту при шестнадцати мегабайтах живых данных. Циклов при GOGC=400 в восемь раз меньше, чем при 50, — и пик кучи втрое выше.

Это не ускорение, а перенос цены со времени на память. Отсюда и правило выбора: GOGC поднимают, когда памяти в избытке, а профиль показывает время в сборке; опускают — когда память в обрез. «Хорошего значения по умолчанию» тут нет; есть только то, чего в системе больше.

И то, чего у GOGC нет: потолка. Цель считается от живых данных, а значит, растут живые — растёт и цель. Программа с растущим кешем съест всю память, ни разу не нарушив настройку.

Механизм 4: GOMEMLIMIT — потолок, и почему он мягкий

Замер показывает разницу прямо:

Вторая строка — то самое отсутствие потолка. Четвёртая — что добавляет GOMEMLIMIT: цель перестаёт подниматься выше предела, и сборка начинает идти чаще, удерживая программу под ним.

Слово «мягкий» в документации стоит не для мягкости:

Если живые данные сами перерастут предел, рантайм не убьёт программу — он будет собирать почти непрерывно. Руководство называет это смертельной спиралью. Симптом характерный и обманчивый: процесс жив, метрики памяти в норме, полезной работы нет.

Отсюда две практические рекомендации, которые и хотят услышать. Ставить предел ниже настоящей границы контейнера — иначе вместо честного OOM получится живой по метрикам процесс без работы. И не ставить GOMEMLIMIT вместо GOGC: они не заменяют друг друга. GOGC управляет обычным режимом, GOMEMLIMIT страхует край.

Глубже: почему сборщик такой, какой есть

Три решения, о которых спрашивают на позициях повыше.

Непоколенный. Гипотеза поколений («большинство объектов умирает молодыми») в Go выполняется — но её выгоду уже собрал escape-анализ: короткоживущие объекты в основном не доходят до кучи вообще, они остаются на стеке. Молодое поколение оказалось бы наполовину пустым, а барьеры для него стоили бы на каждой записи указателя.

Неперемещающий. Объекты не двигаются, поэтому адреса стабильны — а это делает дешёвым взаимодействие с C и позволяет существовать unsafe.Pointer. Цена — фрагментация, которую вместо уплотнения решает аллокатор с классами размеров.

Конкурентный, с барьером записи. Разметка идёт одновременно с программой, и чтобы программа не спрятала от неё объект, каждая запись указателя во время разметки проходит через барьер. Это и есть постоянный налог сборщика на процессорное время — тот самый обмен «больше ЦП, меньше пауза».

И то, что путают с утечкой. Сборщик не возвращает освобождённую память ОС сразу: страницы возвращаются постепенно, фоновым процессом.

Четыре величины, которые смешивают в одну и потом спорят о показаниях:

RSS больше HeapAlloc всегда, и это нормально: в него входят взятые, но ещё не возвращённые страницы, стеки горутин, метаданные аллокатора и код. Утечка выглядит иначе — растёт HeapAlloc после полной сборки.

И связь с предыдущим уроком. Меньше выделений в куче — меньше живых объектов — меньше работы разметке. Но правилом оптимизации это не является: escape-анализ уже отсеял большую часть короткоживущего, а переписывание кода ради стека почти всегда делает его длиннее и хрупче. Сначала профиль, потом решение — тот же порядок, что и в уроке про escape-анализ.

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

Короткий ответ: сборщик возвращает память объектов, до которых от корней больше нет пути, и делает это одновременно с программой — останавливая её дважды за цикл и ненадолго. Поэтому пауза короткая и от размера кучи не зависит: у меня 16 и 256 мегабайт живых данных дали 39 и 48 микросекунд — рост в 1,22 раза на шестнадцатикратной куче. Растёт при этом не пауза, а работа разметки — доля процессорного времени, и путают с паузой именно её.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

Назовите свойства, а не аббревиатуру — и с привязкой к версии. «В нынешних версиях Go это конкурентный трёхцветный mark-and-sweep, неперемещающий и непоколенный. Оптимизирован под задержку: готов тратить больше ЦП, лишь бы не останавливать программу. Язык при этом ничего из перечисленного не обещает — это свойства реализации».

Про GOGC скажите «обмен». «Он задаёт, во сколько раз куче позволено вырасти сверх живых данных. GOGC=400 дал мне вчетверо меньше циклов и в два с половиной раза больший пик кучи. Сборка от этого не дешевеет».

Назовите, чего у GOGC нет. «Потолка. Цель считается от живых данных, поэтому растущий кеш съест память, не нарушив настройки. Потолок — это GOMEMLIMIT, и он мягкий».

И закончите тем, чего не надо делать. «Крутить ручки без профиля не стоит: сборщик на обычной нагрузке стоит единицы процентов ЦП. Дешевле убрать выделения, чем настраивать их уборку».

И одна оговорка, на которой легко переусердствовать: числа отсюда — не константы языка. Микросекунды пауз сняты на конкретной версии рантайма и на двух исполняющих потоках, и на другой машине они будут другими. Точная формулировка звучит так: запоминают не значения, а то, какая величина от чего зависит — пауза от размера кучи не зависит, работа разметки зависит, а цена GOGC платится памятью.

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

fmt.Println(debug.SetGCPercent(100))

fmt.Println(round(goalOverLive(100)))
fmt.Println(round(goalOverLive(400)))

fmt.Println(cyclesFor(-1))

debug.SetGCPercent(-1)
var a runtime.MemStats
runtime.ReadMemStats(&a)
runtime.GC()
runtime.GC()
var b runtime.MemStats
runtime.ReadMemStats(&b)
fmt.Println(b.NumGC - a.NumGC)

100
2
5
0
2

0
1
4
0
2

100
1
4
0
0

100
2
5
1
2

Проверка знаний