Java-ban a szemétgyűjtő automatikusan törli a fel nem használt objektumokat, hogy felszabadítsa a memóriát. A fejlesztőknek nem kell megjelölniük az objektumokat törlésre, ami hibára hajlamos és érzékeny a memóriaszivárgásra. Tehát ésszerű, hogy a Java nem rendelkezik destruktorokkal.
abban az esetben, ha az objektumok nyitott aljzatokat, megnyitott fájlokat vagy adatbázis-kapcsolatokat tartanak fenn, a szemétgyűjtő nem tudja visszaszerezni ezeket az erőforrásokat. Felszabadíthatjuk az erőforrásokat a close metódusban, és a try-finally szintaxist használhatjuk a metódus későbbi meghívására a Java 7 előtt, például az I/O osztályok FileInputStream és FileOutputStream. Mivel a Java 7, tudjuk végrehajtani interfész AutoCloseable és használja try-with-resources nyilatkozatot írni rövidebb és tisztább kódot. De lehetséges, hogy az API felhasználók elfelejtik meghívni a close metódust, így a finalize metódus és a Cleaner osztály jön létre, hogy biztonsági hálóként működjön. De figyelmeztetlek, hogy nem egyenértékűek a destruktorral.
nem biztos, hogy mind a finalize metódus, mind a Cleaner osztály azonnal futni fog. Még esélyt sem kapnak a futásra, mielőtt a JVM kilép. Bár hívhatnánk a rendszert.runFinalization azt sugallja, hogy a JVM futtatja a véglegesítésre váró objektumok véglegesítési módszereit, még mindig nem determinisztikus. Ezenkívül a véglegesítési módszer teljesítményproblémákat, holtpontokat stb. További információt az egyik cikkünkben találhatunk: útmutató a Java véglegesítési módszeréhez. A Java 9-től kezdve a Cleaner osztály hozzáadódik a véglegesítési módszer helyettesítéséhez a hátrányai miatt. Ennek eredményeként jobban tudjuk ellenőrizni a szálat, amely elvégzi a tisztítási műveleteket. De a java spec rámutat a tisztítószerek viselkedésére a rendszer során.az exit implementáció specifikus, és a Java nem garantálja, hogy a tisztítási műveletek meghívásra kerülnek-e vagy sem.
