2012-01-20 16 views
5

Ciao a tutti capisco che se leggiamo byte da uno InputStream e abbiamo finito di leggere tutti i byte (o non intendiamo leggere fino alla fine del flusso), dobbiamo chiamare close() per rilasciare le risorse di sistema associate al flusso.Gli stream si chiudono automaticamente in caso di errore?

Ora mi stavo chiedendo se ho read byte e getta un java.io.IOException, sono ancora obbligato a chiamare close() per rilasciare le risorse di sistema associate al flusso?

Oppure è vero che su errori, i flussi vengono chiusi automaticamente, quindi non dobbiamo chiamare close()?

+0

Le risorse sono chiusi quando GCed. Quindi puoi avere un problema che raramente fa funzionare un'eccezione ok. Per la gestione delle risorse deterministiche, deve essere sempre chiamato close(). –

+0

@PeterLawrey Stai dicendo che è ** perché ** il GC mangia tranquillamente la IOException lanciata da 'close()' che dovremmo chiamare 'close()' noi stessi? Quindi se (ipoteticamente) l'interfaccia di close() non genera alcuna forma di Eccezione, non dobbiamo chiamare close() quando un flusso ha un errore? – Pacerier

+0

Questo è qualcosa da considerare, tuttavia è piuttosto comune ignorare qualsiasi eccezione lanciata da close(). Il problema con il lasciar fare il GC è che puoi eseguire i nostri handle di file prima di attivare un GC che pulisce queste risorse. Il tuo programma può sembrare funzionare, ma fallire occasionalmente che è qualcosa che vuoi evitare. –

risposta

6

Il sistema operativo stesso potrebbe chiudere gli stream e deallocare le risorse perché il processo (vale a dire la JVM) termina, ma non è obbligatorio farlo.

È necessario implementare sempre un blocco finally in cui lo si chiude in casi come questi, ad es. in questo modo:

InputStream is = null; 

try { 
    is = new FileInputStream(new File("lolwtf")); 
    //read stuff here 
} catch (IOException e) { 
    System.out.println("omfg, it didn't work"); 
} finally { 
    is.close(); 
} 

Questo non è realmente garantito il funzionamento se gettato in primo luogo, ma probabilmente vuole terminare a quel punto comunque dato l'origine dati è probabilmente incasinato in qualche modo. Puoi trovare maggiori informazioni a riguardo se tieni il provider di InputStream in giro, ad esempio, se ho mantenuto un riferimento all'oggetto File nel mio esempio, potrei controllare se esiste ecc. Tramite l'interfaccia di File, ma questo è specifico al tuo particolare fornitore di dati.

Questa tattica ottiene più utile con le sessioni di rete che gettano, per esempio, con Hibernate ...

+0

Cosa intendi con l'ultimo paragrafo? Intendi la tattica di * "implementare finalmente il blocco" *? – Pacerier

+0

@Pacerier Significato che è piuttosto comune mettere, ad es., La chiusura di una sessione di sospensione nel blocco finally. – TC1

Problemi correlati