Есть ли деструктор для Java?

Есть ли деструктор для Java? Кажется, я не могу найти никакой документации по этому вопросу. Если нет, как я могу достичь того же эффекта?

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

Будучи обычно программистом на C / C ++, я думал, что это будет тривиально реализовать. (И, следовательно, я планировал реализовать его в последний раз.) Я структурировал свою программу так, чтобы все объекты с возможностью сброса находились в одном классе, чтобы я мог просто уничтожить все «живые» объекты при нажатии кнопки сброса.

Я думал, что если бы все, что я делал, это просто разыменовывал данные и ждал, когда сборщик мусора соберет их, не будет ли утечка памяти, если мой пользователь неоднократно вводит данные и нажимает кнопку сброса? Я также думал, что поскольку Java достаточно зрел как язык, должен быть способ предотвратить это или изящно справиться с этим.

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

Существует наследуемый метод finalize, который вызывается, но он вызывается исключительно по усмотрению сборщика мусора. Таким образом, для классов, которые должны явно привести в порядок, соглашение состоит в том, чтобы определить метод close и использовать finalize только для проверки работоспособности (то есть, если close не был вызван, сделайте это сейчас и зарегистрируйте ошибку).

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

Посмотрите на инструкцию " попробуй с ресурсами" . Например:

try (BufferedReader br = new BufferedReader(new FileReader(path))) {
  System.out.println(br.readLine());
} catch (Exception e) {
  ...
} finally {
  ...
}

Здесь ресурс, который больше не нужен, освобождается в BufferedReader.close()методе. Вы можете создать свой собственный класс, который реализует AutoCloseableи использовать его аналогичным образом.

Это утверждение более ограничено, чем finalizeс точки зрения структурирования кода, но в то же время делает код более простым для понимания и сопровождения. Кроме того, нет никакой гарантии, что finalizeметод вызывается вообще во время работы приложения.

Нет, здесь нет деструкторов. Причина в том, что все объекты Java выделены в куче и мусор. Без явного освобождения (т. Е. Оператора удаления C ++) не существует разумного способа реализации реальных деструкторов.

Java поддерживает финализаторы, но они предназначены для использования только в качестве защиты для объектов, содержащих дескриптор собственных ресурсов, таких как сокеты, дескрипторы файлов, дескрипторы окон и т. Д. Когда сборщик мусора собирает объект без финализатора, он просто отмечает память регион как свободный и все тут. Когда у объекта есть финализатор, он сначала копируется во временное местоположение (помните, мы собираем мусор здесь), затем он помещается в очередь, ожидающую завершения, а затем поток финализатора опрашивает очередь с очень низким приоритетом. и запускает финализатор.

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

Следует избегать использования методов finalize () . Они не являются надежным механизмом очистки ресурсов, и их использование может привести к проблемам в сборщике мусора.

Если вам требуется вызов освобождения в вашем объекте, скажем, для освобождения ресурсов, используйте явный вызов метода. Это соглашение можно увидеть в существующих API (например, Closeable , Graphics.dispose () , Widget.dispose () ) и обычно вызывается через try / finally.

Resource r = new Resource();
try {
    //work
} finally {
    r.dispose();
}

Попытки использовать удаленный объект должны вызвать исключение времени выполнения (см. IllegalStateException ).

РЕДАКТИРОВАТЬ:

Я думал, что если бы я просто разыскивал данные и ждал, когда сборщик мусора соберет их, не будет ли утечка памяти, если мой пользователь неоднократно вводит данные и нажимает кнопку сброса?

Как правило, все, что вам нужно сделать, это разыменовать объекты - по крайней мере, так оно и должно работать. Если вы беспокоитесь о сборке мусора, ознакомьтесь с настройкой сборки мусора виртуальной машины Java SE 6 HotSpot [tm] (или эквивалентным документом для вашей версии JVM).

С выпуском Java 1.7 у вас теперь есть дополнительная опция использования try-with-resourcesблока. Например,

public class Closeable implements AutoCloseable {
    @Override
    public void close() {
        System.out.println("closing..."); 
    }
    public static void main(String[] args) {
        try (Closeable c = new Closeable()) {
            System.out.println("trying..."); 
            throw new Exception("throwing..."); 
        }
        catch (Exception e) {
            System.out.println("catching..."); 
        }
        finally {
            System.out.println("finalizing..."); 
        } 
    }
}

Если выполнить этот класс, c.close()будет выполняться , когда tryблок остается, и до того , как catchи finallyблоки выполняются. В отличие от случая, finalize()метод close()гарантированно будет выполнен. Однако нет необходимости выполнять это явно в finallyпредложении.

Я полностью согласен с другими ответами, говоря не полагаться на выполнение финализации.

В дополнение к блокам try-catch-finally вы можете использовать Runtime # addShutdownHook (представленный в Java 1.3) для выполнения окончательных очисток в вашей программе.

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

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

Нет, java.lang.Object#finalizeэто самое близкое, что вы можете получить.

Однако когда (и если) он вызывается, это не гарантируется.
Видеть:java.lang.Runtime#runFinalizersOnExit(boolean)

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

Вы можете быть уведомлены после того, как объект был уничтожен, используя java.lang.ref.PhantomReference (фактически, сказать, что он был уничтожен, может быть немного неточным, но если фантомная ссылка на него помещена в очередь, то он больше не подлежит восстановлению, что обычно составляет тоже самое). Общее использование:

• Разделите ресурсы в вашем классе, которые нужно разрушить, на другой вспомогательный объект (обратите внимание, что если все, что вы делаете, это закрытие соединения, что является обычным случаем, вам не нужно писать новый класс: соединение, которое будет закрыто, будет в этом случае "вспомогательным объектом").
• Когда вы создаете свой основной объект, создайте для него также PhantomReference. Либо обратитесь к новому вспомогательному объекту, либо настройте карту из объектов PhantomReference к соответствующим вспомогательным объектам.
• После того, как основной объект собран, PhantomReference ставится в очередь (или, скорее, он может быть поставлен в очередь - как у финализаторов, нет никаких гарантий, что он когда-либо будет, например, если виртуальная машина выйдет, то она не будет ждать). Убедитесь, что вы обрабатываете его очередь (либо в специальном потоке, либо время от времени). Из-за жесткой ссылки на вспомогательный объект вспомогательный объект еще не был собран. Поэтому сделайте все, что вам угодно, для объекта-помощника, затем отбросьте PhantomReference, и помощник в конечном итоге также будет собран.

Есть также finalize (), который выглядит как деструктор, но не ведет себя как один. Обычно это не очень хороший вариант.

finalize()Функция деструктор.

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

Кроме того, требуется более одного GC для освобождения объектов, которые имеют finalize().

Вы должны попытаться очистить логические места в вашем коде, используя try{...} finally{...}операторы!

Я согласен с большинством ответов.

Вы не должны зависеть полностью от либо finalizeилиShutdownHook

финализации

1. JVM не гарантирует, когда этот finalize()метод будет вызван.

2. finalize()вызывается только один раз потоком GC. Если объект восстанавливается из метода финализации, он finalizeбольше не будет вызываться.

3. В вашем приложении вы можете иметь несколько живых объектов, для которых сборка мусора никогда не вызывается.

4. Все, Exceptionчто выброшено методом финализации, игнорируется потоком GC

5. System.runFinalization(true)и Runtime.getRuntime().runFinalization(true)методы увеличивают вероятность вызова finalize()метода, но теперь эти два метода устарели. Эти методы очень опасны из-за недостаточной безопасности потока и возможного создания тупика.

shutdownHooks

public void addShutdownHook(Thread hook)

Регистрирует новый хук отключения виртуальной машины.

Виртуальная машина Java отключается в ответ на два вида событий:

1. Программа завершается нормально, когда завершается последний поток, не являющийся демоном, или когда System.exitвызывается метод exit (эквивалентно ), или
2. Виртуальная машина прерывается в ответ на пользовательское прерывание, такое как ввод ^ C, или общесистемное событие, такое как выход пользователя из системы или завершение работы системы.
3. Хук отключения - это просто инициализированный, но не запущенный поток. Когда виртуальная машина начинает свою последовательность выключения, она запускает все зарегистрированные обработчики завершения работы в неустановленном порядке и позволяет им запускаться одновременно. Когда все перехватчики завершены, он будет запускать все непроверенные финализаторы, если финализация при выходе была включена.
4. Наконец, виртуальная машина остановится. Обратите внимание, что потоки демона будут продолжать работать во время последовательности завершения работы, как и потоки, не являющиеся демонами, если завершение работы было инициировано путем вызова метода выхода.

5. Отключающие крюки также должны быстро закончить свою работу. Когда программа вызывает выход, ожидается, что виртуальная машина будет быстро закрыта и завершит работу.

   Но даже в документации Oracle указано, что

В редких случаях виртуальная машина может прерваться, то есть прекратить работу без выключения

Это происходит, когда виртуальная машина завершается извне, например, при SIGKILLсигнале в Unix или при TerminateProcessвызове в Microsoft Windows. Виртуальная машина также может прервать работу, если собственный метод не работает, например, из-за повреждения внутренних структур данных или попытки доступа к несуществующей памяти. Если виртуальная машина прерывает работу, то нельзя гарантировать, будут ли запущены какие-либо перехватчики завершения работы.

Вывод : используйте try{} catch{} finally{}блоки соответствующим образом и высвобождайте критические ресурсы в finally(}блоке. Во время освобождения ресурсов в finally{}блоке catch Exceptionи Throwable.

Если вы беспокоитесь только о памяти, не надо. Просто доверьтесь GC, он делает достойную работу. Я действительно видел кое-что о том, что он настолько эффективен, что для производительности было бы лучше создавать кучи крошечных объектов, чем использовать большие массивы в некоторых случаях.

Возможно, вы можете использовать блок try ... finally, чтобы завершить объект в потоке управления, в котором вы используете объект. Конечно, это не происходит автоматически, но и уничтожение в C ++ не происходит. Вы часто видите закрытие ресурсов в блоке finally.

В Ломбоке есть аннотация @Cleanup, которая в основном напоминает деструкторы C ++:

@Cleanup
ResourceClass resource = new ResourceClass();

При обработке (во время компиляции) Lombok вставляет соответствующий try-finallyблок, который resource.close()вызывается, когда выполнение выходит из области видимости переменной. Вы также можете явно указать другой метод освобождения ресурса, например resource.dispose():

@Cleanup("dispose")
ResourceClass resource = new ResourceClass();

Ближайшим эквивалентом деструктора в Java является метод finalize () . Большая разница с традиционным деструктором заключается в том, что вы не можете быть уверены, когда он будет вызван, поскольку это является обязанностью сборщика мусора. Я настоятельно рекомендую внимательно прочитать это перед использованием, поскольку ваши типичные шаблоны RAIA для файловых дескрипторов и т. Д. Не будут надежно работать с finalize ().

Здесь много хороших ответов, но есть дополнительная информация о том, почему вы должны избегать использования finalize () .

Если JVM завершает работу из-за System.exit()или Runtime.getRuntime().exit(), финализаторы не будут запускаться по умолчанию. Из Javadoc для Runtime.exit () :

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

Вы можете позвонить, System.runFinalization()но это только делает все возможное, чтобы завершить все незавершенные финализации - не гарантия.

Есть System.runFinalizersOnExit()метод, но не используйте его - он небезопасен, давно устарел.

Если вы пишете Java-апплет, вы можете переопределить метод Applet "destroy ()". Это...

 * Called by the browser or applet viewer to inform
 * this applet that it is being reclaimed and that it should destroy
 * any resources that it has allocated. The stop() method
 * will always be called before destroy().

Очевидно, не то, что вы хотите, но может быть то, что ищут другие люди.

Просто подумав об исходном вопросе ... который, я думаю, мы можем сделать вывод из всех других изученных ответов, а также из существенной Блоха Эффективной Java , пункт 7, «Избегать финализаторов», ищет решение законного вопроса таким образом, чтобы не подходит для языка Java ...:

... не было бы довольно очевидным решением сделать то, что на самом деле хочет ОП - сохранить все ваши объекты, которые должны быть сброшены, в виде «игрового автомата», на который все другие не сбрасываемые объекты имеют ссылки только через какой-то вид объекта доступа ...

И затем, когда вам нужно «сбросить», вы отключаете существующий манеж и создаете новый: вся паутина объектов в манеже отбрасывается по течению, никогда не возвращается и однажды будет собрана GC.

Если какой-либо из этих объектов Closeable(или нет, но у него есть closeметод), вы можете поместить их Bagв манеж в момент их создания (и, возможно, открытия), и последним действием аксессора перед тем, как отрезать манеж, будет через все Closeablesзакрывающие их ...?

Код, вероятно, будет выглядеть примерно так:

accessor.getPlaypen().closeCloseables();
accessor.setPlaypen( new Playpen() );

closeCloseablesВероятно, это будет метод блокировки, возможно, включающий защелку (например CountdownLatch), для обработки (и ожидания в случае необходимости) любых Runnables/ Callablesв любых потоках, специфичных Playpenдля завершения, в зависимости от ситуации, в частности в потоке JavaFX.

Хотя в технологии Java GC были достигнуты значительные успехи, вы все равно должны помнить о своих ссылках. Вспоминаются многочисленные случаи, казалось бы, тривиальных эталонных образцов, которые на самом деле являются гнездами крыс под капотом.

Из вашего поста не похоже, что вы пытаетесь реализовать метод сброса для повторного использования объекта (верно?). Содержат ли ваши объекты какие-либо другие типы ресурсов, которые необходимо очистить (т. Е. Потоки, которые должны быть закрыты, любые объекты пула или заимствованные объекты, которые должны быть возвращены)? Если единственное, что вас беспокоит, это освобождение памяти, то я бы пересмотрел структуру своего объекта и попытался бы убедиться, что мои объекты являются автономными структурами, которые будут очищены во время GC.

В Java нет точно класса деструктора, класс уничтожается в Java автоматически сборщиком мусора. но вы можете сделать это, используя ниже один, но это не совсем то же самое:

финализации ()

Был вопрос, который породил углубленное обсуждение финализации , так что вы должны получить больше глубины, если требуется ...

Ни в Java нет деструкторов. Основной причиной этого в Java являются сборщики мусора, которые всегда пассивно работают в фоновом режиме, и все объекты создаются в динамической памяти, где и работает GC. В c ++ мы Явно нужно вызвать функцию удаления, так как нет такой вещи, как сборщик мусора.

Раньше я в основном имел дело с C ++, и это также привело меня к поиску деструктора. Я сейчас использую JAVA. То, что я сделал, и это, возможно, не лучший случай для всех, но я реализовал свой собственный деструктор, сбросив все значения до 0 или там по умолчанию через функцию.

Пример:

public myDestructor() {

variableA = 0; //INT
variableB = 0.0; //DOUBLE & FLOAT
variableC = "NO NAME ENTERED"; //TEXT & STRING
variableD = false; //BOOL

}

В идеале это не будет работать для всех ситуаций, но там, где есть глобальные переменные, это будет работать, пока у вас их нет.

Я знаю, что я не лучший Java-программист, но, похоже, он мне подходит.