Какая ссылка Finalizer (FinalReference) или Weak / Phantom / Soft Reference имеет более высокий приоритет для GC - PullRequest
1 голос
/ 03 октября 2019

Когда создается объект с нетривиальным методом finalize(), JVM создаст Finalizer (FinalReference) с этим объектом в качестве референта. Что произойдет, если этот объект также будет обернут Soft / Weak или Phantom Reference? Будет ли GC пытаться поставить в очередь Finalizer (вызвать метод finalize для него) сначала, а затем поставить в очередь другую ссылку или другую версию?

1 Ответ

2 голосов
/ 23 октября 2019

Я думаю, ваш вопрос не о времени постановки в очередь, на самом деле.

Рассмотрите Уведомление Документация пакета

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

(Примечание«через некоторое время»)

и аналогично, все ссылочные типы имеют оператор вида:

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

(взято из WeakReference; обратите внимание на«В то же время или в более позднее время»)

На практике сборщик мусора передает обнаруженные ссылки на другой поток, который асинхронно выполняет постановку в очередь. Поскольку неопределенная задержка делает порядок, в котором приложение будет извлекать ссылки из очереди, недетерминированным, бессмысленно спрашивать о порядке здесь.

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

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

  1. Есть хотя бы одна мягкая ссылка, и нет никакого давления памяти. Затем сборщик мусора может решить, не ясно, соотв. ставить в очередь любые ссылки.
  2. Мягких ссылок нет или сборщик мусора решает, что нехватка памяти оправдывает очистку мягких ссылок. Затем все мягкие и слабые ссылки очищаются, и все мягкие, слабые ссылки и ссылки финализатора передаются в очередь.
    Только фантомные ссылки остаются без изменений.

Обратите внимание, что однаждыфинализация началась, ссылки Finalizer больше нет, но во время финализации может быть создана новая мягкая или слабая ссылка. Таким образом, результирующие сценарии такие же, как и при оптимизированной обработке объектов, имеющих тривиальный метод finalize(). Может быть смесь мягких, слабых и фантомных ссылок без ссылки Finalizer. Когда нет острой сильной ссылки, у нас снова есть два возможных сценария:

  1. Существует по крайней мере одна мягкая ссылка, и нет никакого давления памяти. Затем сборщик мусора может решить, не ясно, соотв. ставить в очередь любые ссылки.
  2. Мягких ссылок нет, или сборщик мусора решает, что нехватка памяти оправдывает очистку мягких ссылок. Затем все мягкие, слабые и фантомные ссылки очищаются A , а все мягкие, слабые и фантомные ссылки передаются в очередь.

* 1061Фантомные ссылки * A очищаются в Java 9 или новее. В предыдущих версиях они ставились в очередь только без очистки.

...