Lors de l'utilisation de FileLock de Java, est-ce correct de laisser fermer() pour faire automatiquement un lock.release()?

Question

Comme la plupart devraient savoir close() ferme également toutes les utilisations de flux.

Cela permet le code de suivi:

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

C'est agréable, car on n'a pas besoin d'une référence à FileInputStream et rappelez-vous le fermer.

Mais cela fonctionne aussi pour 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(); 
} 

J'ai essayé ce code et le verrou est libéré correctement lorsque br.close() est appelé, mais il est est sûr de le faire? Le Closeable JavaDoc dit, "Ferme ce flux et libère toutes les ressources système qui lui sont associées." Suis-je sûr de supposer que j'utilise close() comme spécifié à release() la serrure?

Answer 1

Selon le JavaDoc:

Il reste valable jusqu'à ce que le verrou est libéré en invoquant la méthode libération , en fermant le canal a été utilisé pour acquérir, ou par la fin du Machine virtuelle Java , selon la première éventualité.

Et voici le contenu de FileInputStream.close()

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

Il ressemble à close sur le flux obture le canal qui libère le verrou.

Answer 2

Oui. Les verrous dépendent d'un descripteur de fichier.

Lorsqu'il n'y a pas de descripteur de fichier représentant un fichier dans un processus, il n'y aurait pas de verrou associé.