Коротко: метод `finalize()` ненадёжен и не должен использоваться для гарантированного освобождения ресурсов. Ниже — почему, как сборщик мусора влияет на поведение и современные альтернативы.
Почему `finalize()` ненадёжен
- Неопределённое время вызова: нет гарантий, когда (или будет ли) `finalize()` вызвано — может быть очень поздно или не вызвано вовсе (например, при завершении JVM).
- Вызывается не более одного раза для данного объекта (не более $1$ раза). При воскрешении объекта `finalize()` повторно, как правило, не выполняется.
- Может возродить объект (resurrection), что усложняет логику и отложенную сборку.
- Задерживает сборку: объект помечается для финализации и остаётся живым дольше, пока финализатор не обработает очередь.
- Выполняется в отдельном фоновом потоке (обычно в одном потоке), поэтому долгие `finalize()` блокируют обработку других финализируемых объектов.
- Исключения в `finalize()` игнорируются JVM (не пробрасываются обратно в вызывающий код) — это может скрывать ошибки.
- Производительность и безопасность: финализаторы добавляют накладные расходы, могут стать вектором атак и усложняют предсказуемость программы.
- Начиная с Java $9$ метод `finalize()` помечен как deprecated.
Влияние сборщика мусора на поведение программ
- Поведение освобождения ресурсов становится недетерминированным: программы не должны полагаться на GC для освобождения критичных ресурсов (файлы, сокеты, дескрипторы, блоки памяти в нативе).
- Зависимости от `System.gc()` или `System.runFinalization()` ненадёжны — JVM может игнорировать или оптимизировать эти вызовы.
- Наличие финализаторов увеличивает частоту и продолжительность пауз при сборке мусора и память, занятую "ожидающими" финализируемыми объектами.
- Отладка утечек усложняется: объекты могут оставаться живыми из‑за финализаторов или ссылок в очередях финализации.
Современные альтернативы (рекомендации)
- Явное освобождение + AutoCloseable + try-with-resources (детерминированное закрытие ресурсов):
Пример:
public class A implements AutoCloseable {
@Override
public void close() { System.out.println("close"); }
}
try (A a = new A()) {
// использование
} // close() гарантированно вызовется
- java.lang.ref.Cleaner (введён в Java $9$): безопаснее, легче контролировать; регистрируется задача очистки, не умеет воскрешать объект и не использует `finalize()`:
Схема:
private static final Cleaner cleaner = Cleaner.create();
private final Cleaner.Cleanable cleanable;
public A(Resource r) {
this.cleanable = cleaner.register(this, () -> r.release());
}
public void close() {
cleanable.clean();
}
- PhantomReference + ReferenceQueue: низкоуровневый механизм для случаев, когда нужен полный контроль за порядком/моментом освобождения нативных ресурсов.
- Явные методы `close()`/`dispose()` и документирование обязанностей (вызвать `close()`): делегируйте ответственность вызывающему коду, используйте паттерны RAII‑подобные через try-with-resources.
- Как запасной механизм (not primary), можно использовать Cleaner для автоматической компенсации при забытом `close()`, но не полагаться на него для корректности.
Резюме и практическая рекомендация
- Не используйте `finalize()` для управления ресурсами; он ненадёжен и дорог.
- Всегда предоставляйте явные методы освобождения ресурсов (реализуйте `AutoCloseable`) и используйте try-with-resources.
- Если нужен автоматический резервный механизм — используйте `Cleaner` или PhantomReference, но рассматривайте это как запасной механизм, а не замену явному закрытию.