2014-01-03 6 views
3

Я получаю суть ссылочных объектов в Java и основные отличия между мягкими, слабыми и фантомными ссылочными объектами.Java: Требуется уточнение в API-документе для ссылочных объектов

Однако, я не в полной мере понять следующие моменты из API Docs

  1. из API док для WeakReference<T>:

    «Слабые опорные объекты, которые не мешают их референты из составляется окончательный вариант, завершено, а затем исправлено. "

    Теперь термины в жирного не были объяснены нигде в API Docs, так интересно, что они точно средний, особенно в отношении понятия более или менее DEPRECATED Object.finalize() метода доработки.

  2. Из API док для Reference<T>:

    public void clear(): «Этот метод вызывается только Java кода, когда сборщик мусора очищает ссылки он делает так непосредственно, без вызова этого метода

    public boolean enqueue(): «Этот метод вызывается только Java кода, когда сборщик мусора ставит в очередь ссылки он делает так непосредственно, без вызова этого метода

    Опять же, я не знаю, что подразумевается под «Java-код» в 2 выше цитаты: Внутренний код виртуальной машины Java, к которым у меня нет доступа? Или код JDK, к которому я имею доступ только для чтения/просмотра? Или собственный код Java конечного пользователя?

    "непосредственно, без вызова этого метода" часть сообщает мне, что JVM не нужно вызывать эти методы. С другой стороны, «только по коду Java» говорит мне, что это не код Java конечного пользователя, а скорее JVM (если это означает код конечного пользователя, тогда мы будем находить эту фразу, замусоренную весь документ API почти для каждого метода каждого класса Java!). Итак, какая интерпретация правильная и кто может назвать эту функцию?

ответ

3

"Слабые ссылки на объекты, которые не препятствуют их референты из делаются финализируемых, доработан, а затем утилизирован."

Это все этапы процесса сбора мусора. Сначала объекты становятся отмеченными как окончательные, чтобы сказать, что нет сильных ссылок на них. Затем вызывается finalize(), и они помечены как финализированные, а затем, наконец, память восстанавливается.

public void clear(): «Этот метод вызывается только кодом Java, когда сборщик мусора очищает ссылки, он делает это напрямую, без вызова этого метода».

Это говорит, что, когда вы, как программист решил очистить ссылку, то метод clear() используется, чтобы сделать это, однако, если вы подкласс WeakReference и переопределить метод clear вы не увидите виртуальная машина вызова, что когда объект был удален.

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

1
  • "финализируемых, завершена, и затем утилизирован." означает мусора.
  • «только по java-коду» означает вызов из самой программы (включая JDK) - то есть у вас может быть какой-то код, который вызывает ref.clear();. Это также объясняет, что GC (т. Е. JVM) эффективно очищает ссылку, но с другим механизмом, который не вызывает метод clear. Например, если вы переопределяете clear, чтобы быть не-op, GC все равно сможет «свести на нет» ссылку.
+0

Спасибо, но мне нравится ответ Тима на «окончательный вариант, завершенный, исправленный». Очевидно, что есть какая-то разница, иначе документы не станут настолько подробными. +1 для пояснения «java code». – Harry

Смежные вопросы