Al usar el FileLock de Java, ¿está bien dejar que close() haga automáticamente un lock.release()?

Question

Como la mayoría debería saber, close() también cierra los usos de secuencias.

Esto permite que el código de seguimiento:

BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream(...))); 
... 
br.close(); 

Esto es bueno, ya que no necesitamos una referencia a FileInputStream y recordar para cerrarla.

¿Pero también funciona para FileLock s?

final FileInputStream fis = new FileInputStream(new File("buffer.txt")); 
final FileChannel c = fis.getChannel(); 
final FileLock lock = c.lock(0L, Long.MAX_VALUE, true); 
final BufferedReader br = new BufferedReader(new InputStreamReader(fis)); 

try { 
    while(br.ready()) { 
     System.out.println(br.readLine()); 
    } 
} finally { 
    br.close(); 
} 

He probado este código y el bloqueo se libera correctamente cuando br.close() se llama, pero se es seguro hacerlo? El Closeable JavaDoc dice, "Cierra esta secuencia y libera los recursos del sistema asociados con ella". ¿Puedo suponer que estoy usando close() como se especifica en release() el bloqueo?

Answer 1

De acuerdo con la JavaDoc:

Sigue siendo válida hasta que el bloqueo es lanzado al invocar el método de liberación , cerrando el canal que se utilizó para adquirirla, o por el terminación de la Java virtual máquina, lo que ocurra primero.

Y aquí están los contenidos de FileInputStream.close()

public void close() throws IOException { 
    if (channel != null) 
     channel.close(); 
    close0(); 
} 

Parece que close en la corriente cierra el canal que libera el bloqueo.

Answer 2

Sí.

Los bloqueos dependen de un descriptor de archivo. Cuando no hay un descriptor de archivo que represente un archivo en un proceso, no habría un bloqueo asociado a él.