Сравнение GC

НЕ ОБЯЗАТЕЛЬНО ДЛЯ НОВИЧКОВ

Цель лабораторной

Сравнить поведение разных реализаций GC (Garbage Collector) под одинаковой нагрузкой и понять, как это влияет на:

  • задержки приложения;
  • потребление памяти;
  • стабильность throughput;
  • паузы (stop-the-world или частичные паузы).

Что нужно знать перед стартом

  • Heap — область памяти для динамически создаваемых объектов.
  • GC pause — время, когда выполнение пользовательского кода замедляется или останавливается ради уборки памяти.
  • Allocation rate — скорость создания объектов.
  • Promotion — перенос объектов из "молодого" поколения в "старшее".
  • Compaction — уплотнение памяти для снижения фрагментации.

Важно: "быстрый GC" в одном сценарии может быть "плохим GC" в другом.

Подготовка эксперимента

1) Выберите сравниваемые платформы

Практичный минимум:

  • Java (G1, ZGC или Shenandoah),
  • Go (стандартный concurrent GC),
  • .NET (Server GC / Workstation GC).

2) Сделайте одинаковую нагрузку

Сценарий должен быть идентичным:

  • много короткоживущих объектов;
  • часть долгоживущих объектов;
  • постоянный поток запросов/операций.

3) Зафиксируйте условия

  • одинаковый лимит RAM;
  • одинаковое число CPU;
  • одинаковая длительность теста (например, 10 минут);
  • прогрев перед замером (1-2 минуты).

Пошаговая методика

Шаг 1. Снимите baseline без тюнинга

Для каждой платформы:

  1. Запустите приложение с настройками по умолчанию.
  2. Выполните нагрузку.
  3. Сохраните метрики и логи GC.

Шаг 2. Снимите ключевые метрики

Минимальный набор:

  • p50/p95/p99 задержки;
  • throughput (операций/сек);
  • среднее и пиковое потребление heap;
  • количество и длительность GC-пауз;
  • доля времени, потраченного на GC.

Шаг 3. Проведите controlled tuning

Меняйте только один параметр за раз. Примеры:

  • размер heap,
  • тип GC,
  • целевая пауза (где поддерживается),
  • пороги запуска сборки.

Шаг 4. Повторите прогоны

Каждый сценарий прогоняйте 3-5 раз. Сравнивайте медиану, а не единичный "удачный" запуск.

Что обычно показывает сравнение

  • При высокой скорости аллокаций могут расти хвостовые задержки (p99).
  • Уменьшение пауз иногда повышает расход CPU.
  • Большой heap снижает частоту сборок, но может ухудшить latency в моменты тяжелой уборки.
  • "Агрессивный" тюнинг GC без замера SLA часто ухудшает UX.

Шаблон таблицы результатов

Заполняйте для каждой конфигурации:

  • Платформа и версия.
  • Тип GC.
  • Размер heap.
  • Throughput.
  • p95/p99.
  • Суммарное время пауз.
  • Пик RAM.
  • Вывод (подходит/не подходит под SLA).

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

  • Сравнение разных по логике приложений вместо одинакового бенчмарка.
  • Анализ только среднего времени ответа.
  • Игнорирование прогрева JIT/рантайма.
  • Отсутствие контроля версий и флагов запуска.
  • Вывод "этот GC лучший всегда" без контекста нагрузки.

Практический итог

Результат лабораторной — не "выбрать модный GC", а получить доказуемый профиль:

  • какой режим лучше для вашего SLA;
  • где компромисс между latency, throughput и RAM;
  • какие настройки безопасно применять в продакшене.

Только такие данные позволяют обсуждать производительность предметно, а не на уровне мифов.