Explication détaillée du code pour l'implémentation du verrouillage exclusif Java

Cet article présente principalement le contenu pertinent de la programmation Java pour implémenter le verrouillage exclusif, décrit les fonctions requises pour implémenter ce verrouillage par code et la solution de l'auteur, puis partage le code source de conception avec tous les amis dans le besoin peuvent s'y référer. .

1. Préface

Un certain jour d'un certain mois et d'une certaine année, un collègue a déclaré qu'une fonction de verrouillage exclusive de fichier est nécessaire. Les exigences sont les suivantes :

(1) Les opérations d'écriture sont des propriétés exclusives
(2) Applicable à plusieurs threads du même processus/également applicable aux opérations exclusives de plusieurs processus
(3) Tolérance aux pannes : acquisition du verrou Si le processus plante, cela n'affectera pas l'acquisition normale des verrous par les processus suivants

2. Solution

1. Initialement L'idée de

Dans le domaine Java, l'implémentation exclusive du multi-threading dans un même processus est relativement simple . Par exemple, vous pouvez utiliser une variable de synchronisation de thread pour indiquer si elle est verrouillée. Mais la mise en œuvre exclusive de différents processus est plus lourde. En utilisant l'API existante, j'ai naturellement pensé à java.nio.channels.FileLock : comme suit

/** 
   * @param file 
   * @param strToWrite 
   * @param append 
   * @param lockTime 以毫秒为单位,该值只是方便模拟排他锁时使用，－1表示不考虑该字段 
   * @return 
   */ 
  public static boolean lockAndWrite(File file, String strToWrite, boolean append,int lockTime){ 
    if(!file.exists()){ 
      return false; 
    } 
    RandomAccessFile fis = null; 
    FileChannel fileChannel = null; 
    FileLock fl = null; 
    long tsBegin = System.currentTimeMillis(); 
    try { 
      fis = new RandomAccessFile(file, "rw"); 
      fileChannel = fis.getChannel(); 
      fl = fileChannel.tryLock(); 
      if(fl == null || !fl.isValid()){ 
        return false; 
      } 
      log.info("threadId = {} lock success", Thread.currentThread()); 
      // if append 
      if(append){ 
        long length = fis.length(); 
        fis.seek(length); 
        fis.writeUTF(strToWrite); 
      //if not, clear the content , then write 
      }else{ 
        fis.setLength(0); 
        fis.writeUTF(strToWrite); 
      } 
      long tsEnd = System.currentTimeMillis(); 
      long totalCost = (tsEnd - tsBegin); 
      if(totalCost < lockTime){ 
        Thread.sleep(lockTime - totalCost); 
      } 
    } catch (Exception e) { 
      log.error("RandomAccessFile error",e); 
      return false; 
    }finally{ 
      if(fl != null){ 
        try { 
          fl.release(); 
        } catch (IOException e) { 
          e.printStackTrace(); 
        } 
      } 
      if(fileChannel != null){ 
        try { 
          fileChannel.close(); 
        } catch (IOException e) { 
          e.printStackTrace(); 
        } 
      } 
      if(fis != null){ 
        try { 
          fis.close(); 
        } catch (IOException e) { 
          e.printStackTrace(); 
        } 
      } 
    } 
    return true; 
  }

Tout est si beau et semble être impeccable. Deux codes de scénario de test ont donc été ajoutés :

(1) Dans le même processus, deux threads se disputent le verrou en même temps. Il est provisoirement nommé programme de test A. Résultats attendus : un thread a échoué. pour acquérir le verrou
(2) Exécuter deux processus, c'est-à-dire exécuter deux programmes de test A, et attendre les résultats : un processus et un thread obtiennent le verrou, et l'autre thread ne parvient pas à obtenir le verrou

public static void main(String[] args) { 
    new Thread("write-thread-1-lock"){ 
      @Override 
      public void run() { 
        FileLockUtils.lockAndWrite(new File("/data/hello.txt"), "write-thread-1-lock" ＋ System.currentTimeMillis(), false, 30 * 1000);} 
    }.start(); 
    new Thread("write-thread-2-lock"){ 
      @Override 
      public void run() { 
        FileLockUtils.lockAndWrite(new File("/data/hello.txt"), "write-thread-2-lock" + System.currentTimeMillis(), false, 30 * 1000); 
      } 
    }.start(); 
  }

2. Le monde n'est pas ce que vous pensez

Le code de test ci-dessus peut répondre à nos attentes en un seul processus. . Cependant, lors de l'exécution de deux processus en même temps, le deuxième processus peut obtenir le verrou normalement dans l'environnement Mac (java8), mais le deuxième processus ne peut pas obtenir le verrou dans Win7 (java7). Pourquoi? TryLock n'est-il pas exclusif ?

En fait, ce n'est pas que TryLock n'est pas exclusif, mais un problème avec channel.close Le communiqué officiel est :

On some systems, closing a channel releases all locks held by the Java virtual machine on the 
 underlying file regardless of whether the locks were acquired via that channel or via  
another channel open on the same file.It is strongly recommended that, within a program, a unique 
 channel be used to acquire all locks on any given file.

<. 🎜>La raison est que dans certaines opérations du système, la fermeture d'un canal entraînera la libération de tous les verrous par la JVM. En d'autres termes, il est clair pourquoi le deuxième cas de test ci-dessus a échoué, car après que le deuxième thread du premier processus n'a pas réussi à acquérir le verrou, nous avons appelé canal.close, ce qui entraînera la libération de tous les verrous et de tous les seconds processus. le verrouillage sera obtenu avec succès.

Après un voyage tortueux pour trouver la vérité, j'ai finalement trouvé un article sur stackoverflow, qui soulignait que NativeFSLock de Lucence nécessite également une écriture exclusive par plusieurs processus. L'auteur fait référence au code source NativeFSLock de Lucence 4.10.4. L'adresse visible spécifique et la méthode d'obtention spécifique sont les suivantes :

(1) Chaque verrou. a un fichier local correspondant.

(2) Un Set de type statique local thread-safe conserve les chemins de fichiers de tous les verrous actuels pour éviter que plusieurs threads n'acquièrent des verrous en même temps. Pour acquérir des verrous, plusieurs threads doivent uniquement déterminer si LOCK_HELD est déjà utilisé. a un chemin de fichier correspondant Cela signifie que le verrou a été acquis, sinon cela signifie qu'il n'a pas été acquis.
(3) En supposant que LOCK_HELD n'a pas de chemin de fichier correspondant, vous pouvez essayer de verrouiller le canal Fichier.

public synchronized boolean obtain() throws IOException { 
    if (lock != null) { 
      // Our instance is already locked: 
      return false; 
    } 
    // Ensure that lockDir exists and is a directory. 
    if (!lockDir.exists()) { 
      if (!lockDir.mkdirs()) 
        throw new IOException("Cannot create directory: " + lockDir.getAbsolutePath()); 
    } else if (!lockDir.isDirectory()) { 
      // TODO: NoSuchDirectoryException instead? 
      throw new IOException("Found regular file where directory expected: " + lockDir.getAbsolutePath()); 
    } 
    final String canonicalPath = path.getCanonicalPath(); 
    // Make sure nobody else in-process has this lock held 
    // already, and, mark it held if not: 
    // This is a pretty crazy workaround for some documented 
    // but yet awkward JVM behavior: 
    // 
    // On some systems, closing a channel releases all locks held by the 
    // Java virtual machine on the underlying file 
    // regardless of whether the locks were acquired via that channel or via 
    // another channel open on the same file. 
    // It is strongly recommended that, within a program, a unique channel 
    // be used to acquire all locks on any given 
    // file. 
    // 
    // This essentially means if we close "A" channel for a given file all 
    // locks might be released... the odd part 
    // is that we can't re-obtain the lock in the same JVM but from a 
    // different process if that happens. Nevertheless 
    // this is super trappy. See LUCENE-5738 
    boolean obtained = false; 
    if (LOCK_HELD.add(canonicalPath)) { 
      try { 
        channel = FileChannel.open(path.toPath(), StandardOpenOption.CREATE, StandardOpenOption.WRITE); 
        try { 
          lock = channel.tryLock(); 
          obtained = lock != null; 
        } catch (IOException | OverlappingFileLockException e) { 
          // At least on OS X, we will sometimes get an 
          // intermittent "Permission Denied" IOException, 
          // which seems to simply mean "you failed to get 
          // the lock". But other IOExceptions could be 
          // "permanent" (eg, locking is not supported via 
          // the filesystem). So, we record the failure 
          // reason here; the timeout obtain (usually the 
          // one calling us) will use this as "root cause" 
          // if it fails to get the lock. 
          failureReason = e; 
        } 
      } finally { 
        if (obtained == false) { // not successful - clear up and move 
                      // out 
          clearLockHeld(path); 
          final FileChannel toClose = channel; 
          channel = null; 
          closeWhileHandlingException(toClose); 
        } 
      } 
    } 
    return obtained; 
  }

Résumé

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!