Как Garbage Collector определяет нехватку памяти?

Алгоритмы определения нехватки памяти в Garbage Collector

Garbage Collector (GC) в .NET определяет нехватку памяти через комплексный механизм, основанный на мониторинге потребления памяти, установленных лимитах и триггерах сборки. Основные подходы:

1. Мониторинг выделенной памяти и лимитов поколений

GC постоянно отслеживает объем памяти, выделенный для каждого поколения (Generation 0, 1, 2) и для Large Object Heap (LOH). Для каждого поколения установлены пороговые значения (thresholds). Когда выделенная память для Generation 0 приближается или превышает этот порог, GC запускает сборку.

// Пример: GC отслеживает статистику (можно получить через API)
GC.GetGeneration(someObject);
GC.GetTotalMemory(false); // Возвращает текущий объем выделенной памяти

Пороги динамически адаптируются в зависимости от паттернов выделения памяти в приложении.

2. Триггеры сборки по поколениям

Нехватка памяти определяется контекстуально для каждого поколения:

• Generation 0: Сборка запускается при переполнении выделенного сегмента. Generation 0 имеет самый маленький сегмент (обычно несколько МБ в зависимости от режима GC). Когда новые объекты не могут быть размещены в Gen 0, запускается Gen 0 collection.
• Generation 1 и 2: Сборка запускается когда:
  • После сборки Gen 0, Gen 1 также превышает порог
  • Приложение явно вызывает GC.Collect() (обычно не рекомендуется)
  • Системная нехватка памяти на уровне ОС

3. Внешние сигналы от операционной системы

В Workstation GC (для клиентских приложений) и Server GC (для серверных) триггером может быть сигнал от ОС:

// Внутренняя логика GC (не доступна напрямую в API)
if (osMemoryPressureNotification) {
    InitiateFullGC(); // Запуск полной сборки Generation 2
}

Windows предоставляет Memory Pressure Events, которые .NET CLR использует для запуска сборки при низкой доступной памяти системы.

4. Аллокация новых объектов как триггер

Каждый вызов new или выделение памяти через malloc в unsafe контексте проверяется на доступность места в соответствующем поколении:

// Пример аллокации, которая может триггернуть GC
var obj = new MyClass(); // Если в Gen 0 нет места, запускается сборка

Алгоритм определения:

1. Проверка свободного места в текущем сегменте Generation 0
2. Если места недостаточно → запуск Gen 0 collection
3. После сборки Gen 0, если Gen 1 также превышает порог → запуск Gen 1 collection
4. Если после этого Gen 2 превышает порог или есть давление от ОС → запуск Full GC (Gen 2)

5. Эвристические алгоритмы и статистика

GC использует эвристики (heuristics) на основе истории сборок:

• Частота аллокаций и скорость роста памяти
• Процент выживаемости объектов после каждой сборки
• Время, затраченное на предыдущие сборки

Например, если после сборки Gen 0 выживает много объектов (высокая выживаемость), порог Gen 0 может быть увеличен для уменьшения частоты сборок.

6. Специальные случаи и режимы GC

В конфигурациях GC поведение меняется:

• Workstation GC с Concurrent: Сборка запускается при порогах, но пытается минимизировать паузы
• Server GC: Пороги более агрессивны для многопоточных серверных нагрузок
• Low Latency Mode (GC.NoGCRegion): Приложение временно запрещает сборку, но при критической нехватке GC все же запускается

Практический пример и выводы

Нехватка памяти определяется не одним фактором, а совокупностью:

• Внутренние пороги поколений
• Внешнее давление ОС
• Статистика аллокаций
• Конфигурация GC (Workstation/Server)

// Пример мониторинга (для диагностики)
var memoryBefore = GC.GetTotalMemory(false);
PerformWork();
var memoryAfter = GC.GetTotalMemory(false);
var allocated = memoryAfter - memoryBefore;
// Если allocated постоянно превышает пороги GC → частые сборки

Ключевое: GC в .NET — саморегулирующаяся система. Она динамически адаптирует пороги на основе поведения приложения, чтобы балансировать между использованием памяти и производительностью сборок. Нехватка памяти — это сигнал для запуска очистки, но не обязательно означает физическое отсутствие памяти в системе; это механизм предотвращения переполнения.