2010-06-09 8 views
6

Un mio collega imposta riferimento a null in blocchi alla fine. Penso che sia un'assurdità.Imposta riferimento = null nel blocco finally?

public Something getSomething() { 
    JDBCConnection jdbc=null; 
    try { 
     jdbc=JDBCManager.getConnection(JDBCTypes.MYSQL); 
     ... 
    } 
    finally { 
     JDBCManager.free(jdbc); 
     jdbc=null; // <-- Useful or not? 
    } 
} 

Cosa ne pensi?

+0

Per questo * codice * esatto, non ha senso provare/finalmente - se un'eccezione viene generata da getConnection, jdbc è nullo, quindi free non farà nulla. Presumibilmente c'è davvero qualcosa tra il compito e la fine del tentativo. –

+0

Qual è il motivo per cui i tuoi colleghi lo fanno? –

+0

Penso che lo consideri "pulito" e salverà la memoria. – deamon

risposta

11

Lei ha ragione, jdbc è una variabile locale in modo che quando il metodo ritorna getSomething()jdbc sarà fuori portata e per la garbage collection che è effettivamente la stessa impostazione a NULL. Quindi non ha senso impostare una variabile su null quando è fuori ambito nella prossima riga di codice.

È buona pratica limitare le variabili allo scope più piccolo necessario, ad es. se è necessaria solo una variabile all'interno di un ciclo for, dichiararla nel ciclo for e sarà idonea per la garbage collection quando il codice esce dal ciclo for. Questo, oltre a ridurre la complessità dei tuoi metodi, riduce la necessità di impostare anche le variabili locali su null e, come beneficio, il tuo codice diventa più modulare, più facile da leggere e gestire.

2

Sì, questo è praticamente un assurdità. La motivazione è solitamente quella di "aiutare" il garbage collector, ma questo non è un vero aiuto dal momento che il riferimento viene comunque cancellato. Anche se non fa nulla di male, almeno non per la VM: i tuoi occhi e la sanità mentale sono una questione diversa.

Tuttavia, l'esempio non restituisce Qualcosa. Se l'esempio è incompleto e in effetti esistono istruzioni dopo il blocco finally, l'impostazione jdbc su null può fungere da deterrente da utilizzare e l'NPE che si verifica immediatamente informa di qualsiasi utilizzo dopo il blocco finally.

5

Poiché si tratta di una variabile locale, verrà comunque utilizzata. Non ha senso.

Se fosse una variabile di istanza (variabile membro) di un oggetto longeva, potrebbe essere utile poiché altrimenti potrebbe impedire al garbage collector di smaltire l'oggetto.

-2

Se ci fosse più codice dopo il blocco finale invece di terminare il metodo, potrebbe aiutare il garbage collector a ripulirlo.

+0

Ancora di più: impedirebbe ai programmatori di usare jdbc dopo che è stato liberato. –

+1

No, non aiuterà il gc a pulire. La specifica JVM è abbastanza chiara che solo i riferimenti che contribuiscono a ulteriori calcoli sono raggiungibili, quindi se lo si annulla e non si ottiene un NPE, il suo annullamento non ha alcun effetto. Se lo annulli e ottieni un NPE, hai infranto il codice. È più facile mettere un extra {} intorno alla dichiarazione e usare, o meglio ridefinire il suo uso in un metodo separato, per scoprire se è usato in fase di compilazione. –

+0

jdbc è già nullo. –

1

In questo caso speciale, tecnicamente parlato, è davvero inutile. Quando il metodo restituisce, jdbc non esiste più e non manterrà un riferimento a una connessione, quindi non influirà sulla raccolta dei dati inutili.

È una questione di stile di codifica. C'è un piccolo vantaggio se un giorno aggiungi altro codice dopo il blocco finale. Quindi è immediatamente evidente che non è più possibile utilizzare jdbc perché è stato liberato da JDBCManager.

Quindi sì, è buona norma annullare i riferimenti alle risorse disponibili.

+0

+1 per mostrare a _programmer_ che un determinato riferimento non è valido. –

+0

chi ha svalutato quella risposta - sarei felice di sapere la tua ragione. Veramente! –

1

come già scritto, in questo caso è inutile, perché il metodo termina dopo l'ultimo.
Lo farei, se c'è un codice che segue il try-finally, per impedire infine il suo utilizzo. E ci sono (molto rare) situazioni in cui può aiutare.
Date un'occhiata a questo articolo: Java Memory Puzzle

0

quindi dovrebbe impostare tutte le variabili locali su null in tutti i metodi prima del ritorno.

JVM probabilmente ottimizzerà comunque la linea, quindi non ha alcun effetto di runtime.

Problemi correlati