Czy istnieje destruktor dla Javy?

Nie, żadnych destruktorów. Powodem jest to, że wszystkie obiekty Javy są przydzielane i zbierane śmieci. Bez wyraźnej dealokacji (np. operatora delete C++) nie ma sensownego sposobu implementacji rzeczywistych destruktorów.

Java obsługuje finalizery, ale są one przeznaczone tylko do ochrony obiektów posiadających uchwyt do natywnych zasobów, takich jak gniazda, uchwyty plików, uchwyty okien itp. Gdy garbage collector zbiera obiekt bez finalizera, po prostu zaznacza obszar pamięci jako wolny i to wszystko. Gdy obiekt ma finalizer, jest najpierw kopiowany do tymczasowej lokalizacji( pamiętajmy, że tutaj zbieramy śmieci), następnie jest pytany o kolejkę oczekującą na finalizację, a następnie wątek Finalizera sprawdza kolejkę z bardzo niskim priorytetem i uruchamia finalizer.

Gdy aplikacja zakończy działanie, JVM zatrzymuje się bez czekania na finalizowanie oczekujących obiektów, więc praktycznie nie ma gwarancji, że finalizatory kiedykolwiek będą działać.

Jeśli używasz Javy 7, spójrz na try-with-resources . Na przykład:

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

Tutaj zasób, który nie jest już potrzebny, jest uwolniony w metodzie BufferedReader.close(). Możesz utworzyć własną klasę, która implementuje AutoCloseable i używać jej w podobny sposób.

To stwierdzenie jest bardziej ograniczone niż finalize pod względem struktury kodu, ale jednocześnie sprawia, że kod jest łatwiejszy do zrozumienia i utrzymania. Ponadto, nie ma gwarancji, że metoda finalize jest wywoływana w ogóle podczas livetime aplikacji.

Należy unikać stosowania metod finalize () . Nie są one niezawodnym mechanizmem czyszczenia zasobów i możliwe jest spowodowanie problemów w garbage collector poprzez ich nadużywanie.

Jeśli potrzebujesz wywołania dealokacji w swoim obiekcie, np. aby zwolnić zasoby, użyj jawnego wywołania metody. Konwencję tę można zobaczyć w istniejących API (np. Closeable, grafika.usunąć(), Widget.dispose () ) i jest zwykle wywoływana poprzez spróbuj / wreszcie.

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

Próby użycia usuniętego obiektu powinny rzucić wyjątek runtime (zobacz IllegalStateException ).

EDIT:

Myślałem, że gdybym tylko aby odczytać dane i poczekać na zbieracz śmieci do ich zbierania, czy nie byłoby wycieku pamięci, gdyby mój użytkownik wielokrotnie wprowadzał dane i nacisnąłeś przycisk resetowania?

Ogólnie rzecz biorąc, wszystko, co musisz zrobić, to dereferować obiekty - przynajmniej jest to tak jak powinno działać. Jeśli martwisz się o garbage collection, sprawdź Java SE 6 HotSpot[TM] Virtual Machine Garbage Collection Tuning (lub odpowiedni dokument dla twojej wersji JVM).

W wersji Java 1.7 masz teraz dodatkową opcję użycia bloku try-with-resources. Na przykład,

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..."); 
        } 
    }
}

Jeśli wykonasz tę klasę, c.close() zostanie wykonana, gdy try zostanie pozostawiony Blok, A przed catch i finally zostaną wykonane bloki. W przeciwieństwie do metody finalize(), close() jest gwarantowana do wykonania. Nie ma jednak potrzeby wykonywania go jawnie w klauzuli finally.

W pełni zgadzam się z innymi odpowiedziami, twierdząc, że nie polegam na wykonaniu finalize.

Oprócz bloków try-catch-finally, możesz użyć Runtime#addShutdownHook (wprowadzonych w Javie 1.6), aby wykonać końcowe czyszczenie w swoim programie.

To nie to samo, co destruktory , ale można zaimplementować hook zamykania z zarejestrowanymi obiektami słuchacza, na których można wywoływać metody czyszczenia (zamykanie trwałych połączeń z bazą danych, usuwanie blokad plików itp.) - rzeczy, które normalnie byłyby wykonywane w destruktorach . Ponownie - nie jest to zamiennik dla konstruktorów, ale w niektórych przypadkach można podejść do pożądanej funkcjonalności z tym.

Zaletą tego jest posiadanie zachowania dekonstrukcyjnego luźno powiązanego z resztą programu.

Nie, java.lang.Object#finalize jest najbliżej jak możesz.

Jednakże, kiedy (i jeśli) jest wywołane, nie jest gwarantowane.
Zobacz też: java.lang.Runtime#runFinalizersOnExit(boolean)

Po pierwsze, zauważ, że ponieważ Java jest zbierana ze śmieci, rzadko trzeba coś zrobić w sprawie niszczenia obiektów. Po pierwsze dlatego, że zwykle nie masz zarządzanych zasobów do uwolnienia, a po drugie dlatego, że nie możesz przewidzieć, kiedy lub czy to się stanie, więc jest to nieodpowiednie dla rzeczy, które musisz zrobić "tak szybko, jak nikt już nie używa mojego obiektu".

Możesz zostać powiadomiony po zniszczeniu obiektu za pomocą Javy.lang.Nr ref.PhantomReference (właściwie mówiąc, że został destroyed może być nieco niedokładny, ale jeśli w kolejce znajduje się odniesienie phantom, to nie można go już odzyskać, co zwykle oznacza to samo). Powszechnym zastosowaniem jest:

• oddziel zasoby w swojej klasie, które należy zniszczyć do innego obiektu pomocniczego (zauważ, że jeśli wszystko co robisz to zamykanie połączenia, co jest powszechnym przypadkiem, nie musisz pisać nowej klasy: połączenie, które ma być zamknięte, będzie "obiektem pomocniczym" w tym przypadku).
• Kiedy Stwórz swój główny obiekt, Stwórz do niego Fantomreferencję. Albo odnieś to do nowego obiektu pomocniczego, albo skonfiguruj mapę z obiektów PhantomReference do odpowiadających im obiektów pomocniczych.
• Po zebraniu głównego obiektu, Phantomreferencja jest w kolejce(a raczej może być w kolejce - jak finalizatory nie ma gwarancji, że kiedykolwiek będzie, na przykład jeśli VM zakończy działanie, to nie będzie czekać). Upewnij się, że przetwarzasz kolejkę (albo w specjalnym wątku, albo od czasu do czasu). Ze względu na twarde odniesienie do obiektu pomocniczego, obiekt pomocniczy nie został jeszcze zebrany. Więc zrób to, co chcesz na obiekcie pomocniczym, a następnie odrzuć PhantomReference, a pomocnik ostatecznie zostanie również zebrany.

Istnieje również funkcja finalize (), która wygląda jak Destruktor, ale nie zachowuje się tak. Zazwyczaj nie jest to dobra opcja.

Przepraszam, jeśli to odbiega od głównego tematu, ale java.util.Timer (SE6) dokumentacja mówi:

" po tym, jak ostatnie aktywne odniesienie do obiektu timera zniknie, a wszystkie zaległe zadania zostaną wykonane, wątek wykonywania zadań timera zakończy się z wdziękiem (i zostanie poddany zbieraniu śmieci). Może to jednak trwać arbitralnie długo. Domyślnie wątek wykonywania zadań nie jest uruchamiany jako wątek demona, więc jest w stanie utrzymać aplikację przed kończę. Jeśli wywołujący chce szybko zakończyć wątek wykonania zadania timera, wywołujący powinien wywołać metodę cancel timera..."

Chciałbym wywołać cancel, gdy Klasa posiadająca Timer traci swoją ostatnią referencję(lub immeditalesky przed). Tutaj niezawodny Destruktor może to dla mnie zrobić. Powyższe komentarze wskazują, że w końcu jest kiepski wybór, ale czy istnieje eleganckie rozwiązanie? Tego biznesu"...zdolne do utrzymania aplikacji przed zakończeniem..."nie jest atrakcyjne.

Jeśli to tylko pamięć, o którą się martwisz, nie rób tego. po prostu zaufaj GC, że robi przyzwoitą robotę. Faktycznie widziałem coś o tym, że jest tak wydajny, że może być lepiej dla wydajności tworzyć sterty małych obiektów niż używać dużych tablic w niektórych przypadkach.

Funkcja finalize() jest destruktorem.

Nie powinno być jednak normalnie używane, ponieważ jest wywoływane po GC i nie można powiedzieć, kiedy to nastąpi (jeśli w ogóle).

Ponadto potrzeba więcej niż jednego GC do dealokacji obiektów, które mają finalize().

Powinieneś spróbować oczyścić miejsca logiczne w kodzie używając try{...} finally{...} instrukcji!

Zgadzam się z większością odpowiedzi.

Nie powinieneś w pełni polegać na finalize lub ShutdownHook

Finalize

1. JVM nie gwarantuje, kiedy ta metoda finalize() zostanie wywołana.

2. finalize() zostanie wywołana tylko raz przez wątek GC jeśli obiekt ożywia się z metody Finalize, to finalize nie zostanie wywołana ponownie.

3. W swojej aplikacji możesz mieć kilka żywych obiektów, na których zbieranie śmieci nigdy nie jest / align = "left" /

4. Każdy wyjątek jest wyrzucany metodą finalizacji jest ignorowany przez wątek GC

5. System.runFinalization(true) i Runtime.getRuntime().runFinalization(true) metody zwiększają prawdopodobieństwo wywołania finalize() metody, ale teraz te dwie metody zostały wycofane. Metody te są bardzo niebezpieczne ze względu na brak bezpieczeństwa wątku i możliwe tworzenie impasu.

ShutdownHooks

public void addShutdownHook(Thread hook)

Rejestruje nowy hook zamykania maszyny wirtualnej.

The Java virtual machine wyłącza się w odpowiedzi na dwa rodzaje zdarzeń: [16]}

1. Program kończy się normalnie, gdy kończy się ostatni wątek nie-demona lub gdy kończy się (równoważnie, System.exit) wywołana jest Metoda, lub
[24]}maszyna wirtualna zostaje zakończona w odpowiedzi na przerwanie użytkownika, takie jak wpisanie ^C, lub zdarzenie systemowe, takie jak wylogowanie użytkownika lub zamknięcie systemu.
2. hak zamykania to po prostu zainicjowany, ale nie rozpoczęty wątek. Kiedy maszyna wirtualna uruchomi swój Sekwencja zamykania uruchomi wszystkie zarejestrowane Hooki zamykania w nieokreślonej kolejności i pozwoli im działać jednocześnie. Po zakończeniu wszystkich hooków uruchomione zostaną wszystkie niepowiązane finalizery, jeśli opcja finalization-on-exit została włączona.
3. wreszcie, maszyna wirtualna zatrzyma się. Należy pamiętać, że wątki demona będą nadal działać podczas sekwencji zamykania, podobnie jak wątki nie-demona, jeśli zamknięcie zostało zainicjowane przez wywołanie metody exit.

4. Haki zamykające powinny również szybko Zakończ swoją pracę. Gdy program wywoła exit, oczekuje się, że maszyna wirtualna natychmiast się wyłączy i zakończy działanie.

   Ale nawet dokumentacja Oracle zacytowała, że

W rzadkich przypadkach maszyna wirtualna może przerwać działanie, to znaczy przestać działać bez wyłączania czysto

Występuje, gdy maszyna wirtualna jest zakończona zewnętrznie, na przykład sygnałem SIGKILL w systemie Unix lub wywołaniem TerminateProcess w systemie Microsoft Windows. Na maszyna wirtualna może również przerwać działanie, jeśli natywna metoda nie działa, na przykład przez uszkodzenie wewnętrznych struktur danych lub próbę uzyskania dostępu do nieistniejącej pamięci. Jeśli maszyna wirtualna przerywa działanie, nie można zagwarantować, czy zostaną uruchomione żadne Hooki zamykania.

wniosek : użyj bloków try{} catch{} finally{} odpowiednio i uwolnij krytyczne zasoby w bloku finally(}. Podczas uwalniania zasobów w bloku finally{}, złapać Exception i Throwable.

Może warto spróbować ... na koniec Zablokuj, aby sfinalizować obiekt w przepływie sterowania, w którym go używasz. Oczywiście nie dzieje się to automatycznie, ale destrukcja w C++też nie. Często widzisz zamykanie zasobów w bloku finally.

Najbliższym odpowiednikiem destruktora w Javie jest Metoda finalize () . Duża różnica w stosunku do tradycyjnego destruktora polega na tym, że nie możesz być pewien, kiedy zostanie wywołany, ponieważ za to odpowiada Śmieciarz. Zdecydowanie zalecam uważne przeczytanie tego przed użyciem, ponieważ typowe wzorce RAIA dla uchwytów plików itp. nie będą działać niezawodnie z finalize ().

Istnieje adnotacja @Cleanup w Lombok, która w większości przypomina destruktory C++:

@Cleanup
ResourceClass resource = new ResourceClass();

Podczas przetwarzania (w czasie kompilacji), Lombok wstawia odpowiedni blok try-finally tak, aby wywoływany był resource.close(), gdy wykonanie opuszcza zakres zmiennej. Można również wyraźnie określić inną metodę zwolnienia zasobu, np. resource.dispose():

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

Mimo że nastąpił znaczny postęp w technologii Java Gc, nadal musisz pamiętać o swoich referencjach. Na myśl przychodzą liczne przypadki pozornie trywialnych wzorców odniesienia, które w rzeczywistości są gniazdami szczurów pod maską.

Z twojego postu nie brzmi to tak, jakbyś próbował zaimplementować metodę reset w celu ponownego użycia obiektu (prawda?). Czy Twoje obiekty posiadają inny rodzaj zasobów, które wymagają oczyszczenia (np. strumienie, które muszą być zamknięte, wszelkie zbiorcze lub pożyczone przedmioty, które muszą zostać zwrócone)? Jeśli jedyną rzeczą, o którą się martwisz, jest dealloc pamięci, to rozważyłbym moją strukturę obiektu i spróbowałbym zweryfikować, że moje obiekty są samowystarczalnymi strukturami, które zostaną wyczyszczone w czasie GC.

Jeśli piszesz aplet Javy, możesz nadpisać aplet metody" destroy ()". Tak...

 * 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().

Zastanawiam się nad pierwotnym pytaniem... co, myślę, że możemy wywnioskować z wszystkich innych wyuczonych odpowiedzi, a także z esencjonalnego Effective Java , punktu 7, "Avoid finalizers", szuka rozwiązania uzasadnionego pytania w sposób, który jest nieodpowiedni dla języka Java...:

... nie byłoby dość oczywistym rozwiązaniem, aby zrobić to, co naprawdę chce OP, aby wszystkie przedmioty, które trzeba zresetować, były w rodzaju "kojca", do którego wszystkie inne obiekty, które nie można zresetować, mają odniesienia tylko za pośrednictwem jakiegoś obiektu dostępowego...

A potem, gdy trzeba "zresetować", odłączyć istniejący kojec i zrobić nowy: cała sieć przedmiotów w kojcu jest wyrzucona, nigdy nie wraca, a pewnego dnia do odbioru przez GC.

Jeśli któryś z tych obiektów jest Closeable (lub nie, ale ma metodę close), możesz umieścić je w Bag w kojcu, gdy są tworzone (i ewentualnie otwierane), a ostatni akt accessor przed odcięciem kojca musiałby przejść przez wszystkie Closeables zamykając je... ?

Kod prawdopodobnie wyglądałby mniej więcej tak:

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

closeCloseables prawdopodobnie byłaby to metoda blokowania, prawdopodobnie polegająca na zatrzasku (np. CountdownLatch), aby poradzić sobie (i czekać odpowiednio na) wszelkie Runnables/Callables w wątkach specyficznych dla Playpen, które mają być odpowiednio zakończone, w szczególności w wątku JavaFX.

Nie istnieje klasa destructor w Javie, Klasa niszczona w Javie automatycznie przez garbage collector . ale można to zrobić używając poniżej jednego, ale to nie to samo:

Finalizuj()

Pojawiło się pytanie , które wywołało dogłębną dyskusję na temat finalize, więc powinieneś uzyskać więcej głębi, jeśli jest to wymagane...

Zajmowałem się głównie C++ i to doprowadziło mnie również do poszukiwania destruktora. Dużo teraz używam Javy. Co zrobiłem, i może nie jest to najlepszy przypadek dla wszystkich, ale zaimplementowałem mój własny Destruktor, resetując wszystkie wartości do 0 lub tam domyślnie przez funkcję.

Przykład:

public myDestructor() {

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

}

Idealnie nie będzie to działać we wszystkich sytuacjach, ale tam, gdzie są zmienne globalne, będzie działać tak długo, jak nie masz ich mnóstwo.

I know I am not Najlepszy programista Javy, ale wydaje mi się, że działa.