i Java sletter affaldssamleren automatisk de ubrugte genstande for at frigøre hukommelsen. Udviklere har ikke behov for at markere objekterne til sletning, hvilket er fejlbehæftet og sårbart over for hukommelseslækage. Så det er fornuftigt Java har ingen destruktorer til rådighed.
hvis objekterne holder åbne stikkontakter, åbne filer eller databaseforbindelser, kan affaldssamleren ikke genvinde disse ressourcer. Vi kan frigive ressourcerne i tæt metode og bruge prøv endelig syntaks til at kalde metoden bagefter før Java 7, såsom I/O-klasserne FileInputStream og FileOutputStream. Fra Java 7 kan vi implementere interface Autokloserbar og bruge Erklæring om forsøg med ressourcer til at skrive kortere og renere kode. Men det er muligt, at API-brugerne glemmer at kalde den tætte metode, så færdiggørelsesmetoden og renere klasse kommer til at fungere som sikkerhedsnet. Men vær opmærksom på, at de ikke svarer til destruktøren.
det er ikke sikret, at både færdiggørelsesmetoden og renere klassen kører hurtigt. De får endda ingen chance for at løbe, før JVM går ud. Selvom vi kunne ringe til systemet.runfinalisering for at foreslå, at JVM kører færdiggørelsesmetoderne for alle objekter, der afventer færdiggørelse, er det stadig ikke-deterministisk. Desuden kan færdiggørelsesmetoden forårsage ydelsesproblemer, deadlocks osv. Vi kan finde mere information ved at se på en af vores artikler: en Guide til færdiggørelsesmetoden i Java. Fra Java 9 tilføjes renere klasse for at erstatte færdiggørelsesmetoden på grund af de ulemper, den har. Som et resultat har vi bedre kontrol over tråden, der udfører rengøringshandlingerne. Men java spec påpeger opførsel af rengøringsmidler under systemet.afslut er implementeringsspecifik, og Java giver ingen garantier for, om rengøringshandlinger vil blive påberåbt eller ej.
