i Java raderar sopsamlaren automatiskt de oanvända objekten för att frigöra minnet. Utvecklare behöver inte markera objekten för radering, vilket är felaktigt och sårbart för minnesläckan. Så det är förnuftigt Java har inga destruktorer tillgängliga.
om objekten har öppna uttag, öppna filer eller databasanslutningar kan sophämtaren inte återta dessa resurser. Vi kan släppa resurserna i close method och använda try-finally syntax för att ringa metoden efteråt före Java 7, till exempel i/O-klasserna FileInputStream och FileOutputStream. Från och med Java 7 kan vi implementera gränssnitt Autokloserbart och använda try-with-resources-uttalande för att skriva kortare och renare kod. Men det är möjligt att API-användarna glömmer att ringa close-metoden, så att finalize-metoden och Cleaner-klassen uppstår för att fungera som säkerhetsnät. Men var försiktig att de inte motsvarar destructor.
det är inte säkert att både finalize-metoden och Cleaner-klassen kommer att köras omedelbart. De får till och med ingen chans att springa innan JVM lämnar. Även om vi kunde ringa systemet.runFinalization för att föreslå att JVM kör finalize-metoderna för alla objekt som väntar på slutförande, är det fortfarande icke-deterministiskt. Dessutom kan finalize-metoden orsaka prestandaproblem,deadlocks etc. Vi kan hitta mer information genom att titta på en av våra artiklar: en Guide till finalize-metoden i Java. Från och med Java 9 läggs Cleaner class till för att ersätta finalize-metoden på grund av nackdelarna den har. Som ett resultat har vi bättre kontroll över tråden som gör rengöringsåtgärderna. Men java spec påpekar beteendet hos städare under systemet.exit är implementeringsspecifikt och Java ger inga garantier om rengöringsåtgärder kommer att åberopas eller inte.
