Em Java, o coletor de lixo elimina automaticamente os objetos não utilizados para libertar a memória. Os desenvolvedores não precisam marcar os objetos para exclusão, que são propensos a erros e vulneráveis ao vazamento de memória. Portanto, é sensato que o Java não tenha destruidores disponíveis.
caso os objetos mantenham soquetes abertos, arquivos abertos ou conexões de banco de dados, o coletor de lixo não será capaz de recuperar esses recursos. Podemos liberar os recursos no método close e usar a sintaxe try-finally para chamar o método posteriormente antes do Java 7, como as classes de E/S FileInputStream e FileOutputStream. A partir do Java 7, podemos implementar a interface AutoCloseable e usar a instrução try-with-resources para escrever código mais curto e limpo. Mas é possível que os usuários da API se esqueçam de chamar o método close, então o método finalize e a classe Cleaner passam a existir para atuar como a rede de segurança. Mas, por favor, seja advertido que eles não são equivalentes ao destruidor.
não está garantido que o método finalize e a classe Cleaner serão executados prontamente. Eles até não têm chance de correr antes que a JVM saia. Embora pudéssemos chamar o sistema.runFinalization para sugerir que JVM execute os métodos finalize de quaisquer objetos pendentes para finalização, ainda é não determinístico. Além disso, o método finalize pode causar problemas de desempenho, deadlocks etc. Podemos encontrar mais informações olhando para um de nossos artigos: um guia para o método finalize em Java. A partir do Java 9, A classe Cleaner é adicionada para substituir o método finalize por causa das desvantagens que possui. Como resultado, temos melhor controle sobre o thread que faz as ações de limpeza. Mas a especificação java aponta o comportamento dos limpadores durante o sistema.exit é específico de implementação e Java não fornece garantias se as ações de limpeza serão invocadas ou não.
