Ключевые концепции управляемой (managed) памяти в Java/C# — кратко:
- Автоматическое выделение и освобождение: память для объектов выделяется в куче (heap) автоматически; освобождение выполняет среда выполнения (GC), а не программист.
- Разделение стек/куча: локальные примитивы/указатели на объекты хранятся в стеке, объекты — в куче; стек часто освобождается автоматически при выходе из функций.
- Root set и достижимость: сборщик считает объект «живым», если до него можно добраться из корней (стек, регистры, статические поля). Недоминируемые объекты считаются мусором.
- Трассирующие vs счётные методы:
- Трассировка (mark-and-sweep, copying): пометить достижимые объекты, затем освободить остальные; бывают копирующие и компактирующие варианты.
- Счётчик ссылок: у каждого объекта счётчик ссылок, объект удаляется при достижении 0; требует обработки циклов.
- Поколенческая (generational) стратегия: объекты делятся по поколениям (young/old) на основе эмпирики (большинство объектов умирают молодыми) — ускоряет сборку.
- Компактирование и перемещение: некоторые сборщики перемещают объекты для уменьшения фрагментации и ускорения аллокации (требует обновления ссылок).
- Конкурентность и инкрементальность: сборщики могут работать параллельно с приложением или инкрементально, чтобы уменьшить паузы.
- Барьеры записи (write barriers): механизмы для согласования работы GC и поточного кода при перемещении/инкрементальной сборке.
- Управление финализацией/ресурсами: финализаторы редко рекомендуются; для внешних ресурсов используют явные паттерны (try-with-resources, IDisposable).
Преимущества сборщика мусора по сравнению с ручным управлением:
- Безопасность: отсутствие висячих указателей (dangling), меньше ошибок типа use-after-free; автоматическая борьба с большинством утечек памяти.
- Производительность разработки: проще писать и поддерживать код, меньше низкоуровневого кода управления памятью.
- Оптимизации времени выполнения: GC + JIT позволяют делать композиционные оптимизации (escape analysis, inlining, автоматическое compacting).
- Управляемость фрагментации: компактирование уменьшает фрагментацию без вмешательства программиста.
- Портируемость и единый модель поведения на разных платформах.
Недостатки сборщика мусора:
- Недетерминированное время освобождения: нельзя точно предсказать момент уничтожения объекта (проблемно для реального времени и управления ресурсами).
- Паузы и латентность: полные или частичные паузы GC могут быть от нескольких миллисекунд до секунд — типично от $\sim 1\text{–}10$ ms до $\sim 1$ s в тяжёлых сценариях, хотя современные низколатентные GC снижают паузы.
- Накладные расходы: дополнительные CPU и память (для хипа, метаданных, вспомогательных структур), overhead на барьеры записи и синхронизацию.
- Менее прямой контроль над памятью: трудно оптимизировать распределение/выделение под специфические требования (реальное время, низкая задержка), приходится использовать обходные пути (off-heap, пул объектов).
- Проблемы финализаторов и ресурсов: финализаторы ненадёжны и непредсказуемы; нужно явное закрытие внешних ресурсов.
- Возможная фрагментация/рост хипа: при некопирующих коллекторах или при активном удержании объектов хип может расти.
Коротко о выборе: сборщик удобен для большинства приложений (сервера, веб, десктоп), повышает надёжность и скорость разработки; ручное управление (или строгие модели владения, как в Rust) остаётся актуальным при жёстких требованиях по латентности, детерминированности и ограниченным ресурсам.