Esiste un distruttore per Java?

Esiste un distruttore per Java? Non riesco a trovare alcuna documentazione al riguardo. In caso contrario, come posso ottenere lo stesso effetto?

Per rendere la mia domanda più specifica, sto scrivendo un'applicazione che si occupa di dati e le specifiche dicono che dovrebbe esserci un pulsante 'reset' che riporta l'applicazione al suo stato originale appena lanciato. Tuttavia, tutti i dati devono essere "attivi" a meno che l'applicazione non venga chiusa o non venga premuto il pulsante di ripristino.

Essendo di solito un programmatore C / C ++, ho pensato che sarebbe stato banale implementarlo. (E quindi ho pianificato di implementarlo per ultimo.) Ho strutturato il mio programma in modo tale che tutti gli oggetti "ripristinabili" fossero nella stessa classe in modo da poter semplicemente distruggere tutti gli oggetti "live" quando viene premuto un pulsante di ripristino.

Stavo pensando se tutto ciò che facevo fosse solo quello di dereferenziare i dati e aspettare che il garbage collector li raccogliesse, non ci sarebbe una perdita di memoria se il mio utente immettesse ripetutamente i dati e premesse il pulsante di ripristino? Stavo pensando anche perché Java è abbastanza maturo come linguaggio, dovrebbe esserci un modo per impedire che ciò accada o affrontarlo con grazia.

Poiché Java è un linguaggio garbage collection, non è possibile prevedere quando (o anche se) un oggetto verrà distrutto. Quindi non esiste un equivalente diretto di un distruttore.

Esiste un metodo ereditato chiamato finalize, ma questo viene chiamato interamente a discrezione del Garbage Collector. Quindi, per le classi che hanno bisogno di riordinare esplicitamente, la convenzione è di definire un metodo di chiusura e usare finalizza solo per il controllo di integrità (cioè se non è stato chiamato chiusura, fallo ora e registra un errore).

C'è stata una domanda che ha generato una discussione approfondita sulla finalizzazione di recente, quindi dovrebbe fornire maggiore profondità se necessario ...

Dai un'occhiata all'istruzione try-with-resources . Per esempio:

try (BufferedReader br = new BufferedReader(new FileReader(path))) {
  System.out.println(br.readLine());
} catch (Exception e) {
  ...
} finally {
  ...
}

Qui la risorsa non più necessaria viene liberata nel BufferedReader.close()metodo. Puoi creare la tua classe che implementa AutoCloseablee usarla in modo simile.

Questa affermazione è più limitata che finalizein termini di strutturazione del codice, ma allo stesso tempo semplifica la comprensione e la manutenzione del codice. Inoltre, non vi è alcuna garanzia che un finalizemetodo venga chiamato durante il live-time dell'applicazione.

No, nessun distruttore qui. Il motivo è che tutti gli oggetti Java sono allocati in heap e garbage collection. Senza esplicita deallocazione (cioè l'operatore di eliminazione di C ++) non esiste un modo ragionevole per implementare i veri distruttori.

Java supporta i finalizzatori, ma sono pensati per essere utilizzati solo come protezione per oggetti che trattengono un handle di risorse native come socket, handle di file, handle di finestre, ecc. Quando il Garbage Collector raccoglie un oggetto senza un finalizzatore, contrassegna semplicemente la memoria regione libera e basta. Quando l'oggetto ha un finalizzatore, viene prima copiato in una posizione temporanea (ricordate, stiamo raccogliendo la spazzatura qui), quindi viene accodato in una coda in attesa di essere finalizzata e quindi un thread Finalizer esegue il polling della coda con priorità molto bassa ed esegue il finalizzatore.

Quando l'applicazione viene chiusa, JVM si arresta senza attendere la finalizzazione degli oggetti in sospeso, quindi praticamente non esiste alcuna garanzia che i finalizzatori vengano mai eseguiti.

L'uso dei metodi finalize () dovrebbe essere evitato. Non sono un meccanismo affidabile per la pulizia delle risorse ed è possibile causare problemi nel garbage collector abusandoli.

Se è necessaria una chiamata di deallocazione nell'oggetto, dire di rilasciare risorse, utilizzare una chiamata di metodo esplicita. Questa convenzione può essere vista nelle API esistenti (ad es. Closeable , Graphics.dispose () , Widget.dispose () ) e di solito viene chiamata tramite try / finally.

Resource r = new Resource();
try {
    //work
} finally {
    r.dispose();
}

I tentativi di utilizzare un oggetto eliminato dovrebbero generare un'eccezione di runtime (consultare IllegalStateException ).

MODIFICARE:

Stavo pensando, se tutto ciò che facevo fosse solo quello di dereferenziare i dati e aspettare che il garbage collector li raccogliesse, non ci sarebbe una perdita di memoria se il mio utente immettesse ripetutamente i dati e premesse il pulsante di ripristino?

Generalmente, tutto ciò che devi fare è dereferenziare gli oggetti - almeno, questo è il modo in cui dovrebbe funzionare. Se sei preoccupato per la garbage collection, dai un'occhiata a Java SE 6 HotSpot [tm] Virtual Machine Garbage Collection Tuning (o al documento equivalente per la tua versione JVM).

Con Java 1.7 rilasciato, ora hai l'opzione aggiuntiva di usare il try-with-resourcesblocco. Per esempio,

public class Closeable implements AutoCloseable {
    @Override
    public void close() {
        System.out.println("closing..."); 
    }
    public static void main(String[] args) {
        try (Closeable c = new Closeable()) {
            System.out.println("trying..."); 
            throw new Exception("throwing..."); 
        }
        catch (Exception e) {
            System.out.println("catching..."); 
        }
        finally {
            System.out.println("finalizing..."); 
        } 
    }
}

Se esegui questa classe, c.close()verrà eseguito quandotry blocco viene lasciato e prima catchche finallyvengano eseguiti i blocchi e . Diversamente dal caso del finalize()metodo, close()è garantito l'esecuzione. Tuttavia, non è necessario eseguirlo esplicitamente nella finallyclausola.

Concordo pienamente con altre risposte, dicendo di non fare affidamento sull'esecuzione di finalizza.

Oltre ai blocchi try-catch-finally, è possibile utilizzare Runtime # addShutdownHook (introdotto in Java 1.3) per eseguire le pulizie finali del programma.

Non è lo stesso dei distruttori , ma è possibile implementare un hook di arresto con oggetti listener registrati su cui è possibile invocare metodi di pulizia (chiudere connessioni al database persistenti, rimuovere blocchi di file e così via) - cose che normalmente si farebbero in distruttori . Ancora una volta - questo non è un sostituto per i distruttori ma in alcuni casi, è possibile avvicinarsi alla funzionalità desiderata con questo.

Il vantaggio è che il comportamento di decostruzione è vagamente accoppiato al resto del programma.

No, java.lang.Object#finalize è il più vicino che puoi ottenere.

Tuttavia, quando (e se) viene chiamato, non è garantito.
Vedere:java.lang.Runtime#runFinalizersOnExit(boolean)

Innanzitutto, si noti che poiché Java è stato raccolto in modo inutile, è raro dover fare qualcosa per la distruzione degli oggetti. In primo luogo perché di solito non hai risorse gestite da liberare, e in secondo luogo perché non puoi prevedere quando o se accadrà, quindi è inappropriato per le cose che devono accadere "non appena nessuno sta più usando il mio oggetto ".

Puoi essere avvisato dopo che un oggetto è stato distrutto usando java.lang.ref.PhantomReference (in realtà, dire che è stato distrutto potrebbe essere leggermente impreciso, ma se un riferimento fantasma ad esso viene messo in coda, non sarà più recuperabile, che di solito equivale a la stessa cosa). Un uso comune è:

• Separa le risorse della tua classe che devono essere distrutte in un altro oggetto helper (nota che se tutto ciò che stai facendo è chiudere una connessione, che è un caso comune, non è necessario scrivere una nuova classe: la connessione da chiudere sarebbe in tal caso l '"oggetto helper").
• Quando crei il tuo oggetto principale, crea anche un PhantomReference. Fare in modo che si riferiscano al nuovo oggetto helper o impostare una mappa dagli oggetti PhantomReference ai loro oggetti helper corrispondenti.
• Dopo che l'oggetto principale è stato raccolto, PhantomReference viene messo in coda (o meglio, può essere messo in coda - come per i finalizzatori, non vi è alcuna garanzia che lo sarà mai, ad esempio se la VM esce e non attende). Assicurati di elaborarne la coda (in un thread speciale o di volta in volta). A causa del duro riferimento all'oggetto helper, l'oggetto helper non è stato ancora raccolto. Quindi esegui qualsiasi operazione di pulizia sull'oggetto helper, quindi scarta PhantomReference e alla fine anche l'helper verrà raccolto.

C'è anche finalize (), che sembra un distruttore ma non si comporta come tale. Di solito non è una buona opzione.

La finalize()funzione è il distruttore.

Tuttavia, non dovrebbe essere normalmente utilizzato perché viene invocato dopo il GC e non si può dire quando ciò accadrà (se mai).

Inoltre, ci vuole più di un GC per deallocare oggetti che hanno finalize().

Dovresti provare a ripulire nei punti logici del tuo codice usando le try{...} finally{...}istruzioni!

Sono d'accordo con la maggior parte delle risposte.

Non dovresti dipendere completamente da finalizeoShutdownHook

Finalizza

1. La JVM non garantisce quando finalize()verrà invocato questo metodo.

2. finalize()viene chiamato solo una volta dal thread GC. Se un oggetto si ripristina dal metodo di finalizzazione, finalizenon verrà più richiamato.

3. Nella tua applicazione, potresti avere alcuni oggetti live, sui quali non viene mai richiamata la garbage collection.

4. Tutto Exceptionciò che viene lanciato dal metodo di finalizzazione viene ignorato dal thread GC

5. System.runFinalization(true)e i Runtime.getRuntime().runFinalization(true)metodi aumentano la probabilità di invocare il finalize()metodo, ma ora questi due metodi sono stati deprecati. Questi metodi sono molto pericolosi a causa della mancanza di sicurezza del thread e della possibile creazione di deadlock.

shutdownHooks

public void addShutdownHook(Thread hook)

Registra un nuovo hook di spegnimento della macchina virtuale.

La macchina virtuale Java si spegne in risposta a due tipi di eventi:

1. Il programma termina normalmente quando esce l'ultimo thread non daemon o quando esce (equivalentemente, System.exit viene invocato il metodo ) oppure
2. La macchina virtuale viene terminata in risposta a un interrupt utente, come digitare ^ C, o un evento a livello di sistema, come la disconnessione dell'utente o l'arresto del sistema.
3. Un hook di arresto è semplicemente un thread inizializzato ma non avviato. Quando la macchina virtuale inizia la sequenza di arresto, avvia tutti gli hook di arresto registrati in un ordine non specificato e li lascia funzionare contemporaneamente. Al termine di tutti gli hook, verranno eseguiti tutti i finalizzatori non invocati se la finalizzazione all'uscita è stata abilitata.
4. Alla fine, la macchina virtuale si arresterà. Si noti che i thread daemon continueranno a essere eseguiti durante la sequenza di arresto, così come i thread non daemon se l'arresto è stato avviato invocando il metodo exit.

5. Anche i ganci di arresto dovrebbero finire rapidamente il loro lavoro. Quando un programma richiama exit, l'aspettativa è che la macchina virtuale si spenga e si spenga rapidamente.

   Ma anche la documentazione di Oracle lo citava

In rare circostanze, la macchina virtuale potrebbe interrompersi, ovvero interrompere l'esecuzione senza spegnersi in modo pulito

Ciò si verifica quando la macchina virtuale viene terminata esternamente, ad esempio con il SIGKILLsegnale su Unix o la TerminateProcesschiamata su Microsoft Windows. La macchina virtuale può anche interrompere se un metodo nativo non funziona, ad esempio corrompendo le strutture di dati interni o tentando di accedere alla memoria inesistente. Se la macchina virtuale si interrompe, non è possibile fornire alcuna garanzia sull'esecuzione o meno di hook di arresto.

Conclusione : utilizzare i try{} catch{} finally{}blocchi in modo appropriato e rilasciare le risorse critiche in finally(}blocco. Durante il rilascio di risorse in finally{}blocco, cattura Exceptione Throwable.

Se è solo la memoria di cui sei preoccupato, non farlo. Fidati del GC che fa un lavoro decente. In realtà ho visto qualcosa che era così efficiente che potrebbe essere meglio per le prestazioni creare cumuli di piccoli oggetti piuttosto che utilizzare grandi array in alcuni casi.

Forse puoi usare un blocco try ... finally per finalizzare l'oggetto nel flusso di controllo in cui stai utilizzando l'oggetto. Ovviamente non succede automaticamente, ma nemmeno la distruzione in C ++. Spesso vedi la chiusura delle risorse nel blocco finally.

C'è un'annotazione @Cleanup in Lombok che assomiglia principalmente ai distruttori C ++:

@Cleanup
ResourceClass resource = new ResourceClass();

Durante l'elaborazione (al momento della compilazione), Lombok inserisce il try-finallyblocco appropriato in modo che resource.close()venga invocato, quando l'esecuzione lascia l'ambito della variabile. Puoi anche specificare esplicitamente un altro metodo per rilasciare la risorsa, ad esempio resource.dispose():

@Cleanup("dispose")
ResourceClass resource = new ResourceClass();

L'equivalente più vicino a un distruttore in Java è il metodo finalize () . La grande differenza rispetto a un distruttore tradizionale è che non puoi essere sicuro di quando verrà chiamato, poiché questa è la responsabilità del garbage collector. Consiglio vivamente di leggere attentamente questo prima di usarlo, poiché i tuoi tipici schemi RAIA per gli handle di file e così via non funzioneranno in modo affidabile con finalize ().

Molte ottime risposte qui, ma ci sono alcune informazioni aggiuntive sul perché dovresti evitare di usare finalize () .

Se la JVM termina a causa di System.exit()o Runtime.getRuntime().exit(), i finalizzatori non verranno eseguiti per impostazione predefinita. Da Javadoc per Runtime.exit () :

La sequenza di arresto della macchina virtuale è composta da due fasi. Nella prima fase tutti gli hook di arresto registrati, se presenti, vengono avviati in un ordine non specificato e possono essere eseguiti contemporaneamente fino al termine. Nella seconda fase vengono eseguiti tutti i finalizzatori non invocati se la finalizzazione all'uscita è stata abilitata. Fatto ciò, la macchina virtuale si arresta.

Puoi chiamare System.runFinalization() ma fa solo "uno sforzo migliore per completare tutte le finalizzazioni in sospeso", non una garanzia.

C'è un System.runFinalizersOnExit()metodo, ma non usarlo: è pericoloso, deprecato molto tempo fa.

Se stai scrivendo un'applet Java, puoi sovrascrivere il metodo "destroy ()" dell'applet. È...

 * Called by the browser or applet viewer to inform
 * this applet that it is being reclaimed and that it should destroy
 * any resources that it has allocated. The stop() method
 * will always be called before destroy().

Ovviamente non è quello che vuoi, ma potrebbe essere quello che cercano gli altri.

Basti pensare alla domanda originale ... che, penso, possiamo concludere da tutte le altre risposte apprese, e anche dall'efficace Java essenziale di Bloch , punto 7, "Evita i finalizzatori", cerca la soluzione a una domanda legittima in un modo che è inappropriato per il linguaggio Java ...:

... non sarebbe una soluzione abbastanza ovvia fare ciò che l'OP vuole effettivamente essere per mantenere tutti i tuoi oggetti che devono essere ripristinati in una sorta di "box", a cui tutti gli altri oggetti non ripristinabili hanno riferimenti solo attraverso una sorta dell'oggetto accessorio ...

E poi, quando è necessario "resettare", si disconnette il box esistente e ne si crea uno nuovo: tutta la rete di oggetti nel box viene lanciata alla deriva, per non tornare mai più e un giorno per essere raccolta dal GC.

Se uno di questi oggetti è Closeable(o no, ma ha un closemetodo), puoi metterli nel Bagbox mentre vengono creati (e possibilmente aperti), e l'ultimo atto dell'accessorio prima di tagliare il box sarebbe quello di andare attraverso tutto ilCloseables chiusure ...?

Il codice sarebbe probabilmente simile a questo:

accessor.getPlaypen().closeCloseables();
accessor.setPlaypen( new Playpen() );

closeCloseablessarebbe probabilmente un metodo di blocco, che probabilmente implica un latch (ad es. CountdownLatch), per gestire (e attendere come appropriato) qualsiasi Runnables/ Callablesin qualsiasi thread specifico Playpenper essere terminato come appropriato, in particolare nel thread JavaFX.

Sebbene ci siano stati notevoli progressi nella tecnologia GC di Java, devi comunque essere consapevole dei tuoi riferimenti. Vengono in mente numerosi casi di schemi di riferimento apparentemente banali che sono in realtà nidi di ratti sotto il cappuccio.

Dal tuo post non sembra che tu stia provando a implementare un metodo di ripristino ai fini del riutilizzo degli oggetti (vero?). I tuoi oggetti contengono altri tipi di risorse che devono essere ripuliti (ovvero flussi che devono essere chiusi, oggetti in pool o presi in prestito che devono essere restituiti)? Se l'unica cosa di cui ti preoccupi è il dealloc della memoria, riconsidererei la mia struttura di oggetti e proverei a verificare che i miei oggetti siano strutture autonome che verranno ripulite al momento del GC.

Non esiste una classe di distruttori esattamente in Java, classe distrutta automaticamente in java dal garbage collector. ma potresti farlo usando quello sotto ma non è esattamente la stessa cosa:

finalize ()

C'è stata una domanda che ha generato una discussione approfondita di finalizzazione , in modo da poter ottenere più profondità se necessario ...

Nessun Java non ha alcun distruttore. La ragione principale dietro di esso in Java è il Garbage Collector che lavora sempre passivamente in background e tutti gli oggetti sono fatti nella memoria dell'heap, che è il luogo in cui lavora GC. In c ++ ci deve chiamare esplicitamente la funzione di eliminazione poiché non esiste un Garbage Collector.

Mi occupavo principalmente di C ++ e questo è ciò che mi ha portato anche alla ricerca di un distruttore. Sto usando molto JAVA ora. Quello che ho fatto, e potrebbe non essere il caso migliore per tutti, ma ho implementato il mio distruttore ripristinando tutti i valori su 0 o lì di default tramite una funzione.

Esempio:

public myDestructor() {

variableA = 0; //INT
variableB = 0.0; //DOUBLE & FLOAT
variableC = "NO NAME ENTERED"; //TEXT & STRING
variableD = false; //BOOL

}

Idealmente, questo non funzionerà per tutte le situazioni, ma dove ci sono variabili globali funzionerà finché non ne avrai una tonnellata.

So di non essere il miglior programmatore Java, ma sembra funzionare per me.