Почему метод finalize() устарел в Java 9?

Хотя вопрос был о методе Object.finalize, на самом деле речь идет о механизме завершение в целом. Этот механизм включает в себя не только поверхностный API Object.finalize, но также включает спецификации языка программирования о жизненном цикле объектов и практическое влияние на реализацию сборщиков мусора в JVM.

Много было написано о том, почему финализацию трудно использовать с точки зрения приложения. См. вопросы Зачем вам когда-либо реализовывать finalize()? и Следует ли предпочесть Java 9 Cleaner финализации? и ответы на них. См. также Эффективная Java, 3-е издание Джошуа Блоха, пункт 8.

Вкратце, некоторые моменты о проблемах, связанных с использованием финализаторов:

• их, как известно, трудно правильно запрограммировать

• в частности, они могут запускаться неожиданно, когда объект становится недостижимым неожиданно (но правильно); Например, см. мой ответ на этот вопрос

• финализация может легко нарушить отношения подкласса/суперкласса

• нет порядка среди финализаторов

• метод finalize данного объекта вызывается JVM не более одного раза, даже если этот объект «воскрес»

• отсутствуют гарантии своевременности доработки или даже то, что он будет работать вообще

• нет явного механизма регистрации или отмены регистрации

Выше перечислены сложности с использованием финализации. Любой, кто рассматривает возможность использования финализации, должен пересмотреть свое решение, учитывая приведенный выше список проблем. Но достаточно ли этих проблем, чтобы отказаться от финализации на платформе Java? Есть несколько дополнительных причин, описанных в разделах ниже.

Завершение потенциально делает системы хрупкими

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

(Правка 2021-09-16: этот вопрос описывает проблему, когда система нормально работает при низкой нагрузке, но дает сбой при высокой нагрузке, вероятно, потому, что относительная скорость выделения превышает скорость завершения при высокой нагрузке.)

Завершение способствует проблемам безопасности

SEI CERT Стандарт кодирования Oracle для Java имеет правило MET12-J: не используйте финализаторы. (Обратите внимание, это сайт о безопасном кодировании.) В частности, там говорится

Improper use of finalizers can result in resurrection of garbage-collection-ready objects and result in denial-of-service vulnerabilities.

Oracle Руководство по безопасному кодированию для Java SE более подробно описывает потенциальные проблемы безопасности, которые могут возникнуть при завершении. В этом случае это не проблема с кодом, использующим финализацию. Вместо этого можно использовать финализацию злоумышленником для атаки на чувствительный код, который не защитил себя должным образом. В частности, Руководство 7-3 / ОБЪЕКТ-3 частично утверждает,

Partially initialized instances of a non-final class can be accessed via a finalizer attack. The attacker overrides the protected finalize method in a subclass and attempts to create a new instance of that subclass. This attempt fails ... but the attacker simply ignores any exception and waits for the virtual machine to perform finalization on the partially initialized object. When that occurs the malicious finalize method implementation is invoked, giving the attacker access to this, a reference to the object being finalized. Although the object is only partially initialized, the attacker can still invoke methods on it....

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

Финализация усложняет спецификации

Платформа Java определяется несколькими спецификациями, включая спецификации языка, виртуальной машины и API библиотеки классов. Влияние финализации тонко распространяется на все это, но оно постоянно дает о себе знать. Например, финализация очень тонко взаимодействует с созданием объекта (что уже достаточно сложно). Завершение также появилось в общедоступных API-интерфейсах Java, а это означает, что эволюция этих API-интерфейсов (до сих пор) требовалась, чтобы оставаться совместимыми с ранее указанным поведением. Развитие этих спецификаций удорожается наличием доработки.

Финализация усложняет реализацию

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

Резюме

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

На момент написания этой статьи (04.06.2019) нет конкретного плана по удалению финализации из Java. Тем не менее, это, безусловно, намерение сделать это. Мы объявили метод Object.finalize устаревшим, но не пометили его для удаления. Это формальная рекомендация программистам прекратить использование этого механизма. Неофициально известно, что финализацию использовать нельзя, но формальный шаг сделать, конечно же, необходимо. Кроме того, некоторые методы finalize в библиотечных классах (например, ZipFile.finalize) объявлены устаревшими «для удаления», что означает, что поведение финализации этих классов может быть удалено из будущего выпуска. В конце концов, мы надеемся отключить финализацию в JVM (возможно, сначала опционально, а затем по умолчанию), и в какой-то момент в будущем действительно удалить реализацию финализации из сборщиков мусора.

(Редактировать 2021-11-03: JEP 421 только что был опубликован, в котором предлагается отказаться от финализации для удаления. На момент написания статьи он находится в состоянии «кандидат», но я ожидаю, что он будет продвигаться вперед. Устаревание, добавленное этим JEP, является официальным уведомлением. эта финализация будет удалена в какой-то момент в последующем выпуске Java. Возможно, неудивительно, что материал в этом ответе и в JEP частично совпадает, хотя JEP более точен и описывает умеренную эволюцию нашего мышления по этой теме. .)