Cuando se utiliza FileLock de Java, ¿está bien dejar que close() haga automáticamente un lock.release()?

nio

Question

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

Esto permite el siguiente código:

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

Esto es bueno, ya que no necesitamos una referencia a FileInputStream y recuerda cerrarlo.

¿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 intentado este código y el bloqueo se libera correctamente cuando se llama a br.close() , pero ¿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 para release() el bloqueo?

Answer 1

De acuerdo con JavaDoc :

Sigue siendo válido hasta que se libere el bloqueo invocando el método de lanzamiento, cerrando el canal que se usó para adquirirlo o terminando la máquina virtual Java, 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 de la corriente se cierra el canal que libera la cerradura.

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.