Какие знаешь причины, которые подталкивают заменить G1 Garbage Collector?

Причины замены G1 Garbage Collector

G1GC был революционным сборщиком мусора, представленным в Java 7 и ставший default в Java 9. Однако в современных приложениях есть сценарии, где имеет смысл рассмотреть альтернативы. Рассмотрю основные причины и когда переходить на другие сборщики.

1. Latency-sensitive приложения - переходим на ZGC

Eсли вашему приложению требуются очень низкие и предсказуемые паузы GC:

// G1GC - типичные паузы: 10-100ms в production
// ZGC - паузы <= 1ms (гарантированно)

// Запуск с ZGC:
// java -XX:+UseZGC -XX:+ZGenerational -jar app.jar

// Сравнение задержек:
public class LatencySensitiveApp {
    // Для торговли на бирже, рекламных аукционов, real-time анализа
    // G1 pauses: 50-200ms - НЕПРИЕМЛЕМО
    // ZGC pauses: <1ms - ИДЕАЛЬНО
    // Shenandoah: 1-3ms - ХОРОШО
}

Когда это критично:

• Финтех приложения (биржевые алгоритмы)
• Рекламные аукционы (real-time bidding)
• Онлайн игры с требованиями к фреймрейту
• Системы реального времени (телеком, системы управления)

2. Большой heap size (> 100GB) - переходим на ZGC или Shenandoah

G1GC плохо масштабируется при очень больших heaps:

// Проблема G1: время full GC растёт линейно с размером heap
// Heap: 32GB  -> Full GC pause: 5-10 сек
// Heap: 128GB -> Full GC pause: 20-40 сек (НЕДОПУСТИМО!)

// ZGC масштабируется линейно на предиктивных фазах
// Heap: 32GB  -> Pause: <1ms
// Heap: 128GB -> Pause: <1ms (практически не растёт)

// Сравнение сборщиков по heap size:
public class HeapScalingComparison {
    /*
    Heap Size | G1 Pause | ZGC Pause | Shenandoah
    32GB      | 10-50ms  | <1ms      | 1-3ms
    64GB      | 30-100ms | <1ms      | 2-5ms
    128GB     | 200-500ms| <1ms      | 5-10ms
    256GB     | 1-5sec   | <1ms      | 10-20ms
    */
}

Когда заменять G1:

• In-memory БД (Coherence, Ignite) с хранением в памяти
• Data warehouses (очень большие наборы данных)
• Графовые БД с полным графом в памяти

3. Случайные полные паузы GC (Full GC) - переходим на Shenandoah

G1 иногда вынужден делать Full GC (stop-the-world), что вызывает длительную паузу:

// Причины Full GC в G1:
// 1. Fragmentation - фрагментация памяти
// 2. Метаспейс overflow - переполнение кода/метаданных
// 3. Humongous allocations - выделение очень больших объектов

public class FullGCProblem {
    public static void main(String[] args) {
        // Код, вызывающий Full GC в G1:
        // java -XX:+UseG1GC -XX:G1HeapRegionSize=1M -Xmx1G App
        
        // Full GC для 1GB heap: 0.5-1 сек PAUSE
        // Приложение полностью заморозится!
    }
}

// Shenandoah избегает Full GC благодаря:
// - Brooks pointers (concurrent relocating)
// - Более гибкой архитектуре

Симптомы проблемы:

• В логах: [GC (G1 Evacuation Pause) ... (Concurrent Humongous Allocation) + долгая пауза
• Нерегулярные спайки latency в метриках
• Пики CPU перед паузой (попытка сделать Full GC)

4. Multi-threaded параллеллизм требует максимальной throughput

Если приложение может позволить себе периодические паузы ради throughput:

// G1 оптимизирован для латенси, а не throughput
// Для максимального throughput лучше выбрать:

// 1. Parallel GC (если допустимы паузы 100-500ms)
java -XX:+UseParallelGC -XX:ParallelGCThreads=8 -Xmx4G app.jar

// Throughput сравнение (operations/sec):
public class ThroughputComparison {
    /*
    GC         | Throughput | Max Pause | Use Case
    Parallel   | 95%        | 500ms     | Batch processing
    G1         | 90%        | 50ms      | Balanced
    ZGC        | 85%        | <1ms      | Latency-critical
    Shenandoah | 87%        | 5ms       | Concurrent heavy
    */
}

5. Зависит от Java версии - выбираем новые сборщики

Новые сборщики стали стабильны только в последних версиях:

// Java 8:  G1GC (default) - это был шаг вперёд
// Java 11: ZGC (experimental) - добавлен
// Java 15: ZGC (production ready) - готов к production
// Java 17: ZGC (default option), Shenandoah стабилен
// Java 21: ZGC улучшен, Shenandoah очень стабилен

public class GCAvailability {
    // java -version показывает версию
    // java --version  (с Java 9+)
    
    // Если Java 8 -> G1 это лучший выбор
    // Если Java 15+ -> рассмотреть ZGC
    // Если Java 21+ -> ZGC по умолчанию отличен
}

6. Контейнеризация и CPU limiting - ZGC/Shenandoah лучше

В Docker контейнерах G1 может неправильно считать доступные ресурсы:

// Docker наложил ограничение: 4 CPU, 8GB RAM
// Но JVM видит все 16 CPU хоста!

// G1 параллелизм = 16 потоков -> конфликты в контейнере
java -XX:+UseG1GC -XX:ParallelGCThreads=16 -Xmx8G app.jar
// -> CPU throttling, задержки

// ZGC лучше адаптируется к контейнерным ограничениям
java -XX:+UseZGC \
     -XX:+ZGenerational \
     -Xmx8G \
     -XX:ActiveProcessorCount=4 \  // явно указываем реальное количество CPU
     app.jar

7. Долгоживущие объекты и старые поколения - G1 неэффективен

Eсли много долгоживущих объектов (caches, session storage):

// G1 разделяет heap на regions одинакового размера
// Проблема: долгоживущие объекты фрагментируют память

public class LongLivedObjectsIssue {
    // In-memory кэш на 2GB из 4GB heap
    // Остальные 2GB для молодого поколения
    // G1 не может эффективно сжать память -> потери ~20%
    
    // CMS (deprecated в Java 9, удален в Java 14):
    // java -XX:+UseConcMarkSweepGC -Xmx4G app.jar
    // Лучше работал с долгоживущими объектами
    
    // Shenandoah справляется лучше благодаря concurrent relocation
}

8. Финальный чек-лист для замены G1:

public class GCReplacementChecklist {
    boolean shouldReplaceG1() {
        boolean hasLatencySLA = latency_SLA_ms < 50;           // -> ZGC
        boolean hasHugeHeap = heap_size_gb > 100;              // -> ZGC
        boolean hasUnpredictablePauses = p99_latency > 200;    // -> Shenandoah
        boolean hasConcurrentWorkload = concurrent_threads > 20; // -> Shenandoah
        boolean needsMaxThroughput = batch_processing;         // -> Parallel GC
        boolean isJava21Plus = java_version >= 21;             // -> ZGC default
        
        if (hasLatencySLA || hasHugeHeap) return true;
        if (hasUnpredictablePauses || hasConcurrentWorkload) return true;
        
        return false;
    }
}

Практическая рекомендация:

G1GC остаётся лучшим выбором для:

• Большинство Java приложений
• Heap 4-32GB
• Tolerable latency 50-100ms
• Java 8-16

Переходить на ZGC если:

• Latency < 10ms критична
• Heap > 100GB
• Java 15+

Переходить на Shenandoah если:

• Много concurrent операций
• Предсказуемые паузы важнее throughput
• Есть Full GC паузы

Выбор GC - это баланс между latency, throughput и footprint. G1 хорошо балансирует, но новые сборщики дают больше контроля.