Golang | Garbage collector

Сборщик мусора в Go: Глубокое Погружение в Освобождение Памяти

Golang
(Go) с момента своего появления завоевал популярность благодаря
простоте, производительности и мощной конкурентной модели. Одним из
ключевых компонентов, обеспечивающих эту производительность и
избавляющих разработчика от рутины, является Сборщик Мусора (Garbage Collector, GC).
В этой статье мы досконально разберем, как работает GC в Go, эволюцию
его алгоритмов, как им управлять и на что обращать внимание при
разработке.

Управление памятью — одна из фундаментальных задач системного программирования. От того, насколько эффективно и безопасно приложение распоряжается выделенной памятью, зависит его производительность, стабильность и устойчивость к атакам. В языках с ручным управлением памятью, таких как C и C++, вся ответственность за выделение (malloc, new) и освобождение (free, delete) ресурсов ложится на разработчика. Такой подход даёт максимальный контроль, но одновременно открывает двери для целого класса трудноуловимых ошибок:

• Утечки памяти
  (memory leaks) — когда динамически выделенная память перестаёт быть
  нужной, но не возвращается системе. Постепенно потребление памяти
  растёт, и рано или поздно приложение падает с out-of-memory.
• Висячие указатели
  (dangling pointers) — обращение к области памяти, которая уже была
  освобождена. Это приводит к неопределённому поведению: программа может
  работать, выдавать случайные результаты или аварийно завершаться в самый
  неподходящий момент.
• Двойное освобождение (double free) — попытка вызвать free для уже освобождённого блока, что часто ведёт к повреждению кучи и трудно диагностируемым сбоям.

Сборщик мусора (Garbage Collector, GC) решает эти проблемы автоматически. Он отслеживает все объекты, созданные программой, и определяет, какие из
них больше не используются (не достижимы из корневых точек — глобальных
переменных, локальных переменных в стеках, регистров процессора).
Ненужные объекты уничтожаются, а занимаемая ими память возвращается в
общий пул для последующих выделений.

В языке Go сборщик мусора встроен в среду исполнения (runtime) с самого
начала и является неотъемлемой частью экосистемы. Разработчику не нужно
вызывать free или delete — достаточно создать объект с помощью &, new или make, и GC позаботится обо всём остальном. Однако за кажущейся простотой
скрывается сложный и постоянно совершенствующийся механизм, который
прошёл долгий путь эволюции — от простого «останавливающего мир»
(stop-the-world) алгоритма до одного из самых быстрых конкурентных
сборщиков в индустрии. В этой статье мы подробно разберём, как устроен
GC в Go, как он менялся от версии к версии, как его настраивать и
мониторить, и как писать код, дружественный к сборщику мусора.

Эволюция сборщика мусора в Go

История GC в Go — это история непрерывного стремления к снижению задержек (latency) при сохранении высокой пропускной способности (throughput). Каждый крупный релиз приносил улучшения, которые делали сборщик всё более незаметным для работающего приложения.

Go 1.0 – 1.2: простой «Stop‑the‑World» Mark‑and‑Sweep

Первые версии Go использовали классический алгоритм «пометить и подмести»
(mark-and-sweep), выполняемый полностью с остановкой всех горутин (STW).
Фаза маркировки обходила граф объектов от корней и помечала все
достижимые объекты как живые. Фаза очистки освобождала память
непомеченных объектов.

Основной недостаток такого подхода — длительные паузы, пропорциональные размеру кучи. В интерактивных сервисах, где важна каждая миллисекунда ответа, такие паузы были неприемлемы. Тем не менее, для первых версий Go,
ориентированных в большей степени на системное программирование и
утилиты, это было терпимо.

Go 1.3 – 1.4: точный сборщик и сокращение STW

В версиях 1.3 и 1.4 был реализован точный сборщик мусора
(precise GC). До этого сборщик был консервативным: он не всегда мог
отличить указатель от обычного числа, поэтому иногда оставлял в живых
объекты, на которые случайно указывало значение, похожее на адрес.
Точный сборщик благодаря улучшенной информации о типах (в том числе о
расположении указателей в структурах) научился безошибочно
идентифицировать указатели. Это позволило уменьшить объём сканируемой
памяти и сократить паузы, хотя STW по-прежнему сохранялся.

Go 1.5: революция — конкурентная маркировка и очистка

Релиз Go 1.5 стал переломным моментом. Разработчики runtime полностью переработали GC, сделав его конкурентным
(concurrent). Основная идея заключалась в том, чтобы выполнять большую
часть работы параллельно с пользовательским кодом, сводя к минимуму
остановки мира.

Сборщик стал трёхфазным:

1. Mark Setup (STW) — очень короткая пауза для подготовки к маркировке, включения так называемого «барьера записи».
2. Concurrent Mark
   — основная маркировка выполняется фоновыми горутинами, используя до 25%
   доступных ядер CPU. В это время программа продолжает работать, а барьер
   записи отслеживает изменения указателей, чтобы не потерять живые
   объекты.
3. Mark Termination (STW) — финальная короткая пауза, завершающая маркировку и гарантирующая, что все живые объекты помечены.
4. Concurrent Sweep — очистка памяти от мусора происходит параллельно с работой приложения, постепенно, не создавая длительных блокировок.

Благодаря этим изменениям паузы GC сократились с сотен миллисекунд до единиц миллисекунд, а впоследствии — до субмиллисекундного диапазона.

Go 1.8 и далее: субмиллисекундные паузы

В Go 1.8 были проведены дополнительные оптимизации, особенно в фазе Mark
Termination, что позволило снизить паузы до значений менее одной
миллисекунды в типичных приложениях. Инженеры Google продолжали
совершенствовать планировщик и алгоритмы обхода объектов, добиваясь
предсказуемости даже при больших объёмах живых данных.

Go 1.12+: гибридный барьер записи (Hybrid Write Barrier)

Одним из ключевых улучшений стало внедрение гибридного барьера записи,
который позволил практически полностью исключить необходимость остановки
мира на этапе завершения маркировки в большинстве сценариев. Барьер —
это небольшой фрагмент кода, который выполняется при каждом изменении
указателя в куче. Он уведомляет GC о том, что ссылка изменилась, и
объект, на который теперь указывают, должен быть учтён при маркировке.
Гибридный подход объединил преимущества двух классических барьеров
(Дейкстры и Стила) и позволил ещё больше снизить задержки.

Современное состояние (Go 1.22+)

На сегодняшний день GC в Go — это зрелая, высокопроизводительная система,
которая из коробки обеспечивает отличные характеристики для подавляющего
большинства приложений. Паузы стабильно находятся на уровне микросекунд
и единиц миллисекунд даже при многогигабайтных кучах, что делает Go
привлекательным выбором для разработки низколатентных сервисов,
API-шлюзов, облачных приложений и микросервисов.

Как работает современный сборщик мусора в Go

Давайте разберём устройство GC в Go начиная с версии 1.8 и выше. Это поможет понять, почему сборщик такой быстрый и как его поведение влияет на производительность вашего кода.

Триггеры запуска GC

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

• Пороговое значение на основе роста кучи.
  Главный триггер — достижение размером кучи определённого порога
  относительно объёма живой памяти после предыдущей сборки. Коэффициент
  задаётся переменной окружения GOGC (по умолчанию 100). Если GOGC=100, то GC стартует, когда размер кучи становится в два раза больше объёма живой памяти после предыдущего цикла. Чем меньше GOGC, тем чаще запускается GC и тем меньше пиковое потребление памяти, но выше нагрузка на CPU.
• Таймаут.
  Если сборка не запускалась более двух минут, runtime инициирует её
  принудительно, даже если порог не достигнут. Это защита от ситуаций,
  когда программа почти не выделяет память, но долго работает, и нужно
  очистить потенциально устаревшие объекты.
• Ручной вызов. Функция runtime.GC()
  позволяет вручную запустить полный цикл сборки. Использовать её в
  production-коде не рекомендуется из-за непредсказуемого влияния на
  производительность, но она полезна для тестирования и профилирования.

Структуры данных и организация памяти

Прежде чем углубляться в фазы GC, нужно понять, как Go организует память. Куча разбита на span'ы
— непрерывные области фиксированного размера (обычно 8 КБ или больше),
которые делятся на объекты одинакового размера. Это упрощает управление и
уменьшает фрагментацию. Кроме того, span'ы хранят метаинформацию,
необходимую сборщику: биты пометок, информацию о том, содержит ли объект
указатели и т.д.

Корни (roots) — это отправные точки обхода графа объектов:

• Глобальные переменные.
• Стеки всех горутин (локальные переменные, аргументы функций).
• Регистры процессора (через информацию от компилятора).

Трёхцветная маркировка (Tri‑color Marking)

Современные
сборщики мусора часто описываются через модель трёх цветов, которая
помогает понять, как конкурентная маркировка сохраняет согласованность
данных.

• Белые объекты — потенциальный мусор. В начале цикла все объекты считаются белыми.
• Серые объекты — объекты, которые уже помечены как живые, но ещё не просканированы на предмет ссылок на другие объекты.
• Чёрные объекты — живые объекты, которые полностью просканированы (все их поля-указатели уже обработаны).

Алгоритм работает так:

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

Проблема при конкурентной работе в том, что пока GC обходит граф, программа может изменять ссылки. Например, программа может прочитать указатель из чёрного объекта на белый и записать его в другой чёрный объект. Если GC уже просканировал первый чёрный объект, он не заметит новую ссылку, и белый объект будет ошибочно собран как мусор, хотя стал живым. Для предотвращения этого используется барьер записи.

Барьер записи (Write Barrier)

Барьер записи — это небольшой код, вставляемый компилятором при каждом присваивании указателя в куче. Когда программа выполняет *ptr = newPtr,
барьер уведомляет GC о том, что указатель изменился. В Go используется
гибридный барьер, который работает по принципу «ослабления инварианта»:
он гарантирует, что в любой момент времени не существует чёрного
объекта, указывающего на белый. Достигается это тем, что при записи
указателя из чёрного объекта в белый, белый объект немедленно становится
серым (или, в зависимости от реализации, добавляется в специальный
буфер для последующей обработки). Таким образом, GC не пропускает новые
связи.

Барьер активен только во время фазы конкурентной маркировки. На время коротких STW-пауз он отключается.

Подробный разбор фаз цикла GC

Рассмотрим каждую фазу в деталях.

1. Sweep Termination (STW)

Цель: завершить очистку, оставшуюся от предыдущего цикла GC.

• Останавливаются все горутины (STW).
• Если после предыдущего цикла остались span'ы, ожидающие очистки, они очищаются сейчас.
• Очистка заключается в обходе всех span'ов и освобождении памяти, занятой объектами, помеченными как мусор.
• После завершения очистки программа возобновляет работу.

2. Mark Phase

Mark Setup (STW) — короткая (обычно микросекунды) пауза:

• Включается барьер записи.
• Сбрасываются вспомогательные структуры для нового цикла.
• Все объекты снова считаются белыми (логически; фактически используются биты пометок).

Concurrent Mark — основная работа:

• Запускаются фоновые горутины маркировки (их количество пропорционально GOMAXPROCS).
• Они обходят граф объектов от корней, используя трёхцветный алгоритм.
• Каждая фоновая горутина может обрабатывать серые объекты и делать их чёрными, добавляя найденные ссылки в очередь серых.
• Параллельно основная программа продолжает выполняться. При каждом изменении указателя срабатывает барьер записи, который добавляет целевой объект в набор серых (если он белый), предотвращая его потерю.
• Фоновые горутины могут потреблять до 25% процессорного времени (настраивается runtime), остальное время отдаётся пользовательскому коду.
• Если во время маркировки пользовательская горутина пытается выделить память, а очередь серых пуста, она может помочь в маркировке (mark assist),
  чтобы ускорить процесс и не дать куче вырасти слишком сильно.

Mark Termination (STW) — финальная короткая пауза:

• Все горутины останавливаются.
• Завершается
  маркировка: повторно сканируются стеки горутин, которые могли
  измениться во время конкурентной фазы, и обрабатываются остатки
  барьерных буферов.
• Убеждаемся, что все живые объекты помечены.
• Отключается барьер записи.
• По окончании этой фазы все непомеченные объекты считаются мусором.

3. Sweep Phase (Concurrent)

• После завершения маркировки начинается фаза очистки, которая выполняется конкурентно с основной программой.
• Очистка происходит при необходимости: например, когда программа выделяет память, соответствующий span очищается «на лету».
• Это позволяет распределить нагрузку от очистки во времени и избежать длительных простоев.
• Очищенные span'ы возвращаются в общий пул свободной памяти и могут быть использованы для новых выделений.

Ключевые характеристики сборщика мусора Go

Понимание архитектурных решений помогает предсказывать поведение GC в различных сценариях.

Не‑сжимающий (Non‑compacting)

В отличие от сборщиков в JVM (HotSpot) или .NET, GC в Go не перемещает
объекты в памяти для устранения фрагментации. Он работает по принципу
«mark‑sweep», а не «mark‑compact». Это упрощает реализацию и устраняет
необходимость обновлять все ссылки на перемещённые объекты, что
потребовало бы дополнительных остановок. Недостаток — потенциальная
фрагментация кучи. Однако аллокатор Go использует технику разделения
памяти на span'ы фиксированного размера, что минимизирует фрагментацию:
объекты одного размера группируются вместе, и освободившееся место сразу
доступно для новых объектов того же размера.

Не‑поколенный (Non‑generational)

Классические сборщики (Java, C#) делят кучу на поколения (молодое, старое) в расчёте на то, что большинство объектов умирают молодыми. Поколенные сборщики позволяют быстрее обрабатывать короткоживущие объекты, не сканируя всю кучу. Go отказался от поколений в пользу низких задержек и простоты. Вместо этого он полагается на быстрый конкурентный обход всей кучи, который, благодаря оптимизациям, выполняется достаточно быстро даже при больших размерах. Такой подход даёт более предсказуемые паузы, так как
время сборки пропорционально размеру живой кучи, а не объёму мусора.

Конкурентный (Concurrent)

Это главная особенность GC Go. Благодаря выполнению маркировки и очистки
параллельно с пользовательским кодом, паузы STW сводятся к минимуму. Это
делает Go идеальным для систем, чувствительных к задержкам.

Управление и мониторинг GC

Хотя GC в Go работает автоматически, у разработчика есть инструменты для наблюдения и тонкой настройки.

Переменные окружения и GODEBUG

• GODEBUG=gctrace=1 — включает вывод подробной информации о каждом цикле GC в стандартный поток ошибок.textgc 4 @0.123s 0%: 0.015+0.30+0.015 ms clock, 0.12+0.15/0.50/0.75+0.12 ms cpu, 4->5->2 MB, 5 MB goal, 8 P
  Расшифровка:
  gc 4 — номер цикла GC.
  @0.123s — время от старта программы.
  0% — доля процессорного времени, потраченная на GC с момента старта.
  0.015+0.30+0.015 ms clock — длительности этапов: STW Mark Setup + Concurrent Mark + STW Mark Termination (настенное время).
  0.12+0.15/0.50/0.75+0.12 ms cpu — использование CPU: вспомогательные детали по фазам.
  4->5->2 MB — размер кучи до GC, размер кучи после маркировки (до очистки), размер живой кучи после GC.
  5 MB goal — целевой размер кучи для следующего цикла (текущая живая куча * (1 + GOGC/100)).
  8 P — количество процессоров (логических ядер).
• GOGC — процентное отношение, определяющее частоту запуска GC. По умолчанию 100. Установка GOGC=off отключает сборку мусора (крайне опасно для долго работающих программ). GOGC=50
  заставляет GC запускаться при росте кучи на 50% от живой памяти, что
  уменьшает пиковое потребление, но увеличивает нагрузку на CPU.

Пакеты runtime и runtime/debug

• runtime.ReadMemStats(&memStats) — заполняет структуру MemStats
  детальной информацией о состоянии памяти: сколько выделено, сколько
  используется, сколько в куче, сколько в стеках, количество сборок и т.д.
• debug.FreeOSMemory()
  — принудительно возвращает неиспользуемую память операционной системе.
  Может вызвать дополнительную работу GC и паузы, поэтому использовать с
  осторожностью.
• debug.SetGCPercent(percent) — программный аналог переменной GOGC, позволяет динамически менять параметр.

Профилирование с pprof

Встроенный профайлер pprof даёт возможность анализировать использование памяти и аллокации. Для этого достаточно подключить пакет net/http/pprof и запустить HTTP-сервер. Затем можно получить профиль кучи:

go tool pprof http://localhost:8080/debug/pprof/heap

Интерактивные команды top, list, web помогут найти места, где создаётся больше всего объектов, и оптимизировать их.

Практические советы по снижению нагрузки на GC

Даже
самый быстрый сборщик мусора не поможет, если программа генерирует
огромное количество мусора. Вот несколько рекомендаций, как писать код,
дружественный к GC.

Уменьшайте количество указателей

GC
сканирует объекты, обходя все поля-указатели. Если структура не
содержит указателей (состоит только из примитивных типов), её
сканировать не нужно. Рассмотрим пример:

type Node struct {
Value int
Next *Node
}

Здесь Next — указатель, и каждый объект Node будет просканирован. Если мы можем хранить данные в массиве индексов или использовать плоские структуры, нагрузка снижается.

Плохо (много указателей):

type Item struct {
Data []byte
}

Лучше (если позволяет логика):

type Item struct {
Data [64]byte // фиксированный массив без указателей
}

Но не всегда это возможно; главное — осознавать цену.

Используйте пулы объектов (sync.Pool)

sync.Pool
позволяет переиспользовать временные объекты вместо того, чтобы каждый
раз выделять новые. Это особенно эффективно для часто создаваемых и
короткоживущих объектов, например, буферов для сетевых операций.

var pool = sync.Pool{
New: func() interface{} {
return make([]byte, 4096)
},
}

func handleRequest() {
buf := pool.Get().([]byte)
defer pool.Put(buf)
// использовать buf
}

Важно помнить, что объекты в пуле могут быть в любой момент собраны GC, если
на них нет других ссылок, поэтому пул не гарантирует, что объект
останется живым надолго, но снижает частоту аллокаций.

Избегайте удержания указателей на короткоживущие объекты в долгоживущих структурах

Если вы помещаете указатель на маленький объект в глобальный кэш или в
объект, живущий всё время работы программы, этот маленький объект
никогда не будет собран GC, хотя мог бы быть быстро освобождён.
Рассмотрите возможность хранения значений (копий) вместо указателей,
если объекты небольшие и их копирование не слишком затратно.

Контролируйте размеры стеков горутин

Стеки горутин являются корнями для GC. Глубокие рекурсивные вызовы или
хранение больших локальных массивов увеличивают размер стека, и GC будет
тратить время на его сканирование. Старайтесь избегать неограниченной
рекурсии и чрезмерно больших локальных структур.

Оптимизируйте аллокации в циклах

Частая ошибка — создание новых объектов внутри горячего цикла. Например:

for _, s := range strings {
m := make(map[string]int)
// заполняем m
result = append(result, m)
}

Здесь на каждой итерации создаётся новая карта. Если карты небольшие,
возможно, лучше использовать одну и сбрасывать её содержимое (хотя для
map нет простого способа очистки без аллокации). Для таких случаев
подойдёт sync.Pool для карт или переиспользование структур.

Выбирайте правильный баланс GOGC

Если приложение работает с большими объёмами данных, но критично потребление памяти, можно уменьшить GOGC
(например, до 50). Это увеличит частоту сборок, но снизит пиковый
размер кучи. Если же приложению важна максимальная пропускная
способность и память не критична, можно увеличить GOGC
(например, до 200 или выше), чтобы GC запускался реже. В современных
облачных средах часто жертвуют памятью ради скорости, но решение всегда
зависит от конкретного SLA.

Сравнение с GC в других языках

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

• Java (HotSpot G1, ZGC):
  поколенные, сжимающие, с очень развитой настройкой. G1 и ZGC также
  нацелены на низкие паузы, но их реализация значительно сложнее. ZGC
  использует цветные указатели и может работать с терабайтными кучами с
  паузами менее 10 мс. Однако по умолчанию Java требует тюнинга, тогда как
  Go работает «из коробки».
• C# (.NET):
  также поколенный, сжимающий. В .NET есть несколько режимов: workstation
  GC (для настольных приложений) и server GC (для серверов). Server GC
  создаёт отдельные кучи и сборщики на каждое ядро, что повышает
  масштабируемость.
• Python / Ruby / JavaScript:
  используют простые сборщики, часто поколенные, но с заметными паузами
  при большом количестве объектов. Например, в Python есть reference
  counting с циклическим сборщиком, что приводит к накладным расходам на
  каждый инкремент/декремент счётчика.

Go выбирает компромисс: он не такой гибкий, как Java, но предлагает
предсказуемые низкие задержки без необходимости сложной настройки. Это
делает его отличным выбором для микросервисов, где важна простота
эксплуатации.

Заключение

Сборщик мусора в Go — это результат многолетней эволюции, направленной на достижение стабильно низких задержек при сохранении высокой
производительности. Отказ от поколений и сжатия в пользу полностью
конкурентной маркировки и очистки позволил создать систему, которая из
коробки даёт паузы менее миллисекунды даже при многогигабайтных кучах.
Понимание того, как устроен GC, какие фазы он проходит, как мониторить
его поведение с помощью GODEBUG и pprof, а также умение писать код, снижающий нагрузку на сборщик, — важные навыки для каждого Go-разработчика.

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

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