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; 
  }

모든 것이 너무 아름답고 흠 잡을 데 없는 것 같습니다. 그래서 두 개의 테스트 시나리오 코드가 추가되었습니다:

(1) 동일한 프로세스에서 두 개의 스레드가 동시에 잠금을 위해 경쟁하며 가칭 테스트 프로그램 A. 예상 결과: 하나의 스레드가 잠금을 획득하지 못했습니다
(2) 두 개의 프로세스를 실행합니다. 즉, 두 개의 테스트 프로그램 A를 실행하고 결과를 기대합니다. 한 프로세스와 스레드는 잠금을 획득하고 다른 스레드는 잠금을 획득하지 못합니다

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. 당신이 생각하는 것과는 다릅니다

위의 테스트 코드는 단일 프로세스 내에서 우리의 기대를 충족할 수 있습니다. 그러나 두 프로세스를 동시에 실행할 경우 Mac 환경(java8)에서는 두 번째 프로세스가 정상적으로 잠금을 획득할 수 있지만, Win7(java7)에서는 두 번째 프로세스가 잠금을 획득할 수 없습니다. 왜? TryLock은 독점적이지 않습니까?

사실 TryLock이 배타적이지 않다는 것은 아니지만, 채널.닫기에 문제가 있습니다. 공식 성명은 다음과 같습니다.

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이 발생하기 때문입니다. 모든 잠금을 해제합니다. 즉, 위의 두 번째 테스트 사례가 실패한 이유를 이해합니다. 첫 번째 프로세스의 두 번째 스레드가 잠금을 획득하는 데 실패한 후 모든 잠금이 해제되도록 하는 모든 잠금을 해제하는 모든 잠금을 유발하는 모든 두 번째 프로세스 잠금을 호출하기 때문입니다. 성공적으로 획득하게 됩니다.

진실을 찾기 위한 고된 여정 끝에 마침내 stackoverflow에서 Lucence의 NativeFSLock도 여러 프로세스에 의한 독점 작성이 필요하다는 내용의 게시물을 발견했습니다. 저자는 Lucence 4.10.4의 NativeFSLock 소스 코드를 참조합니다. 구체적인 표시 주소와 구체적인 획득 방법은 다음과 같습니다. NativeFSLock의 설계 아이디어는 다음과 같습니다.

(1) 각 잠금에는 로컬에 해당하는 파일이 있습니다.
(2) 로컬 정적 유형 스레드 안전 Setf7e83be87db5cd2d9a8a0b8117b38cd4 LOCK_HELD는 여러 스레드가 동시에 잠금을 획득하는 것을 방지하기 위해 모든 현재 잠금의 파일 경로를 유지합니다. 잠금을 획득하려면 여러 스레드가 LOCK_HELD에 이미 해당 파일 경로가 일치하면 잠금이 획득되었음을 의미하고, 그렇지 않으면 잠금이 획득되지 않았음을 의미합니다.
(3) LOCK_HELD에 해당 파일 경로가 없으면 파일 채널을 TryLock할 수 있습니다.

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; 
  }

요약

위 내용은 Java 배타적 잠금 구현에 대한 자세한 코드 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!