2012-01-20 7 views
5

Hola a todos Entiendo que si leemos bytes de InputStream y hemos terminado de leer todos los bytes (o no intentamos leer hasta el final de la secuencia), debemos llamar al close() para liberar los recursos del sistema asociados con la transmisión.¿Las transmisiones se cierran automáticamente por error?

Ahora me preguntaba si read bytes y se lanza una java.io.IOException, estoy todavía obligados a llamar close() para liberar recursos del sistema asociados con la corriente?

¿O es cierto que en los errores, las transmisiones se cierran automáticamente, por lo que no es necesario llamar al close()?

+0

Recursos se cierran cuando GCed. ASÍ PUEDES tener un problema que rara vez arroja una excepción, funciona bien. Para la gestión de recursos determinista, close() siempre debe llamarse. –

+0

@PeterLawrey ¿Estás diciendo que es ** porque ** el GC come tranquilamente la IOException lanzada por 'close()' que deberíamos llamar 'close()'? Entonces, si (hipotéticamente) la interfaz de close() no arroja ninguna forma de excepción, no tenemos que llamar a close() cuando una secuencia tiene un error? – Pacerier

+0

Eso es algo a tener en cuenta, sin embargo, es una práctica bastante común ignorar cualquier excepción lanzada por close(). El problema con dejar que el GC lo haga es que puede ejecutar nuestros identificadores de archivos antes de activar un GC que limpia estos recursos. Puede parecer que su programa funciona, pero falla ocasionalmente, lo cual es algo que desea evitar. –

Respuesta

6

El sistema operativo en sí podría cerrar las rutas y desasignar recursos porque el proceso (es decir, la JVM) finaliza, pero no tiene el mandato para hacerlo.

Siempre debe implementar un bloque finally donde lo cierre en casos como estos, p. Ej. de esta manera:

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(); 
} 

Esto no es realmente garantiza que funcione si se lanzó en el primer lugar, pero es probable que quiere terminar en ese momento de todos modos ya que su fuente de datos es, probablemente, en mal estado de alguna manera. Puede encontrar más información al respecto si mantiene al proveedor de InputStream, como si, si tuviera una referencia al objeto File en mi ejemplo, pudiera verificar si existe, etc. a través de la interfaz File, pero eso es específico a su proveedor de datos en particular.

Esta táctica se vuelve más útil con las sesiones de red que arrojan, por ejemplo, con Hibernate ...

+0

¿Qué quiere decir con el último párrafo? ¿Te refieres a la táctica de * "implementar finalmente bloquear" *? – Pacerier

+0

@Pacerier Lo que significa que es bastante común poner, por ejemplo, el cierre de una sesión de Hibernate en el bloque finally. – TC1

Cuestiones relacionadas