Java排他ロック実装の詳細コード説明

この記事では、主に排他ロックを実装するための Java プログラミングの関連内容を紹介し、このコード ロックを実装するために必要な関数と著者の解決策を説明し、必要な友人が参照できるように設計ソース コードを共有します。

1. はじめに

某年某月某日、同僚からファイルの排他ロック機能が必要だと言われました。

(1)書き込み操作は排他属性です
(2) 同一プロセスに適用可能 マルチスレッド/複数プロセスの排他操作にも適しています
(3) 耐障害性: ロックを取得するプロセスがクラッシュしても、通常のロックの取得には影響しません。後続のプロセスによるロック

2. 解決策

1. 元のアイデア

Java 分野では、同じプロセス内でのマルチスレッドの排他的な実装は比較的単純です。たとえば、スレッド同期変数を使用して、スレッドがロックされているかどうかを示すことができます。ただし、さまざまなプロセスを排他的に実装するのはさらに面倒です。既存の API を使用して、自然に java.nio.channels.FileLock: を次のように考えました

/** 
   * @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; 
  }

すべてがとても美しく、完璧に見えます。そこで、2 つのテスト シナリオ コードが追加されました:

(1) 同じプロセスで、2 つのスレッドが同時にロックを競合します。テスト プログラム A と仮名を付けます。予想される結果: 1 つのスレッドがロックの取得に失敗しました
(2) 2 つのプロセスを実行します。つまり、2 つのテスト プログラム A を実行し、結果を期待します。1 つのプロセスとスレッドはロックを取得し、もう 1 つのスレッドはロックの取得に失敗します

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。あなたが考えているものではありません

上記のテストコードは、私たちの期待は単一のプロセス内で満たされます。ただし、2 つのプロセスを同時に実行した場合、Mac 環境 (java8) では 2 番目のプロセスは正常にロックを取得できますが、Win7 (java7) では 2 番目のプロセスはロックを取得できません。なぜ？ TryLock は排他的ではないですか?

実際、TryLock が排他的ではないということではなく、channel.close の問題が原因です。公式声明は次のとおりです:

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.

その理由は、一部のオペレーティング システムでは、チャネルを閉じると JVM エラーが発生するためです。すべてのロックを解除します。言い換えれば、上記の 2 番目のテスト ケースが失敗した理由は明らかです。最初のプロセスの 2 番目のスレッドがロックの取得に失敗した後、channel.close を呼び出し、すべてのロックが解放され、すべての 2 番目のプロセスが呼び出されたからです。ロックは正常に取得されます。

真実を見つけるための曲がりくねった旅の末、最終的に stackoverflow で投稿を見つけました。その投稿では、Lucence の NativeFSLock も複数のプロセスによる排他的書き込みが必要であることが指摘されていました。筆者は、lucence 4.10.4 の NativeFSLock ソースコードを参照しています。具体的な可視アドレスと具体的な取得方法は次のとおりです。

(1) 各ロックはローカルに対応するファイルを持ちます。
(2) ローカルの静的型のスレッドセーフな Set LOCK_HELD は、複数のスレッドが同時にロックを取得するのを避けるために、現在のロックのファイル パスを維持します。対応するファイル パスが存在する場合は、ロックが取得されたことを意味し、そうでない場合は、ロックが取得されていないことを意味します。
(3) LOCK_HELD に対応するファイル パスがない場合は、ファイル チャネルを TryLock できます。

りー

概要

以上がJava排他ロック実装の詳細コード説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。