Верно ли, что сборка мусора в Go полностью останавливает выполнение пользовательских горутин?
Нет. Сборщик мусора Go в основном работает конкурентно с пользовательскими горутинами, поэтому полный останов процесса на весь цикл сборки не происходит. Однако в каждом цикле есть короткие фазы stop-the-world — прежде всего завершение подготовки к маркировке и завершение маркировки; их длительность влияет на задержки.
Полностью последовательный сборщик мусора проще реализовать, но на больших кучах он надолго останавливает приложение. Для серверных программ с требованиями к задержкам Go использует конкурентную маркировку: значительная часть работы выполняется параллельно с приложением, пока оно продолжает изменять граф объектов.
Такой подход решает проблему длинных глобальных пауз, но не устраняет стоимость GC. За снижение пауз приходится платить фоновой нагрузкой на CPU, работой барьеров записи и возможным участием прикладных горутин в маркировке.
Неверно считать, что конкурентный GC делает паузы невозможными. Если приложение чувствительно к задержкам, даже короткая остановка всех пользовательских горутин может проявиться как всплеск latency, особенно при высокой нагрузке или небольшом запасе времени у запросов.
Обратная ошибка также опасна: попытка любой ценой исключить STW, например постоянным ручным запуском GC или чрезмерным уменьшением целевого размера кучи, может увеличить частоту сборок, CPU-затраты и время ответа. Оценивать нужно не только длительность паузы, но и частоту циклов, фоновую работу GC и задержки на хвостах распределения.
Цикл GC включает конкурентную маркировку достижимых объектов. В этот момент пользовательские горутины продолжают работать, но изменения ссылок отслеживаются write barrier, чтобы сборщик не пропустил объект, который стал достижимым во время маркировки.
Перед началом маркировки runtime выполняет короткую фазу stop-the-world, подготавливая состояние сборки и согласуя работу с горутинами. После конкурентной маркировки выполняется другая STW-фаза — mark termination: сборщик завершает маркировку, обрабатывает оставшиеся изменения и фиксирует итоговый набор живых объектов.
Затем очистка памяти в основном выполняется конкурентно. Поэтому утверждение «GC останавливает приложение» слишком грубое: правильнее сказать, что GC сочетает конкурентные фазы с короткими глобальными остановками. Их фактическая длительность зависит от размера и структуры корней, состояния планировщика, нагрузки и особенностей конкретного цикла.
Кроме STW-пауз, приложение может ощущать GC через GC assist. При высокой скорости аллокаций runtime способен заставить аллоцирующую горутину выполнить часть маркировки, чтобы темп создания объектов не опережал работу сборщика. В результате формальная STW-пауза может быть небольшой, но CPU-время отдельных запросов всё равно вырастет.
Для диагностики следует сопоставлять несколько сигналов: длительность STW-пауз, CPU GC, частоту циклов, объём аллокаций и задержки запросов. Изменение GOGC, уменьшение лишних аллокаций и настройка размера рабочей кучи могут улучшить разные показатели, поэтому универсального параметра для всех сервисов нет.
В API-сервисе средняя задержка запросов почти не изменилась, но p99 периодически вырос. Команда сначала решила, что причиной являются длинные остановки GC, однако профиль показал короткие STW-фазы и высокий объём конкурентной маркировки.
Рассматривались три варианта:
Выбран третий вариант: сначала устранили лишние промежуточные объекты в горячем пути, затем проверили STW, CPU GC и p99 на нагрузочном тесте. Ожидаемый результат — меньше циклов и GC assist при сохранении приемлемого объёма памяти; конкретный эффект нужно подтверждать измерениями, а не выводить только из факта наличия пауз.
Обычно к ним относят короткое завершение подготовки к маркировке и mark termination. Основная маркировка и последующая очистка выполняются конкурентно, поэтому продолжительность полного GC-цикла не равна длительности STW-паузы.
Точный профиль фаз зависит от версии runtime и состояния системы, поэтому на собеседовании важно говорить о принципе, а не обещать фиксированный набор или фиксированную длительность пауз.
Во время STW запросы не продвигаются, и задержка накапливается у всех затронутых горутин. Если пауза совпала с уже загруженным периодом, восстановление очереди может занять больше времени, чем сама остановка.
Кроме того, p99 отражает редкие события, поэтому средняя задержка может остаться почти прежней, хотя хвост распределения заметно ухудшится. Анализировать нужно временные ряды и высокие перцентили, а не только среднее значение.
Нет. GC может потреблять CPU конкурентно, а при высокой скорости аллокаций прикладные горутины могут выполнять GC assist. Это увеличивает время обработки операций без глобальной остановки всех горутин.
Поэтому диагностика должна включать не только события STW, но и CPU-профиль, скорость аллокаций, частоту циклов и показатели assist. Малые паузы сами по себе не означают низкую общую стоимость сборки.