Сопоставляют ли циклы ссылок в Java замедлять сборку мусора или влияют на память / производительность? [Дубликат]

yes Java Сборщик мусора обрабатывает циркулярную ссылку!

How?

Существуют специальные объекты, называемые корнями сбора мусора (корни GC).

Простое Java-приложение имеет следующие корни GC:

1. Локальные переменные в основном методе
2. Основной поток
3. Статические переменные основного класса

[/g1]

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

1. Алгоритм проходит все ссылки на объекты, начиная с корней GC, и маркирует каждый найденный объект как живой.
2. Вся память кучи, которая не является занятые отмеченными объектами.

Таким образом, если какой-либо объект недоступен из корней GC (даже если он является самореферентным или циклическим), он

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

[/g2]

Источник: Управление памятью Java

Билл ответил на ваш вопрос напрямую. Как сказал Амнон, ваше определение сбора мусора - это просто подсчет ссылок. Я просто хотел добавить, что даже очень простые алгоритмы, такие как сборка меток и подметания и копирования, легко обрабатывают циклические ссылки. Итак, ничего волшебного в этом нет!

Вы правы. Конкретная форма сбора мусора, которую вы описываете, называется « подсчет ссылок ». То, как это работает (концептуально, по крайней мере, большинство современных реализаций подсчета ссылок фактически реализовано совсем по-другому) в простейшем случае выглядит следующим образом:

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

И эта простая стратегия имеет именно ту проблему, которую вы описываете: если ссылки A B и B ссылки A, то оба их подсчета ссылок могут никогда быть меньше 1, что означает, что они wil Я никогда не собираюсь собраться.

Существует четыре способа решения этой проблемы:

1. Игнорировать. Если у вас достаточно памяти, ваши циклы малы и нечасты, а время выполнения короткое, возможно, вам удастся просто не собирать циклы. Подумайте о интерпретаторе сценария оболочки: сценарии оболочки обычно запускаются в течение нескольких секунд и не выделяют много памяти.
2. Объедините свой счетный сборщик мусора с другим сборщиком мусора , который не работает У меня проблемы с циклами. CPython делает это, например: главный сборщик мусора в CPython является сборщиком подсчета ссылок, но время от времени трассировочный сборщик мусора запускается для сбора циклов.
3. Обнаружение циклов. К сожалению, обнаружение циклов на графике является довольно дорогостоящей операцией. В частности, он требует почти столько же накладных расходов, что и коллекционер трассировки, поэтому вы могли бы использовать один из них.
4. Не реализуйте алгоритм наивным образом, как вы и я: поскольку в 1970-х годах было разработано несколько довольно интересных алгоритмов, которые объединяют обнаружение циклов и подсчет ссылок в одной операции умным способом, который значительно дешевле, чем либо делать их как отдельно, либо делать трассирующий коллектор.

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

Поскольку цикл доступен только внутри себя, но недоступен из набора корней, он будет собран.

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

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

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

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