問題タブ [reentrantreadwritelock]

私のアプリケーションは、Java 6 update 30 を使用して Weblogic 10.3.5 にデプロイされています。このコード行の実行中に、次のエラーが発生しました。

クラスのロード中にロックが初期化されている間：

キャッシュは次のとおりです。

突然 IllegalMonitorStateException がスローされました:

ここで、このシナリオと同様の説明を読みました。

なぜこれが起こるのか誰にも分かりますか？

Java Gurus、

現在、頻繁HashMap<String,SomeApplicationObject>に読み取られ、時々変更されるがあり、変更/再ロード中に読み取り操作が返されるという問題がありますが、nullこれは受け入れられません。

これを修正するには、次のオプションがあります。

A.ConcurrentHashMapを使用します

これは最初の選択肢のように見えますが、私たちが話している操作はreload()-という意味でclear()、その後に。が続きreplaceAll()ます。したがって、Mapがpostclear()およびprereplaceAll()で読み取られた場合、nullが返されますが、これは望ましくありません。私がsynchronizeこれで問題が解決しない場合でも。

B.ReentrantReadWriteLockに基づいて別の実装を作成します

Write Lock操作前に取得を作成する場所reload()。これはより適切に思えますが、これにはすでに何かが利用可能であるに違いないと感じており、車輪の再発明をする必要はありません。

最善の方法は何ですか？

編集そのような機能を備えたコレクションはすでに利用可能ですか？

それはReentrantReadWriteLock一人の作家と複数の読者を対象としていると言われています。

それでも、リーダーは、バッファーにデータが存在するまで待つ必要があります。

だから、何をロックするのですか？

次のような同時実行オブジェクトを作成しました。

今書き込みメソッドで私はします：

しかし、リーダーを書く方法は？取得するだけでreadLockいいですか？しかし、それではどのようにして信号を待つことができるのでしょうか？それがまた取得する場合、writeLock読み取り/書き込みロックの優位性はどこにありますか？

必要な変数がによってのみ保護されている場合、読み取り中に必要な変数が変更されないようにするにはどうすればよいwriteLockですか？

キューはタスクに一致しません

これはについての質問ですReentrantReadWriteLock。

契約について詳しく教えてください。に含まれる 2 つのロックがReentrantReadWriteLock何らかの形で関連しているかどうかわかりません。それとも、これらは 2 つの通常のロックの単なるバンドルですか?

かなり一般的な質問ですが、アドバイスをお願いします。

私はサーブレットを持っています。

このサーブレットにはプライベート フィールドがあります。

プライベート フィールドは一種のメタデータです (public class Metadata{//bla-bla-bla})。

GETリクエストが処理されると、このメタデータを使用して何らかの操作が実行されます。

同じサーブレットに POST メソッドを実装したい。ユーザーがファイルをアップロードすると、メタデータ フィールドが更新されます。

問題: 1 つのサーブレット インスタンスを使用して、複数の Web スレッド間で共有される Metadata オブジェクトを使用して、このプライベート フィールドに同時にアクセスします。POST メソッド操作 (メタデータ オブジェクトの更新) により、メタデータの不整合状態が発生し、同時 GET 要求が失敗する可能性があります。

質問: GET リクエストの実行中に Metadata オブジェクトを更新する最良の方法は何ですか?

ダミーソリューション：

1. 各 GET リクエストの間、最初に

2. メタデータ オブジェクトを同期し、1 つのブロックに複製してから解放します。

3. 同時 GET リクエストは、一貫性のある Metadata オブジェクトのクローン バージョンで動作します。

4. 各 POST リクエスト中。

5. メタデータ オブジェクトを同期し、そのフィールドを更新します。

6. Metadata オブジェクトを解放します。

アドバイスや批判をお願いします。

タイトルが示すように、現在のスレッドがクラッシュしたときに readwritelock がどうなるか興味があります。

最終ブロックで確実にロックを解除して、突然の中断を防ぐことができます。しかし、readLock.lock() ステートメントがクラッシュした場合、ロックは自動的に解除されるのでしょうか?

ありがとう、

使用パターンは、次の理由から生じました。

1. 条件付きでデータが存在しない場合、データを待機するために読み取りスレッドが必要です。

2. 読み取りロックは条件をサポートしていないため、条件は書き込みロックから取得する必要があります。

3. 読み取りスレッドは状態を待機するため、待機するために書き込みロックも取得する必要があります。

クラスに次のロック定義があります。

私のライターメソッドには、次のパターンがあります。

私の読み取り方法では、次のパターンがあります

上記のパターンは正しいですか？

問題は、reader が再入可能である場合、つまり 2 回以上読み取りをロックしている場合、解放コードが機能せず、reader が書き込みロックを取得する行でハングすることです。

RentrantReadWriteLockについての私の理解では、同時に多くの読み取りが許可されますが、書き込みは 1 回しか許可されません。

読み取りロックを取得しようとすると、ドキュメントの状態

heldここで とはどういう意味ですか ?

• 別のスレッドが書き込みロックを要求し、書き込みよりも実行されましたか?

また

• 上記と、別のスレッドが書き込みロックを要求したが、それを取得するのを待っている場合。

書き込みロックが要求されたとき、次の場合は許可されないためです。

• 他の誰かが書き込みロックを持っています
• 他の誰かが読み取りロックを持っています

書き込みロックドキュメントから:

したがって、スレッドが要求後に書き込みロックを待機している場合、読み取りロックの呼び出しのその後の動作について知りたいだけです。書き込みロックの要求をさらに長く待機させますか?

Java の実装ロックでは、ロックを読み取りロックから書き込みロックにアトミックにアップグレードする方法はありません。たとえば、次のコード スニペットは失敗します。

書き込みロックの取得は、すべての読み取りロックが完了するまで待機する必要があるため、リーダーが読み取っている可能性のあるデータを上書きしていないことがわかります。良くないね。したがって、回避策は次のようにすることです。

しかし、これは理想的ではありません。読み取りのロックを解除して書き込みを取得する間に、誰かが行って何かを行う可能性があります。とにかく、これらの条件を再確認することはおそらく良い考えですが、それでも - それは醜いです.

通常、ロックを取得するときは、実際にロックを取得するまでコードを強制的に待機させてから、行っていることを実行します。データをいじり始める前に、ロック機構がロックを与えてくれるということだけを信頼したくはありません。

しかし、ロックが必要であることを通知したときから、実際に待機するように読み取られるまで、実行を強制的に停止する必要があるのはなぜでしょうか? たとえば、次のようなことが許可されなかった理由は次のとおりです。

したがって、ある意味では、現在のロック機能は、次のように両方が同時に行われていると理論化できます。

ある種の遅延インテントのロックを許可しないようにする設計上の決定は何ですか? そのようなロックの設計には、単に私が気付いていない重大な問題がありますか?