Краткий ответ

Принудительный вызов runtime.GC после каждой операции обычно повышает загрузку CPU и ухудшает хвостовые задержки. Сборщик запускает частые циклы даже тогда, когда объём недавно созданного мусора недостаточен для оправдания такой работы.

Исторический контекст

Автоматический запуск GC появился для того, чтобы приложению не приходилось вручную определять момент сборки недостижимых объектов. Современный сборщик Go выполняет значительную часть работы конкурентно с приложением, стремясь ограничить длительные паузы и самостоятельно выбирать компромисс между памятью и CPU.

Принудительный запуск оставлен как специальный инструмент: например, для контролируемого измерения поведения памяти или редких операций обслуживания. Он не предназначен для регулярного управления жизненным циклом объектов в обработчиках запросов.

Постановка проблемы

После завершения операции в памяти может находиться много ещё живых объектов или небольшое количество мусора. Вызов GC не делает живые объекты дешевле и не гарантирует немедленного уменьшения RSS процесса, но всё равно запускает работу по обнаружению недостижимых объектов.

Если делать это для каждого запроса, стоимость сборки начинает зависеть не от реальной необходимости, а от частоты запросов. Это может привести к росту CPU, снижению пропускной способности и увеличению p95/p99 latency из-за фаз, синхронизации и ожидания завершения цикла.

Подробное решение

runtime.GC инициирует цикл сборки и блокирует вызывающую горутину до его завершения. Сам цикл включает короткие остановки мира, конкурентную маркировку и последующую обработку освобождённой памяти; точная видимая задержка зависит от размера кучи, количества указателей, скорости аллокаций и текущей нагрузки.

Принудительный запуск не означает, что все объекты будут освобождены: достижимые объекты останутся живыми. Кроме того, освобождение памяти внутри рантайма не обязано сразу возвращать страницы операционной системе, поэтому RSS может почти не измениться.

Частые вызовы также мешают штатному pacing сборщика. Рантайм обычно запускает GC на основе объёма живой памяти и темпа аллокаций, а ручной запуск заставляет его работать раньше естественного порога. В результате на каждый цикл приходится фиксированная и переменная накладная стоимость, даже если собирать почти нечего.

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

Минимальный пример антишаблона:

func handle(items []Item) Result {
    result := process(items)
    runtime.GC()
    return result
}

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

Ситуация из практики

В сервисе вызов GC добавили после формирования каждого большого ответа, рассчитывая уменьшить память перед следующим запросом. В профиле обнаружились повышенные CPU-затраты и ухудшение хвостовой задержки, хотя RSS почти не изменился: значительная часть объектов оставалась живой, а освобождённые страницы не сразу возвращались системе.

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

Выбрали третий вариант: убрали GC из обработчика, ограничили время жизни крупных буферов и проверили поведение под нагрузкой. Результат оценивали по CPU, аллокациям, live heap, RSS и p99 latency; решение считали успешным только при улучшении целевого показателя без неприемлемого роста памяти.

Что кандидаты часто упускают

Вопрос: Блокирует ли принудительный GC все горутины на всё время сборки?

Ответ: Нет, это неточная формулировка. В цикле есть stop-the-world-фазы, но значительная часть маркировки выполняется конкурентно с приложением. При этом вызывающая горутина ждёт завершения runtime.GC, а продолжительность и влияние пауз зависят от состояния рантайма и размера работы.
Вопрос: Обязательно ли после runtime.GC уменьшается объём памяти процесса?

Ответ: Нет. GC освобождает недостижимые объекты для повторного использования рантаймом, но это не означает немедленного возврата страниц операционной системе. На RSS влияют удерживаемые живые объекты, внутренние структуры аллокатора, фрагментация и политика возврата страниц.
Вопрос: Может ли ручной GC быть оправдан в серверном приложении?

Ответ: Да, но только в узком, измеренном сценарии. Например, после редкой операции, которая временно создала большой объём мусора, ручной запуск может помочь завершить сборку до перехода к фазе простоя. В горячем пути он обычно вреден; решение нужно подтверждать нагрузочными измерениями CPU, latency, live heap и RSS.