|
JavaTM 2 Platform Standard Ed. 5.0 |
|||||||||
| 이전 클래스 다음 클래스 | 프레임으로 프레임 없이 | |||||||||
| 개요: NESTED | 필드 | 생성자 | 메서드 | 상세: 필드 | 생성자 | 메서드 | |||||||||
public interface ReadWriteLock
ReadWriteLock는
읽기 전용
조작용 및 write무의, 관련하는락
페어를 제어합니다. read 락 은 라이터가 존재하지 않는 한, 복수의 리더 thread를 동시에 보관 유지할 수 있습니다. 출력 락 은 배타적입니다.
읽기 - 출력 락을 사용하면, 상호 배타 락을 사용하는 경우보다 광범위한 병행성을 공유 데이터에의 액세스에 갖게할 수 있습니다 . 이 락은 공유 데이터를 한 번으로 변경할 수 있는 것은 단일의 thread ( 「라이터」thread) 뿐인 것 및 많은 경우, 임의수의 thread ( 「리더」thread)가 데이터를 동시에 읽어들일 수가 있다고 하는 사실을 이용합니다. 이론상은 읽기 - 출력 락의 사용으로 허가되는 병행성을 향상시키면, 상호 배타 락을 사용하는 경우와 비교해 퍼포먼스가 향상합니다. 실제로는 병행성 향상이 충분히 실현되는 것은 복수의 프로세서상에서 사용되어 공유 데이터의 액세스 패턴이 적합한 경우만입니다.
독해-출력 락에 의해 상호 배타 락보다 퍼포먼스가 향상할지 어떨지는 데이터 변경에 대한 데이터 읽을 빈도, 독해 및 출력의 지속 기간 및 데이터의 경합, 즉 동시에 데이터를 읽어내는 또는 출력하는 thread의 수에 의존합니다. 예를 들어 데이터가 넣을 수 있던뒤 너무 변경되는 일 없이 (디렉토리등이) 빈번하게 검색되는 컬렉션은 독해-출력 락의 이상적인 후보가 됩니다. 다만, 갱신이 빈번하게 행해지는 경우, 데이터의 시간의 대부분은 배타적 락에 소비되기 때문에 병행성은 향상한다고 해도 매우 불과입니다. 게다가 읽기 조작의 시간이 너무 짧으면, 독해-출력 락의 구현에 한 오버헤드 (본래, 상호 배타 락보다 복잡)에 의해 실행 코스트가 지배되어 버릴 가능성이 있습니다. 다수의 독해-출력 락 구현이 적은 코드 섹션으로 모든 thread를 직렬화하는 경우는 특히 이것이 들어맞읍니다. 결국, read-출력 락이 사용하는 어플리케이션에 적절하고 있는지를 조사하려면, 프로 파일링과 파악을 실행할 수 밖에 없습니다.
read-출력 락의 기본 조작은 복잡하지는 않습니다만, 구현으로 실시할 필요가 있는 정책 상의 결정이 다수 존재합니다. 이러한 결정은 지정된 어플리케이션에서의 읽기 -출력 락의 효과성에 영향을 주는 경우가 있습니다. 이러한 정책 의 예를, 다음에 나타냅니다.
ReentrantReadWriteLock,
Lock,
ReentrantLock | 메서드 개요 | |
|---|---|
Lock |
readLock ()
읽기에 사용하는 락을 리턴합니다. |
Lock |
writeLock ()
출력을 사용하는 락을 리턴합니다. |
| 메서드의 상세 |
|---|
Lock readLock()
Lock writeLock()
|
JavaTM 2 Platform Standard Ed. 5.0 |
|||||||||
| 이전 클래스 다음 클래스 | 프레임으로 프레임 없이 | |||||||||
| 개요: NESTED | 필드 | 생성자 | 메서드 | 상세: 필드 | 생성자 | 메서드 | |||||||||
Copyright 2004 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms . Documentation Redistribution Policy 도 참조하십시오.