2016-12-29 17 views
0

Я слышал, что в книге Джошуа Блоха написано, что сбор и сбор памяти могут быть увеличены до 430 раз, если мы переопределим метод finalize.Почему фаза распределения может быть увеличена, если мы переопределим метод finalize?

Для меня ясно, что сбор памяти может работать медленнее, потому что дополнительная итерация требуется для gc для освобождения памяти.

Но почему фаза распределения может быть увеличена?

+0

Сначала я бы сделал некоторое исследование по этой теме и проверил, если вы найдете что-нибудь об этом ... написано после год 2000 или около того. Имейте в виду, что наиболее известные думают, что Блок работал ... похожи на 15 лет назад. ** С тех пор на java-платформе произошло много **. – GhostCat

+0

Я не понимаю, почему распределение было бы дороже. Очистка создает объекты для добавления объекта в очередь завершения. –

+0

Выделение может занять больше времени, потому что более вероятно, что придется ждать циклов GC, вызванных нетривиальными переопределениями 'finalize()'. –

ответ

0

Я искал оригинальное утверждение:

На моей машине время, чтобы создать и уничтожить простой объект около 5,6 нс. Добавление финализатора увеличивает время до 2400 нс. Другими словами, это около в 430 раз медленнее, чтобы создавать и уничтожать объекты с финализаторами.

Так что это не общее утверждение, а просто отчет о доказательствах, который предполагает, что за ним стоит шаблон, а не то, что число воспроизводимо. Этот фактор, вероятно, изменится при использовании не так-тривиальных объектов или просто их намного больше.

Конечно, эти затраты зависят от того, как выполняется окончательная доработка. В HotSpot экземпляр Finalizer будет создан путем вызова метода Finalizer.register каждый раз, когда создается объект с нетривиальным методом finalize().

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

Когда дело доходит до «разрушения», восстановление обычного объекта - это не-op. Никаких действий не будет предпринято, и на самом деле невозможно сделать что-либо с недостижимым объектом, так как это недоступно. Особые состояния достижимости можно встретить только при наличии объекта Reference достижимого уровня, например, упомянутого выше объекта Finalizer, который содержит ссылку на конкретный объект (в то время как объект не встречался ни по какой другой обычной ссылке. Затем объект Reference может быть (одна из) нити (-ов) финализатора могут предпринять соответствующие действия.

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