Какие знаешь механизмы, по которым сборщик мусора определяет, какой объект используется?

Механизмы определения "живых" объектов в сборке мусора (Garbage Collection)

В контексте Android и Java (Kotlin) сборщик мусора (GC) определяет, какие объекты "живы" (используются) и должны быть сохранены, а какие можно удалить, используя комбинацию нескольких фундаментальных механизмов. Основные подходы базируются на понятии достижимости (reachability) объектов от так называемых корневых точек (GC roots).

Корневые точки (GC Roots)

Это специальные объекты или ссылки, которые гарантированно являются "живыми" на протяжении работы программы. Сборщик мусора начинает свой анализ именно с них. Основные типы корневых точек включают:

• Локальные переменные и параметры методов в текущих активных стеках вызовов (frames в stack).
• Активные потоки (Thread объекты) и их локальные переменные.
• Статические поля классов (static variables).
• Ссылки из JNI (Java Native Interface) контекста.
• Системные классы, загруженные загрузчиками классов (Bootstrap Classloader и др.).
• Мониторы (используемые в synchronized блоках).

Ключевые алгоритмы и механизмы анализа

1. Маркировка через достижимость (Reachability Tracing)

Это классический подход большинства GC (например, в CMS, G1, ZGC). Алгоритм работает в две фазы:

Фаза 1: Маркировка (Marking)

• GC начинает обход графа объектов от всех корневых точек.
• Он последовательно проходит по всем ссылкам (полям объектов) и "маркирует" каждый найденный объект как "живой".
• Обход может реализовываться, например, через алгоритм обхода в глубину (DFS).

// Пример графа объектов, который будет анализироваться GC
class Application {
    static Config globalConfig = new Config(); // GC Root (статическое поле)
}

class Activity {
    private View currentView; // Ссылка на другой объект
}

// GC начинает с globalConfig, проходит через все ссылки и маркирует достижимые объекты.

Фаза 2: Очистка (Sweeping)

• После завершения маркировки все не маркированные объекты считаются недостижимыми ("мертвыми") и могут быть удалены.
• Их память либо освобождается сразу, либо помечается для последующего использования.

2. Reference Counting (Счетчик ссылок) - менее распространен в Java/Android

В этом механизме каждый объект имеет внутренний счетчик, который увеличивается при создании новой ссылки на него и уменьшается, когда ссылка уничтожается или переприсваивается. Когда счетчик достигает нуля, объект считается неиспользуемым.

// Концептуальный пример (в Java/Android так не реализовано)
class ReferenceCountedObject {
    private var count: Int = 0

    fun addReference() { count++ }
    fun releaseReference() {
        count--
        if (count == 0) {
            // Объект может быть удален
        }
    }
}

Ограничение: Основная проблема этого метода — циклические ссылки (circular references), где два или более объектов ссылаются друг на друга, но ни один из них не доступен из корневых точек. Их счетчики никогда станут нулевыми, приводя к утечке памяти. Поэтому основные GC в JVM/ART используют tracing алгоритмы, которые корректно обрабатывают такие циклы.

3. Различные уровни достижимости (по типам ссылок Java)

Java предоставляет различные типы ссылок, которые помогают GC в определении "важности" объекта. Помимо обычных Strong References, существуют:

• Soft References (SoftReference): Объекты удаляются только при необходимости освободить память (до возникновения OutOfMemoryError). Используются для кэшей.
• Weak References (WeakReference): Объекты удаляются при следующем проходе сборщика мусора, если на них нет сильных ссылок. Используются для связей, не препятствующих сборке (например, WeakHashMap).
• Phantom References (PhantomReference): Самые "слабые"; используются для отслежиения финализации объекта перед его удалением, обычно для управления ресурсами вне heap.

// Пример использования WeakReference для избежания циклических ссылок
WeakReference<HeavyObject> weakRef = new WeakReference<>(new HeavyObject());
HeavyObject obj = weakRef.get(); // может вернуть null, если GC уже удалил объект

Особенности в Android (ART и Dalvik)

Современный Android Runtime (ART) использует улучшенные версии tracing GC (например, CMS-based, Generational). Ключевые особенности:

• Generational Collection (Поколенная сборка): Объекты разделяются на "молодые" (новые) и "старые" (долгоживущие) поколения. Большинство объектов "умирают" молодыми, поэтому GC чаще сканирует область молодых объектов (Young Generation), что повышает эффективность.
• Многопоточная маркировка и очистка: ART старается выполнять часть работы GC в параллельных потоках для минимизации пауз (Stop-the-World).
• Moving Collectors (с перемещением): Некоторые сборщики в ART могут перемещать "живые" объекты в процессе сборки (компактизация памяти) для борьбы с фрагментацией.

Итог

Таким образом, основной механизм, по которому GC определяет используемый объект — это алгоритм маркировки через достижимость от корневых точек (GC Roots). Этот метод корректно обрабатывает сложные графы объектов, включая циклические ссылки. Дополнительную детализацию и оптимизацию обеспечивают поколенная сборка, различные типы ссылок и параллельные алгоритмы, реализованные в современных виртуальных машинах, таких как ART в Android.