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

Question

Como la mayoría debería saber close () también cierra cualquier uso de transmisión.

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 recuerde 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 intentado este código y el bloqueo se libera correctamente cuando se llama a br.close () , pero ¿es seguro hacerlo? El JavaDoc cerrable dice , " Cierra este flujo y libera los recursos del sistema asociados con él. " Estoy seguro de que estoy usando close () como se especifica en la versión de () ¿el bloqueo?

Answer 1

Según el JavaDoc :

  

Sigue siendo válido hasta que el bloqueo esté   lanzado invocando el lanzamiento   Método, cerrando el canal que   fue utilizado para adquirirlo, o por la   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 el flujo 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á un bloqueo asociado con él.