Удалит ли Garbage Collector два объекта ссылающихся друг на друга

Удалит ли Garbage Collector два объекта, ссылающихся друг на друга?

Да, Garbage Collector (GC) в Java (и, соответственно, в Android) удалит два объекта, ссылающихся друг на друга, если на них больше нет ссылок из так называемых "живых" корневых объектов (Garbage Collection Roots). Это классический пример циклической ссылки, который часто обсуждается в контексте работы сборщика мусора. Современные GC, используемые в Java/Android, такие как Generational Garbage Collector (в стандартной JVM) или Concurrent Mark-Sweep (CMS), G1, а на Android — ART с его преимущественно moving GC (например, Concurrent Copying GC), успешно справляются с обнаружением и очисткой таких циклических зависимостей.

Как это работает: алгоритмы обнаружения

Основной принцип работы GC — определение достижимости объектов от корневых точек (GC Roots). К корневым точкам относятся:

• Активные потоки исполнения (Thread).
• Статические переменные в классах.
• Локальные переменные в стеке вызовов (стеке потоков).
• JNI-ссылки.
• И другие системные корни.

Если от этих корней нельзя достичь объекта (или группы объектов) через цепочку ссылок, то такие объекты считаются недостижимыми и подлежат удалению, даже если они ссылаются друг на друга.

Рассмотрим пример циклической ссылки:

public class Node {
    private Node next;
    
    public void setNext(Node next) {
        this.next = next;
    }
}

// Создание циклической ссылки
Node node1 = new Node();
Node node2 = new Node();
node1.setNext(node2);
node2.setNext(node1);

// Обнуляем внешние ссылки
node1 = null;
node2 = null;

// В этот момент GC может безопасно удалить оба объекта,
// так как они недостижимы из корней.

После обнуления node1 и node2 оба объекта Node становятся недостижимыми, несмотря на их взаимные ссылки. Сборщик мусора, используя алгоритмы вроде mark-and-sweep (или его оптимизированных версий), пометит только достижимые объекты, начиная с корней. Поскольку ни node1, ни node2 не достижимы, они не будут помечены и будут удалены на фазе очистки (sweep).

Особенности на Android

На Android, в среде выполнения ART (Android Runtime), используется преимущественно moving garbage collector (например, начиная с Android 8+ — Concurrent Copying GC). Его ключевые особенности:

• Алгоритм пометки-и-копирования (mark-and-copy): GC помечает живые объекты, затем копирует их в другое пространство памяти, освобождая старое. Циклические ссылки не мешают этому процессу, так как недостижимые объекты просто не копируются.
• Циклические ссылки не проблема: ART, как и большинство современных сборщиков, не использует простой подсчёт ссылок (reference counting), который уязвим для циклических зависимостей. Вместо этого применяются алгоритмы tracing GC (следящие за достижимостью), которые игнорируют циклические ссылки между недостижимыми объектами.
• Производительность: ART оптимизирован для мобильных устройств, с минимизацией пауз (stop-the-world). Обнаружение циклических ссылок не требует дополнительных вычислительных затрат по сравнению с обычными объектами.

Важные нюансы

Хотя GC справляется с циклическими ссылками, есть ситуации, когда утечки памяти всё же возможны:

• Использование неправильных ссылок: Например, если один из объектов в цикле зарегистрирован как слушатель (Listener) в глобальной системе и не отписывается, то весь цикл останется достижимым.
• Статические ссылки: Если один из объектов хранится в статическом поле, то он становится корневым сам по себе, и весь цикл будет жить.
• Использование WeakReference или SoftReference: Для управления памятью в случаях, когда нужно избежать удержания объектов, можно применять слабые ссылки. Они не предотвращают удаление GC, но это уже инструмент для решения специфических задач (кэширование, обработка контекстов в Android).

Вывод

Современные Garbage Collector'ы, включая используемые в Android, эффективно удаляют объекты с циклическими ссылками, если эти объекты недостижимы из корневых точек. Это одно из ключевых преимуществ алгоритмов tracing GC перед простым подсчётом ссылок. Разработчикам Android следует фокусироваться не на циклических ссылках как таковых, а на обеспечении правильного времени жизни объектов — избегая утечек через статические поля, контексты активности, неотписанные слушатели и подобные долгоживущие корни.