Почему в Go растет память при активном сборщике мусора и как найти утечку

Одна из распространенных иллюзий среди разработчиков, переходящих на Go с C или C++, — уверенность в том, что наличие автоматического сборщика мусора гарантирует защиту от утечек оперативной памяти. В низкоуровневых языках забытый вызов free() приводит к физической потере указателя: блок памяти остается занятым в ОС, хотя программа о нем уже ничего не знает. В Go подобная ситуация исключена. И тем не менее графики потребления памяти в Grafana раз за разом показывают неумолимый тренд вверх, пока контейнер не настигает OOMKilled от ядра Linux.

Сборщик мусора в Go регулярно обходит граф объектов, начиная от корней (GC roots: глобальные переменные, стеки активных горутин), и уничтожает недостижимые структуры. Однако если приложение само удерживает ссылку на объект в активной переменной, GC обязан сохранить его в куче, даже если в бизнес-логике эти данные устарели и больше никогда не понадобятся. Это называется логической утечкой памяти.

Три классических сценария скрытого удержания памяти

В бэкенд-разработке на Go львиная доля скрытых утечек сводится к трем архитектурным ловушкам:

Бесконечно растущие коллекции без вытеснения: Разработчики создают внутренний in-memory кэш на базе стандартной map или среза slice, но забывают реализовать политику устаревания записей (TTL) или алгоритм вытеснения элементов (LRU). Каждая входящая операция добавляет элемент, и коллекция раздувает кучу.
Коварство реслайсинга (reslicing): Представим, что сервис считывает из сокета пакет данных размером в несколько мегабайт в байтовый срез data := make([]byte, 1024*1024*10). Из этого массива парсер извлекает всего 16 байт заголовка: header := data[:16]. Если переменная header сохраняется в долгоживущей структуре, сборщик мусора не сможет освободить исходный 10-мегабайтный массив. В Go срез хранит указатель на массив, длину и емкость (cap). Пока жив хоть один срез, ссылающийся на подлежащий массив, весь массив целиком остается в памяти. Спасение — явное копирование через copy().
Утечки брошенных горутин (goroutine leaks): Горутина в Go легковесна (начальный стек всего 2–4 КБ), но если она блокируется навсегда — например, при попытке записи в небуферизованный канал, из которого никто не читает, или при отсутствии таймаута в контексте — рантайм никогда не удалит ее из памяти. Стек заблокированной горутины, а также все локальные переменные, захваченные в ее замыкание, остаются привязаны к корням сборщика мусора. Сотни таких зависших горутин незаметно удерживают сотни мегабайт.

Чтение мыслей сборщика мусора через gctrace

Первый шаг в расследовании аномального потребления памяти — проверка гипотезы: действительно ли в сервисе происходит логическая утечка памяти? Для этого достаточно запустить бинарник приложения с флагом отладки рантайма:

GODEBUG=gctrace=1 ./my-service

Рантайм начнет выводить в стандартный поток ошибок подробный отчет о каждом цикле сборщика:

gc 18 @42.150s 1%: 0.045+1.2+0.030 ms clock, 0.36+0.8/2.1/0+0.24 ms cpu, 14->15->8 MB, 16 MB goal, 8 P

В этой строке зашифрована фундаментальная метрика:

Числа 14->15->8 MB: это размер кучи до начала фазы маркировки, размер кучи в момент окончания маркировки и фактический размер живых данных после очистки (sweep).
Значение 8 MB: реальный объем данных, которые сборщик мусора счел достижимыми.
Главный диагностический признак: если под стабильной рабочей нагрузкой конечное число (размер живой кучи после sweep) монотонно увеличивается от цикла к циклу — скажем, с 8 МБ до 24 МБ, затем до 60 МБ и далее без откатов назад — перед нами однозначная логическая утечка памяти. Сборщик мусора регулярно прочесывает память, но объем удерживаемых данных растет.

Подключение pprof и анатомия снимков кучи

Когда факт утечки подтвержден, наступает этап точечной локализации виновника в исходном коде. Стандартная библиотека Go предоставляет эталонный инструмент профилирования — пакет net/http/pprof.

Куча в pprof измеряется в двух принципиально разных режимах:

-alloc_space: показывает суммарный объем памяти, выделенный приложением с момента старта процесса, включая все уже уничтоженные и собранные GC объекты. Этот режим полезен для поиска точек высокой нагрузки на аллокатор памяти, но бесполезен для поиска утечек.
-inuse_space: показывает объем памяти, занятый объектами прямо в данную секунду. Именно этот режим позволяет изолировать те блоки, которые GC не может удалить.

Минимальный сервис с воспроизведением утечки и регистрацией эндпоинта pprof:

package main

import (
    "log"
    "net/http"
    _ "net/http/pprof"
    "time"
)

// Глобальная коллекция, симулирующая утечку ссылок
var memorySink = make([]*[1024]byte, 0)

func workerLoop() {
    for {
        // Регулярно создаем объект размером 1 КБ и сохраняем указатель
        chunk := new([1024]byte)
        memorySink = append(memorySink, chunk)
        time.Sleep(5 * time.Millisecond)
    }
}

func main() {
    // Поднимаем отладочный эндпоинт pprof на изолированном порту
    go func() {
        log.Println(http.ListenAndServe("localhost:6060", nil))
    }()

    go workerLoop()

    log.Println("Сервис запущен. Имитация удержания памяти активна...")
    select {}
}

Дифференциальный анализ: метод двух снимков

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

Сравнительный дифференциальный анализ двух снимков кучи pprof для выявления скрытой утечки памяти в Go

Для гарантированного выявления утечки применяется дифференциальное профилирование:

Сервис запускается под нагрузкой. После прогрева кэшей (спустя 2–3 минуты) снимается базовый снимок кучи (heap_base.pb.gz).
Приложение продолжает работать под той же нагрузкой в течение 20–30 минут, накапливая утечку.
Снимается второй, контрольный снимок (heap_target.pb.gz).
Запускается сопоставление через флаг -diff_base.

Команды фиксации снимков и дифференциального анализа:

# 1. Фиксация базового снимка после прогрева сервиса
curl -s http://localhost:6060/debug/pprof/heap > heap_base.pb.gz

# 2. Фиксация контрольного снимка через 20 минут активной работы
curl -s http://localhost:6060/debug/pprof/heap > heap_target.pb.gz

# 3. Запуск сравнительного анализа дельты удерживаемой памяти
go tool pprof -inuse_space -diff_base heap_base.pb.gz heap_target.pb.gz

В интерактивном интерфейсе pprof вызываются две главные команды:

(pprof) top
Showing nodes accounting for +18.42MB, 98.5% of +18.70MB total
      flat  flat%   sum%        cum   cum%
   +18.42MB 98.5%  98.5%   +18.42MB 98.5%  main.workerLoop

(pprof) list workerLoop
ROUTINE ======================== main.workerLoop
   +18.42MB   +18.42MB (flat, cum)  98.5% of Total
         .          .     14:func workerLoop() {
         .          .     15:   for {
   +18.42MB   +18.42MB     16:      chunk := new([1024]byte)
         .          .     17:       memorySink = append(memorySink, chunk)
         .          .     18:       time.Sleep(5 * time.Millisecond)
         .          .     19:   }
         .          .     20:}

Команда top сразу поднимает наверх функции с наибольшим положительным приростом (+18.42MB), а команда list показывает точные номера строк в исходном коде, где выделяются невыгружаемые объекты.

Возврат памяти операционной системе: иллюзия постоянного роста RSS

Нередко инженеры сталкиваются с загадкой: утечка устранена, в pprof куча снизилась с 2 ГБ до 200 МБ, но утилита top или метрики container_memory_working_set_bytes в Kubernetes по-прежнему показывают прежние 2 ГБ.

Здесь важно понимать механику взаимодействия рантайма Go с ядром Linux. Сборщик мусора освобождает память внутри собственной виртуальной кучи, организуя ее в спаны (mspan) для повторного использования будущими аллокациями. Физический возврат страниц памяти ядру ОС выполняется асинхронно специальным фоновым потоком — скравером (scavenger).

Скравер использует системный вызов madvise с флагом MADV_DONTNEED. Этот вызов сообщает ядру Linux, что физические страницы можно забрать при нехватке памяти, однако виртуальный диапазон остается зарезервированным. Поэтому падение показателя RSS в операционной системе происходит плавно и с задержкой.

Памятка инженеру: чеклист защиты от утечек памяти

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

Оснащайте любые in-memory хранилища и кэши жесткими лимитами размера или временем жизни записей (TTL). Если хранилище превышает критический порог, старые ключи должны автоматически вытесняться.
При срезании небольших фрагментов данных из массивных буферов всегда используйте явное копирование в свежевыделенный массив через функцию copy().
Контролируйте жизненный цикл каждой порождаемой горутины. Передавайте контекст с таймаутом context.WithTimeout и гарантируйте, что при отмене контекста каналы будут прочитаны, а горутины корректно завершатся.
Проверяйте подозрительные сервисы через GODEBUG=gctrace=1 на этапе нагрузочного тестирования. Если живая куча растет синхронно со временем теста — ищите логическую утечку до выкатки в прод.
Регулярно практикуйте дифференциальное профилирование go tool pprof -diff_base при нагрузочных прогонах. Оно отсекает статический шум и безошибочно указывает на проблемную строчку кода.