Perché mai implementare finalize ()?

Ho letto molte delle domande principianti su Java finalize()e trovo sconcertante che nessuno abbia chiarito che finalizzare () è un modo inaffidabile per ripulire le risorse. Ho visto qualcuno commentare che lo usano per ripulire Connections, il che è davvero spaventoso poiché l'unico modo per avvicinarsi alla garanzia che una connessione sia chiusa è implementare try (catch) finalmente.

Non avevo studiato in CS, ma ho programmato in Java professionalmente per quasi un decennio ormai e non ho mai visto nessuno implementare finalize() in un sistema di produzione mai. Ciò non significa ancora che non abbia i suoi usi o che le persone con cui ho lavorato lo stiano facendo bene.

Quindi la mia domanda è: quali casi d'uso ci sono per l'implementazione finalize() che non possono essere gestiti in modo più affidabile tramite un altro processo o sintassi all'interno della lingua?

Fornisci scenari specifici o la tua esperienza, semplicemente ripetere un libro di testo Java o finalizzare l'uso previsto non è sufficiente, in quanto non è l'intento di questa domanda.

È possibile utilizzarlo come backstop per un oggetto che contiene una risorsa esterna (socket, file, ecc.). Implementare un close()metodo e documentare che deve essere chiamato.

Implementare finalize()per eseguire l' close()elaborazione se si rileva che non è stata eseguita. Forse con qualcosa di scaricatostderr sottolineare che stai pulendo dopo un chiamante buggy.

Fornisce ulteriore sicurezza in una situazione eccezionale / buggy. Non tutti i chiamanti faranno il correttotry {} finally {} cose . Sfortunato, ma vero nella maggior parte degli ambienti.

Sono d'accordo che raramente è necessario. E come sottolineano i commentatori, viene fornito con GC overhead. Utilizzare solo se è necessaria la sicurezza di "cintura e bretelle" in un'app di lunga durata.

Vedo che a partire da Java 9, Object.finalize()è obsoleto! Ci indicano java.lang.ref.Cleanere java.lang.ref.PhantomReferencecome alternative.

finalize()è un suggerimento per JVM che potrebbe essere utile eseguire il codice in un momento non specificato. Questo è utile quando si desidera che il codice non funzioni in modo misterioso.

Fare qualcosa di significativo nei finalizzatori (praticamente qualsiasi cosa tranne la registrazione) va bene anche in tre situazioni:

• vuoi scommettere che altri oggetti finalizzati saranno ancora in uno stato che il resto del tuo programma considera valido.
• vuoi aggiungere un sacco di codice di controllo a tutti i metodi di tutte le tue classi che hanno un finalizzatore, per assicurarti che si comportino correttamente dopo la finalizzazione.
• vuoi resuscitare accidentalmente oggetti finalizzati e spendere molto tempo a cercare di capire perché non funzionano e / o perché non vengono finalizzati quando vengono rilasciati.

Se ritieni di aver bisogno di finalizzare (), a volte ciò che realmente vuoi è un riferimento fantasma (che nell'esempio fornito potrebbe contenere un riferimento reale a una connessione utilizzata dal suo riferimento, e chiuderlo dopo che il riferimento fantasma è stato messo in coda). Questo ha anche la proprietà che potrebbe non funzionare misteriosamente, ma almeno non può richiamare metodi o resuscitare oggetti finalizzati. Quindi è giusto per le situazioni in cui non hai assolutamente bisogno di chiudere in modo pulito quella connessione, ma ti piacerebbe molto, e i clienti della tua classe non possono o non vogliono chiudere da soli (il che è abbastanza giusto - che cosa' s il punto di avere un garbage collector se si progettano interfacce che richiedono un'azione specifica prima della raccolta? Questo ci riporta ai tempi di malloc / free.)

Altre volte hai bisogno della risorsa che pensi di riuscire a essere più robusta. Ad esempio, perché è necessario chiudere quella connessione? Alla fine deve essere basato su un qualche tipo di I / O fornito dal sistema (socket, file, qualunque cosa), quindi perché non puoi fare affidamento sul sistema per chiuderlo quando hai il livello più basso di risorse? Se il server all'altra estremità richiede assolutamente di chiudere la connessione in modo pulito piuttosto che far cadere la presa, cosa accadrà quando qualcuno inciamperà sul cavo di alimentazione della macchina su cui è in esecuzione il codice o la rete che interviene?

Disclaimer: ho lavorato su un'implementazione JVM in passato. Odio i finalizzatori.

Una semplice regola: non usare mai i finalizzatori.

Il solo fatto che un oggetto abbia un finalizzatore (indipendentemente dal codice che esegue) è sufficiente per causare un notevole sovraccarico per la garbage collection.

Da un articolo di Brian Goetz:

Gli oggetti con finalizzatori (quelli che hanno un metodo finalize () non banale) hanno un notevole sovraccarico rispetto agli oggetti senza finalizzatori e dovrebbero essere usati con parsimonia. Gli oggetti finalizzabili sono sia più lenti da allocare sia più lenti da raccogliere. Al momento dell'allocazione, la JVM deve registrare tutti gli oggetti finalizzabili con il Garbage Collector e (almeno nell'implementazione di HotSpot JVM) gli oggetti finalizzabili devono seguire un percorso di allocazione più lento rispetto alla maggior parte degli altri oggetti. Allo stesso modo, anche gli oggetti finalizzabili sono più lenti da raccogliere. Ci vogliono almeno due cicli di garbage collection (nel migliore dei casi) prima che un oggetto finalizzabile possa essere recuperato e il garbage collector deve fare un lavoro extra per invocare il finalizzatore. Il risultato è più tempo dedicato all'allocazione e alla raccolta di oggetti e una maggiore pressione sul Garbage Collector, poiché la memoria utilizzata da oggetti finalizzabili non raggiungibili viene mantenuta più a lungo. Combinalo con il fatto che i finalizzatori non sono garantiti per essere eseguiti in tempi prevedibili, o addirittura affatto, e puoi vedere che ci sono relativamente poche situazioni per le quali la finalizzazione è lo strumento giusto da usare.

L'unica volta che ho usato finalizzare nel codice di produzione era implementare un controllo che le risorse di un determinato oggetto fossero state ripulite e, in caso contrario, registrare un messaggio molto vocale. In realtà non ha provato a farlo da solo, ha solo gridato molto se non è stato fatto correttamente. Si è rivelato abbastanza utile.

Faccio Java professionalmente dal 1998 e non l'ho mai implementato finalize(). Non una volta.

La risposta accettata è buona, volevo solo aggiungere che ora c'è un modo per avere la funzionalità di finalizzazione senza effettivamente usarla affatto.

Guarda le classi "Riferimenti". Riferimento debole, riferimento Phantom e riferimento morbido.

Puoi usarli per mantenere un riferimento a tutti i tuoi oggetti, ma questo riferimento ALONE non fermerà GC. La cosa bella di questo è che puoi averlo chiamare un metodo quando verrà eliminato, e questo metodo può essere garantito per essere chiamato.

Per quanto riguarda finalizzare: ho usato finalizzare una volta per capire quali oggetti venivano liberati. Puoi giocare ad alcuni giochi accurati con statica, conteggio dei riferimenti e simili - ma era solo per analisi, ma fai attenzione a codice come questo (non solo per finalizzare, ma è lì che è più probabile vederlo):

public void finalize() {
  ref1 = null;
  ref2 = null;
  othercrap = null;
}

È un segno che qualcuno non sapeva cosa stavano facendo. "Pulire" in questo modo non è praticamente mai necessario. Quando la classe è GC'd, questo viene fatto automaticamente.

Se trovi un codice del genere in una finalizzazione, è garantito che la persona che l'ha scritto era confusa.

Se è altrove, è possibile che il codice sia una patch valida per un modello errato (una classe rimane a lungo in circolazione e per qualche ragione le cose a cui faceva riferimento dovevano essere liberate manualmente prima che l'oggetto fosse GC'd). Generalmente è perché qualcuno ha dimenticato di rimuovere un ascoltatore o qualcosa del genere e non riesce a capire perché il suo oggetto non sia GC'd, quindi cancellano semplicemente le cose a cui si riferisce e scrollano le spalle e se ne vanno.

Non dovrebbe mai essere usato per ripulire le cose "Più veloce".

Non sono sicuro di cosa tu possa fare di questo, ma ...

itsadok@laptop ~/jdk1.6.0_02/src/
$ find . -name "*.java" | xargs grep "void finalize()" | wc -l
41

Quindi immagino che il Sole abbia trovato alcuni casi in cui (pensano) che dovrebbe essere usato.

class MyObject {
    Test main;

    public MyObject(Test t) {    
        main = t; 
    }

    protected void finalize() {
        main.ref = this; // let instance become reachable again
        System.out.println("This is finalize"); //test finalize run only once
    }
}

class Test {
    MyObject ref;

    public static void main(String[] args) {
        Test test = new Test();
        test.ref = new MyObject(test);
        test.ref = null; //MyObject become unreachable，finalize will be invoked
        System.gc(); 
        if (test.ref != null) System.out.println("MyObject still alive!");  
    }
}

====================================

risultato:

This is finalize

MyObject still alive!

=====================================

Quindi puoi rendere raggiungibile un'istanza irraggiungibile nel metodo finalize.

finalize()può essere utile per rilevare perdite di risorse. Se la risorsa deve essere chiusa ma non è scritto, non essere chiusa in un file di registro e chiuderla. In questo modo rimuovi la perdita di risorse e ti dai un modo per sapere che è successo in modo da poterlo riparare.

Sto programmando in Java dalla 1.0 alpha 3 (1995) e non ho ancora finito di finalizzare nulla ...

Non dovresti dipendere da finalize () per ripulire le tue risorse. finalize () non funzionerà fino a quando la classe non sarà raccolta in modo inutile, se allora. È molto meglio liberare esplicitamente le risorse quando hai finito di usarle.

Per evidenziare un punto nelle risposte precedenti: i finalizzatori verranno eseguiti sul thread GC singolo. Ho sentito parlare di una grande demo di Sun in cui gli sviluppatori hanno aggiunto un po 'di sonno ad alcuni finalizzatori e hanno intenzionalmente messo in ginocchio una demo 3D altrimenti stravagante.

Meglio evitare, con la possibile eccezione della diagnostica test-env.

Il pensiero di Eckel in Java ha una buona sezione su questo.

Hmmm, una volta l'ho usato per ripulire oggetti che non venivano restituiti a un pool esistente.

Erano passati molto, quindi era impossibile dire quando potevano essere tranquillamente riportati in piscina. Il problema era che ha introdotto un'enorme penalità durante la raccolta dei rifiuti che era molto maggiore di qualsiasi risparmio derivante dalla messa in comune degli oggetti. È stato in produzione per circa un mese prima che strappassi l'intero pool, rendessi tutto dinamico e ci fossi finito.

Fai attenzione a ciò che fai in a finalize(). Soprattutto se lo stai usando per cose come chiamare close () per assicurarti che le risorse vengano ripulite. Ci siamo imbattuti in diverse situazioni in cui avevamo librerie JNI collegate al codice java in esecuzione, e in qualsiasi circostanza in cui abbiamo usato finalize () per invocare metodi JNI, avremmo avuto una pessima corruzione dell'heap java. La corruzione non è stata causata dallo stesso codice JNI sottostante, tutte le tracce di memoria andavano bene nelle librerie native. Era solo il fatto che stavamo chiamando i metodi JNI da finalize ().

Questo è stato con un JDK 1.5 che è ancora ampiamente utilizzato.

Non scopriremmo che qualcosa è andato storto molto più tardi, ma alla fine il colpevole era sempre il metodo finalize () che utilizzava le chiamate JNI.

Quando si scrive codice che verrà utilizzato da altri sviluppatori che richiede una sorta di metodo di "pulizia" da chiamare per liberare risorse. A volte quegli altri sviluppatori dimenticano di chiamare il metodo di pulizia (o chiusura, distruzione o altro). Per evitare possibili perdite di risorse è possibile verificare il metodo finalize per assicurarsi che il metodo sia stato chiamato e, in caso contrario, è possibile chiamarlo da soli.

Molti driver di database fanno questo nelle loro implementazioni di Dichiarazione e Connessione per fornire un po 'di sicurezza agli sviluppatori che dimenticano di chiamarli vicini.

Modifica: Okay, davvero non funziona. L'ho implementato e ho pensato che se fallisce a volte va bene per me, ma non ha nemmeno chiamato il metodo finalize una sola volta.

Non sono un programmatore professionista, ma nel mio programma ho un caso che penso sia un esempio di un buon caso di utilizzo di finalize (), ovvero una cache che scrive il suo contenuto sul disco prima che venga distrutto. Poiché non è necessario che venga eseguito ogni volta in caso di distruzione, accelera solo il mio programma, spero che non abbia sbagliato.

@Override
public void finalize()
{
    try {saveCache();} catch (Exception e)  {e.printStackTrace();}
}

public void saveCache() throws FileNotFoundException, IOException
{
    ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("temp/cache.tmp"));
    out.writeObject(cache);
}

Può essere utile rimuovere le cose che sono state aggiunte a un luogo globale / statico (per necessità) e devono essere rimosse quando l'oggetto viene rimosso. Per esempio:

    void privato addGlobalClickListener () {
        weakAwtEventListener = new WeakAWTEventListener (this);

        Toolkit.getDefaultToolkit (). AddAWTEventListener (weakAwtEventListener, AWTEvent.MOUSE_EVENT_MASK);
    }

    @Oltrepassare
    protetto void finalize () genera Throwable {
        super.finalize ();

        if (weakAwtEventListener! = null) {
            . Toolkit.getDefaultToolkit () removeAWTEventListener (weakAwtEventListener);
        }
    }

iirc - puoi usare il metodo finalize come mezzo per implementare un meccanismo di pooling per risorse costose - in modo che non ottengano anche i GC.

Come nota a margine:

Un oggetto che sostituisce finalize () viene trattato in modo speciale dal Garbage Collector. Di solito, un oggetto viene immediatamente distrutto durante il ciclo di raccolta dopo che l'oggetto non rientra più nell'ambito. Tuttavia, gli oggetti finalizzabili vengono invece spostati in una coda, in cui thread di finalizzazione separati svuoteranno la coda ed eseguiranno il metodo finalize () su ciascun oggetto. Una volta terminato il metodo finalize (), l'oggetto sarà finalmente pronto per la garbage collection nel ciclo successivo.

Fonte: finalize () deprecato su java-9

Le risorse (File, Socket, Stream ecc.) Devono essere chiuse una volta terminato. Generalmente hanno un close()metodo che generalmente chiamiamo nella finallysezione delle try-catchdichiarazioni. A volte finalize()può essere utilizzato anche da pochi sviluppatori, ma IMO non è un modo adatto in quanto non esiste alcuna garanzia che finalizzare verrà chiamato sempre.

In Java 7 abbiamo un'istruzione try-with-resources che può essere utilizzata come:

try (BufferedReader br = new BufferedReader(new FileReader(path))) {
  // Processing and other logic here.
} catch (Exception e) {
  // log exception
} finally {
  // Just in case we need to do some stuff here.
}

Nell'esempio precedente try-with-resource chiuderà automaticamente la risorsa BufferedReaderinvocando il close()metodo. Se vogliamo, possiamo anche implementare Closeable nelle nostre classi e usarlo in modo simile. IMO sembra più pulito e semplice da capire.

Personalmente, non l'ho quasi mai usato, finalize()tranne in una rara circostanza: ho creato una raccolta personalizzata di tipo generico e ho scritto un finalize()metodo personalizzato che procede come segue:

public void finalize() throws Throwable {
    super.finalize();
    if (destructiveFinalize) {
        T item;
        for (int i = 0, l = length(); i < l; i++) {
            item = get(i);
            if (item == null) {
                continue;
            }
            if (item instanceof Window) {
                ((Window) get(i)).dispose();
            }
            if (item instanceof CompleteObject) {
                ((CompleteObject) get(i)).finalize();
            }
            set(i, null);
        }
    }
}

^{( CompleteObjectÈ un'interfaccia che ho fatto che consente di specificare che hai implementato raramente attuati Objectmetodi come #finalize(), #hashCode(), e #clone())}

Quindi, usando un #setDestructivelyFinalizes(boolean)metodo gemello , il programma che usa la mia collezione può (aiutare) garantire che la distruzione di un riferimento a questa raccolta distrugge anche i riferimenti al suo contenuto e elimina qualsiasi finestra che possa mantenere in vita la JVM involontariamente. Ho anche considerato di interrompere qualsiasi thread, ma ciò ha aperto una nuova lattina di worm.

La risposta accettata indica che è possibile eseguire la chiusura di una risorsa durante la finalizzazione.

Comunque questa risposta mostra che almeno in java8 con il compilatore JIT, si verificano problemi imprevisti in cui a volte viene chiamato il finalizzatore anche prima di terminare la lettura da un flusso gestito dall'oggetto.

Quindi anche in quella situazione non è consigliabile chiamare finalizzare .