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

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

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

Сборщик мусора использует какую-то хэш-карту или таблицу?

Edit:

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

я спрашиваюspecifically То, как gc знает, какие объекты живы, а какие мертвы, с эффективностью.

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

 Jackson Tale15 мая 2012 г., 13:24
@ ErnestFriedman-Hill, дело в том, что этот пост не отвечает на мой вопрос.
 Ernest Friedman-Hill14 мая 2012 г., 19:05
возможный дубликатTheory and algorithm behind Java garbage collection
 Ernest Friedman-Hill15 мая 2012 г., 13:21
Это как раз «основная теория сбора мусора».
 Jackson Tale15 мая 2012 г., 12:55
@ ErnestFriedman-Hill нет, этот вопрос не является дубликатом дляstackoverflow.com/questions/4141237/… Я не спрашиваю основную теорию для сбора мусора. Вместо этого я спрашиваю конкретно о том, как сборщик мусора может управлять количеством ссылок, которые объект имеет в настоящее время, поэтому позже сборщик может легко решить, вернуть его обратно или нет.

Ответы на вопрос(3)

но все они в основном работают, отслеживая, какие объектыreachable из известных активных объектов.

Отличное резюме можно найти в статьеКак работает сборка мусора в Java но на самом деле вы должны смотреть наНастройка сборки мусора с помощью виртуальной машины Java [tm] 5.0

An object is considered garbage when it can no longer be reached from any pointer in the running program. The most straightforward garbage collection algorithms simply iterate over every reachable object. Any objects left over are then considered garbage. The time this approach takes is proportional to the number of live objects, which is prohibitive for large applications maintaining lots of live data.

Beginning with the J2SE Platform version 1.2, the virtual machine incorporated a number of different garbage collection algorithms that are combined using generational collection. While naive garbage collection examines every live object in the heap, generational collection exploits several empirically observed properties of most applications to avoid extra work.

The most important of these observed properties is infant mortality. ...

То есть многие объекты, такие как итераторы, живут очень короткое время, поэтомуyounger Объекты с большей вероятностью будут иметь право на сборку мусора, чем более старые объекты.

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

Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide (Java SE 8)

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

Решение Вопроса

в мусора.

Один тип, который часто используется для объектов, которые были вокруг некоторое время, называетсяМарк-и-стреловидность, Это в основном включает в себя начало с известного "живого" объекты (так называемыеgarbage collection roots), следуя всем цепочкам ссылок на объекты и помечая каждый достижимый объект как "живой".

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

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

 Jackson Tale15 мая 2012 г., 12:56
То есть, вы имеете в виду, что каждый раз, когда gc собирается выполнить очистку, он будет сканировать все объекты в памяти (следуя процессу Mark and Sweep)? Это эффективно?
 15 мая 2012 г., 12:58
Эффективнее по сравнению с чем?
 15 мая 2012 г., 13:05
@JacksonTale: единственный способ узнать, является ли проблема чем-то, состоит в том, чтобы измерить это. Это то, для чего нужны профилировщики (они могут многое рассказать вам о том, что происходит с GC.)
 Jackson Tale15 мая 2012 г., 13:00
Я имею в виду, что если у меня в памяти миллионы объектов, я буду изображать каждый раз, когда полное сканирование может быть неэффективным.

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

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

 14 мая 2012 г., 19:13
+1 к правлению ГК. Мусор Чакноррис только получает проблемы, но никогда не принимает заказов. Это как запросить услугу и получить ответ, когда сервер решит.

Ваш ответ на вопрос