JavaTM Platform
Standard Ed. 6

java.util.concurrent.locks
インタフェース ReadWriteLock

既知の実装クラスの一覧:
ReentrantReadWriteLock

public interface ReadWriteLock

ReadWriteLock は、読み取り専用操作用および書き込み用の、関連するロックのペアを制御します。読み込みロックは、ライターが存在しないかぎり、複数のリーダースレッドが同時に保持できます。書き込みロックは排他的です。

すべての ReadWriteLock 実装で、関連付けられた readLock に対する writeLock 操作のメモリー同期効果 (Lock インタフェースで指定) も保持することを保証する必要があります。つまり、正常に読み込みロックを取得したスレッドでは、書き込みロックが前回解放されたときに行われたすべての更新内容を認識します。

読み込み - 書き込みロックを使用すると、相互排他ロックを使用する場合よりも広範な並行性を共有データへのアクセスに持たせることができます。このロックは、共有データを一度に変更できるのは単一のスレッド (「ライター」スレッド) だけであること、および多くの場合、任意数のスレッド (「リーダー」スレッド) がデータを並行して読み込むことができるという事実を利用します。理論上は、読み込み - 書き込みロックの使用で許可される並行性を向上させると、相互排他ロックを使用する場合と比べてパフォーマンスが向上します。実際には、並行性向上が十分に実現されるのは、複数のプロセッサ上で使用され、共有データのアクセスパターンが適している場合だけです。

読み取り−書き込みロックにより相互排他ロックよりもパフォーマンスが向上するかどうかは、データ変更に対するデータ読み込みの頻度、読み取りおよび書き込みの持続期間、およびデータの競合、つまり同時にデータを読み取るまたは書き込むスレッドの数に依存します。たとえば、データが入れられたあと、あまり変更されることなく (ディレクトリなどが) 頻繁に検索されるコレクションは、読み取り−書き込みロックの理想的な候補になります。ただし、更新が頻繁に行われる場合、データの時間の大半は排他的ロックに費やされるため、並行性は向上するとしてもごくわずかです。さらに、読み込み操作の時間が短すぎると、読み取り−書き込みロックの実装によるオーバーヘッド (本来、相互排他ロックよりも複雑) により実行コストが支配されてしまう可能性があります。多数の読み取り−書き込みロック実装が少ないコードセクションですべてのスレッドを直列化する場合は、特にこのことが当てはまります。結局のところ、読み込み−書き込みロックが使用するアプリケーションに適しているかどうかを調べるには、プロファイリングと計測を実行するしかありません。読み込み−書き込みロックの基本操作は複雑ではありませんが、実装で行う必要のあるポリシー上の決定が多数存在します。

これらの決定は、指定されたアプリケーションでの読み込み−書き込みロックの効果性に影響を与える場合があります。これらのポリシーの例を、次に示します。

指定されたアプリケーション実装の適性を評価する際、これらすべてを考慮する必要があります。

導入されたバージョン:
1.5
関連項目:
ReentrantReadWriteLock, Lock, ReentrantLock

メソッドの概要
 Lock readLock()
          読み込みに使用するロックを返します。
 Lock writeLock()
          書き込みに使用するロックを返します。
 

メソッドの詳細

readLock

Lock readLock()
読み込みに使用するロックを返します。

戻り値:
読み込みに使用するロック

writeLock

Lock writeLock()
書き込みに使用するロックを返します。

戻り値:
書き込みに使用するロック

JavaTM Platform
Standard Ed. 6

バグの報告と機能のリクエスト
さらに詳しい API リファレンスおよび開発者ドキュメントについては、Java SE 開発者用ドキュメントを参照してください。開発者向けの詳細な解説、概念の概要、用語の定義、バグの回避策、およびコード実例が含まれています。

Copyright 2006 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Documentation Redistribution Policy も参照してください。