Я думаю, ваш вопрос не о времени постановки в очередь, на самом деле.
Рассмотрите Уведомление Документация пакета
Через некоторое время после того, как сборщик мусора определит, что достижимость референта изменилась на значение, соответствующее типу ссылки, он добавит ссылку в связанную очередь.
(Примечание«через некоторое время»)
и аналогично, все ссылочные типы имеют оператор вида:
Предположим, что сборщик мусора определяет в определенный момент времени, что объектслабо достижим. В это время он будет атомарно очищать все слабые ссылки на этот объект и все слабые ссылки на любые другие слабодоступные объекты, из которых этот объект доступен через цепочку сильных и мягких ссылок. В то же время он объявит, что все ранее слабо достижимые объекты были завершены. В то же время или в более позднее время он будет ставить в очередь те недавно очищенные слабые ссылки, которые зарегистрированы в очередях ссылок.
(взято из WeakReference
; обратите внимание на«В то же время или в более позднее время»)
На практике сборщик мусора передает обнаруженные ссылки на другой поток, который асинхронно выполняет постановку в очередь. Поскольку неопределенная задержка делает порядок, в котором приложение будет извлекать ссылки из очереди, недетерминированным, бессмысленно спрашивать о порядке здесь.
Однако, я полагаю, вы на самом деле интересуетесь другими « определенный момент времени », когда« сборщик мусора определяет, что достижимость референта изменилась на значение, соответствующее типу ссылки », и решит очистить ссылки атомарнои сделать их пригодными для постановки в очередь.
Когда существует несколько различных ссылочных объектов различного типа, включая Finalizer
ссылку, но нет строгой ссылки, возможны два сценария:
- Есть хотя бы одна мягкая ссылка, и нет никакого давления памяти. Затем сборщик мусора может решить, не ясно, соотв. ставить в очередь любые ссылки.
- Мягких ссылок нет или сборщик мусора решает, что нехватка памяти оправдывает очистку мягких ссылок. Затем все мягкие и слабые ссылки очищаются, и все мягкие, слабые ссылки и ссылки финализатора передаются в очередь.
Только фантомные ссылки остаются без изменений.
Обратите внимание, что однаждыфинализация началась, ссылки Finalizer
больше нет, но во время финализации может быть создана новая мягкая или слабая ссылка. Таким образом, результирующие сценарии такие же, как и при оптимизированной обработке объектов, имеющих тривиальный метод finalize()
. Может быть смесь мягких, слабых и фантомных ссылок без ссылки Finalizer
. Когда нет острой сильной ссылки, у нас снова есть два возможных сценария:
- Существует по крайней мере одна мягкая ссылка, и нет никакого давления памяти. Затем сборщик мусора может решить, не ясно, соотв. ставить в очередь любые ссылки.
- Мягких ссылок нет, или сборщик мусора решает, что нехватка памяти оправдывает очистку мягких ссылок. Затем все мягкие, слабые и фантомные ссылки очищаются A , а все мягкие, слабые и фантомные ссылки передаются в очередь.
* 1061Фантомные ссылки * A очищаются в Java 9 или новее. В предыдущих версиях они ставились в очередь только без очистки.