JVM (tracing, generational) — принципы
- Память: управляемая куча разделена на поколения (например, Young/Old/Metaspace). Основная идея — «большинство объектов умирает молодыми».
- Молодое поколение: часто используют копирующие сборщики (copying): живые объекты копируются в другую область, остальное свободно; это быстро и уменьшает фрагментацию.
- Старое поколение: применяют mark-and-sweep + compact (или concurrent compacting): фаза маркировки живых объектов, затем удаление немаркированных, возможная компактификация для устранения фрагментации.
- Коллекторы: с «stop‑the‑world» паузами (старые Parallel/Serial) или конкурентные без больших пауз (G1, ZGC, Shenandoah): конкурентная маркировка/перемещение объектов, минимизация задержек.
- Дополнительно: сбор слабых/мягких/фантомных ссылок (WeakReference, SoftReference, PhantomReference) и ReferenceQueue; finalizers/finalize (не рекомендуется).
- Поведение: сборка выполняется недетерминированно — время освобождения памяти не гарантировано; при нехватке памяти выбрасывается OutOfMemoryError.
Reference counting — принципы
- Для каждого объекта хранится счётчик ссылок $\text{refCount}$.
- При создании/присвоении ссылки: $\text{refCount}=\text{refCount}+1$. При удалении ссылки: $\text{refCount}=\text{refCount}-1$.
- Объект освобождается сразу, когда $\text{refCount}=0$ (детерминированное освобождение).
- Плюсы: предсказуемое время освобождения, простота реализации; удобно для детерминированного разрушения (RAII).
- Минусы: накладные операции (часто атомарные) при многопоточности; не собирает циклические зависимости (например A→B и B→A при внешних ссылках отсутствуют), требуется дополнительная детекция циклов или алгоритмы для их устранения.
Какие классы ошибок устраняются
- Устраняет ошибки, связанные с явным освобождением памяти: отсутствие «use-after-free», dangling pointers, double-free. В управляемой среде доступ к уже освобождённой памяти как правило невозможен (нет неопределённого поведения С/С++).
- Уменьшает вероятность ошибок из‑за неправильного ручного управления памятью (например, неправильно расчётанный free).
Какие остаются
- Утечки памяти логического характера: удержание живых ссылок — объекты считаются достижимыми и не собираются (в JVM — сильные ссылки, в RC — циклы). В RC циклы особенно проблемны.
- OutOfMemoryError / исчерпание памяти при большом объёме живых объектов.
- Негарантированное время освобождения (в tracing GC освобождение недетерминировано; в RC оно детерминировано, но может быть дорого).
- Производственные проблемы: паузы GC, фрагментация, накладные стоимости (атомарные операции в RC), латентность.
- Ошибки нативного кода: сегфолты, переполнение буфера, corrupt memory — GC не защищает код на C/C++ или JNI.
- Утечки ресурсов, не управляемых сборщиком (файловые дескрипторы, сокеты, соединения) — GC не закрывает автоматически внешние ресурсы (если только классы явно не делают это в finalize/try-with-resources).
- Конкурентные ошибки (гонки), логические баги алгоритмов, дедлоки — не исправляются GC/RC.
Короткое сравнение
- Tracing (JVM): собирает циклы, недетерминированное освобождение, может иметь паузы/конкурентные реализации; хорошо для автоматического управления большими программами.
- Reference counting: детерминированное освобождение, простота, но не собирает циклы без доп. механизмов; может иметь высокую стоимость при многопоточности.
Вывод (в две строки)
- GC (tracing) и RC устраняют классы ошибок, связанные с ручным управлением памятью (use‑after‑free, double‑free, dangling pointers).
- Остаются утечки из‑за удержания ссылок / циклов (особенно в RC), исчерпание памяти, ошибки нативного кода, утечки внешних ресурсов и проблемы производительности/латентности.