Как отвечать: определение → как работает внутри → где ловушка → пример. Отвечайте вслух до чтения ответа — собеседование это устный жанр, и «понимаю про себя» не равно «объясняю словами».
1. Зачем нужен write barrier? Что сломалось бы без него?
Маркировка идёт параллельно с работой программы: пока GC расставляет метки, горутины продолжают менять граф указателей. Без защиты возможна потеря объекта: GC прочитал поле и пошёл проверять старую ссылку, а горутина в этот момент записала туда новую — новый объект мог остаться белым (немаркированным) и был бы собран вместе с живыми данными. Write barrier — маленький хук на запись указателей: во время маркировки он сообщает GC об изменениях (записывает затронутые указатели в буфер, GC их перепроверяет — shaded objects). Следствие, которое спрашивают: запись указателя во время GC дороже обычной — поэтому в hot path рекомендуют уменьшать количество указательных полей ( value вместо *T, индексы вместо ссылок).
2. Какие фазы у цикла сборки и где stop-the-world?
Цикл: sweep termination (короткая STW) → mark phase — параллельная маркировка с включением assists → mark termination (короткая STW: финализация меток, очистка) → sweep phase — фоновая уборка по сегментам. Обе STW-паузы в здоровом приложении — десятки и сотни микросекунд; на них жалуются обычно тогда, когда программа с тысячами горутин останавливается впервые после старта (стеки надо просканировать) — поэтому «разогрев» после деплоя может показывать редкие длинные паузы. В ответе полезно назвать assists: если горутина аллоцирует быстрее, чем работает маркировка, её заставляют помогать маркировке — латентность растёт у «виновника».
3. Что такое mark assist и когда он бьёт по латентности?
Assist — механизм справедливости маркировки: если во время mark phase горутина аллоцирует память, она обязана отработать часть маркировки пропорционально аллокации. Для типовых сервисов это незаметно; для аллоцирующих hot path (сотни тысяч аллокаций в секунду) assist превращается в скрытые хвосты латентности: p95/p99 растёт волнами во время GC-циклов. Диагностика: метрика GC assist time (runtime/metrics /Gc/... или pprof). Лечение: меньше аллокаций в горячем пути (sync.Pool, переиспользование буферов, pre-allocation), иногда — поднятие GOGC, чтобы сборки были реже, а assists короче.
4. Чем sweep отличается от scavenger? Куда возвращается память?
Sweep помечает память свободной внутри кучи Go — она остаётся у процесса и переиспользуется новыми аллокациями. Scavenger — отдельный механизм, который возвращает свободные страницы операционной системе (madvise/MADV_FREE): без него RSS после пика оставался бы навсегда. Нюансы для ответа: возврат памяти — фоновый и постепенный (не мгновенный), поэтому RSS после пиковой нагрузки «сдувается» минутами; в Linux MADV_FREE не сразу уменьшает RSS в мониторинге — страницы числятся освобождёнными, но из метрик ОС уходят при реальном давлении на память. Вопрос «почему RSS не падает после оптимизации» на собеседовании закрывается ровно этим различием.
5. Как GOGC и GOMEMLIMIT работают вместе? Приведите настройку для контейнера.
GOGC задаёт относительную цель (во сколько раз куча вырастет между сборками), GOMEMLIMIT — абсолютный мягкий потолок всей памяти рантайма. Они работают одновременно: GC стремится к GOGC-росту, но не даёт сумме превысить GOMEMLIMIT, форсируя сборки при подходе к потолку. Практика в контейнере с лимитом 512М: GOMEMLIMIT=440M (85% — запас под стеки, метаданные и вне-кучу), GOGC=100 по умолчанию; для сервисов с сильными пиками — GOGC поднимают (например, 300), экономя CPU на сборках, а потолок держит OOM. Опасность-ловушка: GOMEMLIMIT — не гарантия; если живые данные реально близки к лимиту, рантайм будет крутить сборки бесконечно (thrashing) — это видно по росту CPU GC и его надо лечить аллокациями, а не настройками.
GOMEMLIMIT=440MiB # мягкий потолок памяти процесса GOGC=100 # дефолт; при пиках поднимают до 200-400
6. Что такое стек горутины, как он растёт и чем опасен stack growth?
Стек горутины стартует с 8 КБ и растёт копированием: при нехватке рантайм выделяет новый стек вдвое больше и переносит кадры. Копирование безопасно потому, что Go использует стековые указатели относительно (внутри кадра нет абсолютных адресов в стек), но срезы/указатели, которые уже «уехали» из стека в кучу, переезжать не могут — они и так в куче. Следствия: тысячи горутин — это тысячи стеков (память 8КБ × N минимум), а редкие остановки «первого GC после старта» связаны в том числе со сканированием стеков. Уменьшать число горутин ради стека обычно не нужно — 8 КБ × 100к = 800 МБ уже много, но типичные сервисы живут сотнями-тысячами горутин без проблем.
7. Финализаторы и cleanup: чем runtime.SetFinalizer отличается от addCleanup (Go 1.24+)?
SetFinalizer запускает функцию, когда объект стал недостижимым, до освобождения памяти: используется для обёрток нерезюмируемых ресурсов (C-память, дескрипторы). Известные проблемы: финализатор продлевает жизнь объекта минимум на один цикл GC, требует «самоссылок» для восстановления, порядок запуска не гарантирован. В Go 1.24 появился runtime.AddCleanup — новая замена: функцию вешают на отдельный объект, меньше ограничений и дешевле. Правильный посыл на интервью: и то и другое — крайняя мера; явное Close() через defer и sync.Once остаётся основным способом освобождения, финализация — страховка от забывчивости пользователя библиотеки.
8. Практический кейс: p99 латентность сервиса растёт волнами раз в несколько секунд. Как связать это с GC?
Маршрут диагностики: (1) график GC-пауз и частоты сборок (runtime/metrics: /gc/pauses:seconds histogram, /gc/cycles) — волнам латентности обычно соответствуют сборки; (2) график размера кучи: пилообразный рост до GOGC-предела и сброс — подтверждение; (3) pprof: доля CPU в gcBgMarkWorker (помощь маркировке) и в runtime.mallocgc (аллокации + assists). Если подтверждено: уменьшать аллокации в горячем пути (re-use, Pool, value-типы вместо указателей), поднять GOGC/GOMEMLIMIT, при упорных паузах — искать крупный фиксированный аллоцируемый буфер (например, огромный make в хендлере). Ответ уровня senior: сначала измерить, потом настраивать; «подкрутить GOGC» без профиля — угадывание.
Прокачать тему в самоучителе
Читается быстро, запоминается практикой. Эти курсы закрывают тему с запуском кода прямо на странице:
- Продвинутые возможности языка Go — Продвинутый курс Go: замыкания, defer, горутины, каналы, контекст, интерфейсы, дженерики, рефлексия, тесты и JSON. 25 уроков с практикой в браузере.