Как Java сборщик мусора работает с циклическими ссылками, когда их путь доступа не работает?

Question

Я просто хочу, чтобы кто-нибудь объяснил мне, что, как GC обнаруживает, что эти блоки памяти (изображенные в красной области) являются мусором, когда их счетчик ссылок больше 0, но они практически недоступны?

Answer 1

Существует множество «корневых объектов», которые считаются всегда доступными: например, ссылки на потоки, статические переменные, ссылки на классы. Если какой-либо объект не может быть достигнут по ссылке ссылок из этих корневых объектов, он считается доступным для GC, даже если есть некоторые ссылки на этот объект.

Answer 2

GarbageCollector работает на основе Java Memory Model. В Java доступное приложение памяти делится на две части: куча и стек. Объект хранится в динамической памяти и доступен двумя способами: -

1) Объект может иметь ссылочную переменную, которая хранится в памяти стека. В этом случае к объекту можно получить прямой доступ с помощью его ссылочной переменной.

2) Объект может содержаться любым другим объектом и не иметь ссылки в памяти стека. В этом случае доступ к этому объекту возможен только с помощью этого объекта-контейнера. Таким образом, если объект контейнера является сборщиком мусора, то этот объект должен иметь право на сборку мусора.

Выполняя GarbageCollection, GarbageCollector проверяет, доступен ли объект прямо или косвенно по любой ссылке, доступной в стеке, если он есть, то он не будет собирать этот объект, иначе он его соберет.

Answer 3

Детали алгоритма GC зависят от реализации в Java, поэтому это зависит от вашей виртуальной машины. Но большинство виртуальных машин не используют подсчет ссылок. Официальная виртуальная машина даже имеет несколько настраиваемых алгоритмов. Так что об этом сложно обобщать.