Java - Как может сборщик мусора быстро узнать, какие объекты больше не имеют ссылок на них?

Я понимаю, что в Java, если у объекта больше нет ссылок на него, сборщик мусора вернет его через некоторое время позже.

Но как сборщик мусора знает, что у объекта есть или нет ссылок, связанных с ним?

Может ли сборщик мусора использовать какой-либо хэш файл или таблицу?

Edit:

Обратите внимание, что я не спрашиваю, как работает gc. действительно, я не прошу об этом.

Я спрашиваю специально, что Как gc знает, какие объекты живут и которые мертвы, с эффективностью.

Вот почему я говорю в своем вопросе, что gc поддерживает какой-то хэш файл или набор и постоянно обновляет количество ссылок, которые имеет объект?

Ответ 1

Типичная современная JVM использует несколько различных типов сборщиков мусора.

Один тип, который часто используется для объектов, которые были вокруг какое-то время, называется Mark-and-Sweep. В основном это начинается с известных "живых" объектов (так называемых корней сбора мусора), следуя всем целям ссылок на объекты и маркируя каждый доступный объект как "живой".

Как только это будет сделано, этап развертки может вернуть те объекты, которые не были помечены как "живые".

Чтобы этот процесс работал, JVM должен знать местоположение в памяти каждой ссылки на объект. Это необходимое условие, чтобы сборщик мусора был precise (который есть Java).

Ответ 2

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

Большое резюме можно найти в статье "Как сборка мусора работает в Java" , но для реального низкого уровня вы должны смотреть на Tuning Garbage Collection с виртуальной машиной 5.0 Java [tm]

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

Начиная с платформы J2SE версии 1.2, виртуальная машина включила множество различных алгоритмов сбора мусора, которые объединены с использованием коллекций поколений. Хотя наивная сборка мусора рассматривает каждый живой объект в куче, коллекция поколений использует несколько эмпирически наблюдаемых свойств большинства приложений, чтобы избежать дополнительной работы.

Наиболее важным из этих наблюдаемых свойств является младенческая смертность....

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

Для получения более актуальных руководств по настройке ознакомьтесь с:

Кстати, будьте осторожны, пытаясь догадаться о своей стратегии сбора мусора, я знаю много производительности программ, которые могут быть сорваны чрезмерно усердным использованием System.gc() или неприемлемых параметров -XX.

Ответ 3

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

Но вы можете запросить GC очень вежливо, используя System.gc(). Это всего лишь подсказка для системы. GC не должен запускаться в этот момент, он не должен удалять ваш конкретный объект и т.д. Поскольку GC - БОЛЬШОЙ босс, и мы (программисты Java) - это просто его подчиненные...: (