In Java, il garbage collector elimina automaticamente gli oggetti non utilizzati per liberare la memoria. Gli sviluppatori non hanno bisogno di contrassegnare gli oggetti per l’eliminazione, che è soggetta a errori e vulnerabile alla perdita di memoria. Quindi è ragionevole Java non ha distruttori disponibili.
Nel caso in cui gli oggetti contengano socket aperti, file aperti o connessioni al database, il garbage collector non è in grado di recuperare tali risorse. Possiamo rilasciare le risorse nel metodo close e utilizzare la sintassi try-finally per chiamare il metodo in seguito prima di Java 7, come le classi I / O FileInputStream e FileOutputStream. A partire da Java 7, possiamo implementare l’interfaccia AutoCloseable e utilizzare l’istruzione try-with-resources per scrivere codice più breve e più pulito. Ma è possibile che gli utenti API dimentichino di chiamare il metodo close, quindi il metodo finalize e la classe Cleaner entrano in esistenza per fungere da rete di sicurezza. Ma si prega di essere avvertiti che non sono equivalenti al distruttore.
Non è garantito che sia il metodo finalize che la classe Cleaner verranno eseguiti prontamente. Non hanno nemmeno la possibilità di correre prima che la JVM esca. Anche se potremmo chiamare il sistema.runFinalization per suggerire che JVM esegua i metodi finalize di qualsiasi oggetto in attesa di finalizzazione, è ancora non deterministico. Inoltre, il metodo finalize può causare problemi di prestazioni, deadlock ecc. Possiamo trovare maggiori informazioni guardando uno dei nostri articoli: Una Guida al metodo finalize in Java. A partire da Java 9, la classe Cleaner viene aggiunta per sostituire il metodo finalize a causa degli aspetti negativi che ha. Di conseguenza, abbiamo un migliore controllo sul filo che esegue le azioni di pulizia. Ma la specifica java sottolinea il comportamento dei detergenti durante il sistema.exit è specifico per l’implementazione e Java non fornisce alcuna garanzia se le azioni di pulizia verranno invocate o meno.
