В какой момент Garbage Collector понимает что объект больше не нужен

Алгоритмы определения "неживых" объектов в Android (Java/Kotlin)

Garbage Collector (GC) не "понимает" момент, когда объект больше не нужен, в реальном времени. Вместо этого он периодически выполняет анализ графа объектов, чтобы обнаружить те, которые не могут быть достигнуты из "корней" (GC Roots). Этот процесс называется определение жизнеспособности (liveness determination) и является фундаментальным для всех современных сборщиков мусора.

Ключевые принципы: GC Roots и достижимость

GC начинает работу с фиксированного списка корневых точек (GC Roots). В Android/Java это включает:

• Локальные переменные в активных стеках методов (т.е., текущие вызовы методов всех потоков)
• Статические поля классов (глобальные переменные)
• Активные Java/Kotlin потоки и их контексты
• Ссылки из JNI (Java Native Interface) глобального уровня
• Специальные системные объекты (например, мониторы синхронизации)

Все объекты, напрямую или косвенно доступные из этих корней, считаются живыми (live). Любой объект, не достижимый через любую цепочку ссылок из GC Roots, автоматически считается мертвым (dead) и подлежит сборке.

Пример процесса достижимости в коде

Рассмотрим ситуацию на Kotlin:

class User(val name: String) {
    var friend: User? = null
}

fun main() {
    // Объект 'alice' является GC Root (локальная переменная в активном стеке)
    val alice = User("Alice")
    
    // Объект 'bob' достижим через 'alice.friend'
    alice.friend = User("Bob")
    
    // Объект 'charlie' создан, но не присвоен корню или его потомкам
    val charlie = User("Charlie") // После окончания метода станет недостижимым
    
    // Удаляем ссылку на 'bob' из цепочки достижимости
    alice.friend = null
    
    // Теперь 'bob' НЕ достижим из GC Roots (alice не ссылается на него)
    // При следующем цикле GC объект 'bob' будет признан мертвым
}

После выполнения main():

• alice остается живой, так как является локальной переменной (GC Root) во время выполнения метода (но после завершения метода тоже станет недостижимой, если не была возвращена или сохранена).
• bob становится недостижимым после alice.friend = null и будет удален GC.
• charlie создается, но не связывается с корневой цепочкой, поэтому также будет удален.

Алгоритмы обнаружения в разных GC Android

В Android используется несколько реализаций GC, и алгоритмы определения жизнеспособности немного отличаются:

1. До Android 5.0 (ART предварительно) - Dalvik с Stop-the-World GC:

   • Использует прямой анализ графа ссылок (mark-and-sweep).
   • Приостанавливает все потоки, сканирует корни, помечает достижимые объекты.
   • Все не помеченные объекты считаются мертвыми.

2. ART (Android Runtime) - современные алгоритмы:

   • Concurrent Mark-Sweep (CMS) - выполняет маркировку параллельно с работой приложения.
   • Generational Collection - разделяет объекты по "возрасту" (Young/Old поколения).

     * В **Young Generation** объекты считаются мертвыми после одного цикла, если не выжили.
     * В **Old Generation** используется более глубокий анализ достижимости.

Момент актуализации информации

Ключевой момент: GC не отслеживает каждый удаление ссылки в реальном времени. Вместо этого, информация о достижимости актуализируется во время цикла сборки (GC cycle). Это происходит:

• При явном вызове System.gc() (но в Android это не рекомендуется).
• При автоматическом триггере - когда память заполняется или система обнаруживает высокую нагрузку на выделение.
• По расписанию - в зависимости от алгоритма GC (например, в фоновом потоке в ART).

Особенности для Android разработчика

1. Утечки памяти создают ложную "жизненность":

   // Пример утечки через статическое поле
   public class MemoryLeak {
       static List<Object> leakCache = new ArrayList<>();
       
       void leak(Object obj) {
           leakCache.add(obj); // Объект всегда достижим из статического корня!
       }
   }
   

   Объекты в leakCache всегда достижимы из GC Root (статического поля), поэтому GC никогда их не удалит.

2. Слабые ссылки (WeakReference) позволяют объектам быть достижимыми, но не препятствуют сборке:

   val weakRef = WeakReference(heavyObject)
   // GC может удалить heavyObject, даже если weakRef существует,
   // потому что WeakReference не считается "сильной" GC Root.
   

Таким образом, GC "понимает" что объект больше не нужен только во время цикла сборки, через алгоритмы анализа достижимости от корневых точек. Для Android разработчика критически важно избегать создания ложных цепочек достижимости (утечек памяти) и понимать разницу между сильными и слабыми ссылками.