> Что такое garbage collector и как он работает (Go)

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

Garbage collector (GC) - это компонент рантайма, который автоматически освобождает память, занятую объектами, на которые больше нет ссылок. В Go используется concurrent, tri-color mark-and-sweep сборщик. Он работает параллельно с основной программой, минимизируя паузы (stop-the-world). GC отслеживает достижимость объектов от корней (стек, глобальные переменные) и удаляет недостижимые, возвращая память аллокатору.

Подробное объяснение

GC решает проблему ручного управления памятью: разработчику не нужно явно вызывать free или delete. Это снижает риск утечек памяти и ошибок вида use-after-free. В Go сборщик мусора - часть рантайма, он запускается автоматически по определённым триггерам.

Основной алгоритм в Go - tri-color mark-and-sweep:

1. Mark (разметка) - сборщик обходит граф объектов, начиная с корней (глобальные переменные, стек каждого горутина, регистры). Каждый объект помечается одним из трёх цветов:

   • белый - не посещён, кандидат на удаление;
   • серый - обнаружен, но его ссылки ещё не обработаны;
   • чёрный - обработан, все его поля проверены.

2. Sweep (очистка) - после завершения разметки все белые объекты считаются недостижимыми, их память возвращается в аллокатор.

Ключевая особенность Go - concurrent GC: разметка выполняется параллельно с работой программы. Для этого используется write barrier - механизм, который при записи указателя в поле объекта помечает целевой объект как серый, чтобы сборщик не пропустил новую ссылку. Это позволяет избежать длительных stop-the-world пауз.

Дополнительно Go использует generational hypothesis частично: есть отдельный механизм для маленьких объектов, но в целом GC не является поколенческим. Вместо этого применяется hybrid write barrier и оптимизации для снижения пауз.

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

• превышение порога роста heap (по умолчанию GOGC=100, т.е. сборка при удвоении размера живой памяти);
• явный вызов runtime.GC();
• при нехватке памяти.

На практике

Для backend-разработчика на Go важно понимать, как GC влияет на latency и throughput. Основные практические аспекты:

• Настройка GOGC - переменная окружения или runtime.SetGCPercent. Увеличение значения (например, 200) снижает частоту сборок, но увеличивает пиковое потребление памяти. Уменьшение (50) - наоборот.
• Снижение аллокаций - меньше аллокаций → реже GC → меньше пауз. Используйте sync.Pool, переиспользование буферов, избегайте лишних конкатенаций строк.
• Избегание указателей в горячих путях - объекты без указателей (например, []byte) GC обрабатывает быстрее, так как не нужно сканировать их содержимое.
• Мониторинг - смотрите метрики runtime.MemStats: HeapAlloc, HeapObjects, PauseNs (гистограмма пауз). Это помогает выявить проблемы с GC.
• Специфика - в Go нет возможности отключить GC полностью, но можно минимизировать его влияние через оптимизацию кода.

Пример кода

GO
package main

import (
    "fmt"
    "runtime"
    "time"
)

func main() {
    // Пример: измерение пауз GC
    var stats runtime.MemStats
    runtime.ReadMemStats(&stats)
    
    // Создаём нагрузку - много аллокаций
    for i := 0; i < 100000; i++ {
        _ = make([]byte, 1024)
    }
    
    runtime.GC() // принудительный запуск
    
    runtime.ReadMemStats(&stats)
    fmt.Printf("HeapAlloc: %d bytes\n", stats.HeapAlloc)
    fmt.Printf("NumGC: %d\n", stats.NumGC)
    fmt.Printf("PauseTotalNs: %d ns\n", stats.PauseTotalNs)
    
    // Пример настройки GOGC
    old := runtime.SetGCPercent(200) // реже сборки
    defer runtime.SetGCPercent(old)
    
    // Пример использования sync.Pool для снижения аллокаций
    pool := &sync.Pool{
        New: func() interface{} {
            return make([]byte, 1024)
        },
    }
    
    buf := pool.Get().([]byte)
    // используем buf...
    pool.Put(buf) // возвращаем в пул
}

Как отвечать на собеседовании

Начните с краткого определения, затем опишите алгоритм mark-and-sweep и три цвета. Обязательно упомяните concurrent-природу и write barrier - это ключевое отличие Go от многих других языков. Приведите пример, когда GC может стать проблемой (высокий трафик, много аллокаций), и как это решается (GOGC, sync.Pool). Если спросят про поколения - честно скажите, что Go не поколенческий, но есть оптимизации. Хорошо показать знание метрик runtime.MemStats.

Что проверяет интервьюер

• Понимание базовых принципов автоматического управления памятью.
• Знание конкретной реализации в Go: tri-color, write barrier, concurrent.
• Умение связать теорию с практикой: влияние на производительность, настройки.
• Понимание trade-off: частота сборок vs потребление памяти.
• Знание инструментов мониторинга и профилирования (pprof, MemStats).

Типичные ошибки

• Путаница между mark-and-sweep и reference counting (в Go нет подсчёта ссылок).
• Утверждение, что Go GC - поколенческий.
• Незнание write barrier - без него нельзя объяснить, как GC работает параллельно с программой.
• Игнорирование влияния аллокаций на latency - ответ только про теорию без практики.
• Ошибочное мнение, что runtime.GC() нужно вызывать вручную в production - это почти всегда вредно.
• Непонимание, что GC в Go не освобождает память сразу в ОС - она остаётся в heap рантайма.