java.util.concurrent.locks
인터페이스 ReadWriteLock

기존의 구현 클래스의 일람:

ReentrantReadWriteLock

public interface ReadWriteLock

ReadWriteLock 는, 읽기 전용 조작용 및 기입해 용무의, 관련하는락 의 페어를 제어합니다. read 락 은, 라이터가 존재하지 않는 한, 복수의 리더 thread를 동시에 보관 유지할 수 있습니다. 기입 락 은 배타적입니다.

모든 ReadWriteLock 구현으로, 관련지을 수 있었던 readLock 에 대한 writeLock 조작의 메모리 동기 효과 (Lock 인터페이스로 지정)도 보관 유지하는 것을 보증할 필요가 있습니다. 즉, 정상적으로 읽어들여 락을 취득한 thread에서는, 기입 락이 전회 해제되었을 때에 행해진 모든 갱신 내용을 인식합니다.

읽어들여 - 기입 락을 사용하면(자), 상호 배타 락을 사용하는 경우보다 광범위한 병행성을 공유 데이터에의 액세스에 갖게할 수가 있습니다. 이 락은, 공유 데이터를 한 번으로 변경할 수 있는 것은 단일의 thread ( 「라이터」thread) 뿐인 것, 및 많은 경우, 임의수의 thread ( 「리더」thread)가 데이터를 병행해 읽어들일 수가 있다고 하는 사실을 이용합니다. 이론상은, 읽어들여 - 기입 락의 사용으로 허가되는 병행성을 향상시키면(자), 상호 배타 락을 사용하는 경우와 비교해 퍼포먼스가 향상합니다. 실제로는, 병행성 향상이 충분히 실현되는 것은, 복수의 프로세서상에서 사용되어 공유 데이터의 액세스 패턴이 적합한 경우만입니다.

읽기-기입 락에 의해 상호 배타 락보다 퍼포먼스가 향상할지 어떨지는, 데이터 변경에 대한 데이터 읽을 빈도, 읽기 및 기입의 지속 기간, 및 데이터의 경합, 즉 동시에 데이터를 읽어내는 또는 기입하는 thread의 수에 의존합니다. 예를 들어, 데이터가 넣을 수 있던 뒤, 너무 변경되는 일 없이 (디렉토리등이) 빈번하게 검색되는 컬렉션은, 읽기-기입 락의 이상적인 후보가 됩니다. 다만, 갱신이 빈번하게 행해지는 경우, 데이터의 시간의 대부분은 배타적 락에 소비되기 (위해)때문에, 병행성은 향상한다고 해도 매우 정확히 알 수 없는 것입니다. 게다가 읽어들여 조작의 시간이 너무 짧으면(자), 읽기-기입 락의 구현에 의한 오버헤드 (본래, 상호 배타 락보다 복잡)에 의해 실행 코스트가 지배되어 버릴 가능성이 있습니다. 다수의 읽기-기입 락 구현이 적은 코드 섹션으로 모든 thread를 직렬화하는 경우는, 특히 이것이 들어맞읍니다. 결국, read-기입 락이 사용하는 어플리케이션에 적절하고 있는지 어떤지를 조사하려면 , 프로 파일링과 계측을 실행할 수 밖에 없습니다. read-기입 락의 기본 조작은 복잡하지는 않습니다만, 구현으로 실시할 필요가 있는 정책상의 결정이 다수 존재합니다.

이러한 결정은, 지정된 어플리케이션에서의 읽어들여-기입 락의 효과성에 영향을 주는 경우가 있습니다. 이러한 정책의 예를, 다음에 나타냅니다.

• 라이터가 기입해 락을 해제했을 때에, read 락 또는 기입해 락을 허가할지 어떨지, 언제 리더 및 라이터의 양쪽 모두를 대기시킬까를 결정한다. 라이터는 단기적으로 사용 빈도도 적은 것이 기대되기 (위해)때문에, 라이터 우선은 일반적이다. 리더가 예상 대로 빈번하게 실행되어 장시간의 경우, 기입의 지연이 커지기 (위해)때문에, 리더 우선은 일반적이지 않다. 공평, 즉 「순서」구현도 가능하다.
• 리더가 액티브해 라이터가 대기중에, read 락을 요구한 리더가 읽어내 락이 허가될지 어떨지를 판별한다. 라이터에 대한 우선이 병행성의 가능성을 저하시킬 가능성이 있는데 대해, 리더에 대한 우선은 라이터를 무제한하게 늦출 가능성이 있다.
• 락이 재입 가능한가 어떤가 (기입 락을 가지는 thread가 그것을 재취득 가능한가, 기입 락을 가지면서 read 락을 취득 가능한가, read 락 자체가 재입 가능한가)를 판정한다.
• 개입하는 라이터를 허가하는 일 없이, 기입 락을 읽어들여 락에 격하 가능한가. read 락을, 대기중외의 리더나 라이터보다 우선해 기입 락에 승격 가능한가.

지정된 어플리케이션 구현의 적성을 평가할 때, 이것들 모든 것을 고려할 필요가 있습니다.

도입된 버젼:

1.5

관련 항목:

ReentrantReadWriteLock , Lock , ReentrantLock

메소드의 개요

Lock	readLock () 읽어들여에 사용하는 락을 돌려줍니다.
Lock	writeLock () 기입해에 사용하는 락을 돌려줍니다.

메소드의 상세

readLock

Lock  readLock()

읽어들여에 사용하는 락을 돌려줍니다.

반환값:

읽어들여에 사용하는 락

writeLock

Lock  writeLock()

기입해에 사용하는 락을 돌려줍니다.

반환값:

기입해에 사용하는 락