問題タブ [reentrantlock]

Java JREでコードを見ました

ロックがプライベート変数にキャプチャされるのはなぜですか? 私は単純に期待します

synchronizedReentrantLock の Java API を調べたところ、キーワードで同期が使用されていないことがわかりました。オブジェクトを同期するのは、AbstractQueuedSynchronizer (ロックを取得しようとするときに ReentrantLock が参照している) の以下のメソッドにありますか? はネイティブ メソッドであるためcompareAndSwapInt、同期はネイティブ レベル/コードで行われますか?

RentrantLockを使用してエンティティの特定のインスタンス（キーで識別される）を変更する非同期の試行をブロックすることにより、Javaアプリケーションで並行性を強制するクラスを実装しようとしています。目標は、前のスレッドが完了するまで、オブジェクトの特定のインスタンスを変更する複数の同時試行をブロック/キューに入れることです。クラスはこれを一般的な方法で実装し、コードの任意のブロックがロックを取得して解放できるようにします（RentrantLockセマンティクスと同じ）。オブジェクトの同じインスタンスを変更しようとするスレッドのみをブロックするユーティリティが追加されます（識別されたとおり）。キーによって）コードのブロックに入るすべてのスレッドをブロックするのではなく。

このクラスは、エンティティの1つのインスタンスに対してのみコードのブロックを同期できるようにするための単純な構造を提供します。たとえば、ID 33のユーザーからのすべてのスレッドに対してコードのブロックを同期させたいが、他のユーザーのスレッドをスレッドサービスユーザー33によってブロックしたくない場合です。

クラスは次のように実装されます

このクラスは次のように使用されます。

問題は、それが完全に機能しないことです。同時実行性の負荷が非常に高い場合でも、同じキーを持つ複数のスレッドが同期されていない場合があります。私はかなり徹底的にテストしましたが、なぜ/どこでこれが発生するのか理解できません。

並行性の専門家はいますか？

クリック可能なウィジェットを開発しています。静的な java.util.concurrent.locks ReentrantLock を使用して、ウィジェット ロジックが一度に 1 回だけ呼び出されるようにします。

しかし、私の恐れは、10 秒のライフサイクル ウィンドウのためにロックが事前に殺されるため、非常にまれな状態でロックが解除されない可能性があることです。

ReentrantLock を使用することに異論はありますか? ロックを解除する最良の方法は何ですか?

または、シングルスレッドのみで実行する Android オプションはありますか?

現時点では、finally ブロックまたは finalize メソッド (痛い) で onReceive の最後にロックを解除することを考えています。

データを読み書きできるデータベースを実装しています。同時実行の問題については、ロックを実装する必要があります。通常、ReentrantReadWriteLock は、読み取りの前に書き込みを実行させます。どうすれば逆にいけますか? 書き込みスレッドが実行される前に読み取る方法はありますか?

再利用可能なコードを作成して、タスクをエグゼキューター サービスに送信する際に待機状態を許可したいと考えています。あまりにも多くのタスクがキューに入っている場合にブロックするためのきちんとした方法の実装がたくさんあります。

タスクが終了するたびに、待機中のすべてのスレッドを評価するエグゼキューターが必要です。タスクを atm に送信できるかどうかを判断するには、アクティブなすべてのタスクの現在の状態を考慮する必要があります。私は次の解決策を思いつきました。これは、複数の送信者や高度な同時実行タスクに合わせて拡張する必要はありません。

質問:次のコードは安全に使用できますか? それとも、見落としている欠陥がありますか? aquireAccessのメソッドを実装する人はConditionEvaluator<T>、クエリされたスレッドの状態がスレッド セーフであることを確認する必要がありますが、実装者は activeTasks コレクションに対する反復を保護する必要はありません。コードは次のとおりです。

質問:コードを改善できますか?

を使用できる場合、並行性のロックが非常に重要になる理由を理解しようとしていますsynchronized (this)。以下のダミーコードでは、次のいずれかを実行できます。

1. メソッド全体を同期するか、脆弱な領域を同期します（synchronized(this){...}）
2. または、脆弱なコード領域をReentrantLockでロックします。

コード：

以下は、典型的なリーダーとライターのパターンです (読み取りが多く、書き込みが少ない)。

ライターとリーダーを優先することは可能ですか？たとえば、通常、ライターは、他のスレッドによって保持されている読み取りロックが常に保持されている場合、非常に長い時間 (おそらく永遠に) 待機する可能性があるため、より高い優先度のライターを使用することは可能ですか?優先度の高い（スキップライン）そのようなもの。

I was writing my own implementation of BlockingQueue for practice. I am trying to avoid using the synchronized keyword for the methods. I would instead like to use ReentrantLock.

What is the best way to write this implementation? I am not a Java ninja and would greatly appreciate if someone could pinpoint the errors in my code here and suggest better ways of implementing it.

Thanks for your time!

このページの例に基づいてスレッドプールを作成しました。ワーカースレッドには、スレッドを停止させない無限ループと、実行する作業がないときにスレッドを一時停止するwait（）メソッド呼び出しがあります。

実際には、キューが空の場合、RuntimeExceptionであるr = (Runnable) queue.removeFirst();をスローする可能性があります。NoSuchElementExceptionそして、そのような例外がその行でスローされると、ミューテックスを保持している現在のスレッドが停止し、プールがスレッドをリークします。スレッドが終了すると、ミューテックスが解放されるようです。

ただし、デフォルトのsynchronizedキーワードを使用してキューを同期する代わりに、を使用しReentrantLockてロックしCondition、シグナリングと待機を行う場合、ミューテックスを保持している現在のスレッドは、予期せず中断したときにロックを解放しないようです。

したがって、私の場合、[スレッド]タブでJVisualVMを確認すると、AWT-EventQueue-0スレッドがThread-1ミューテックスの解放を待っていることがわかりました。しかし、Thread-1はタスクを実行する途中で停止し、予期せず終了し（RuntumeException）、ミューテックスは解放されなかったようです。

私の質問：

1） ReentrantLocksを保持しているスレッドが予期せず終了した場合、ReentrantLocksは解放されませんか？

2）上記のコードスニペットwhile (queue.isEmpty()) {との間に違いはありますか？if (queue.isEmpty()) {どちらの場合もスレッドは待機するため、違いはわかりません。ただし、使用時の動作は異なると思いますif（複数のスレッドがキューに影響を与える可能性がある場合など）。

実際のJava同時実行の編集状態：

これらすべての理由から、待機から復帰するときは、条件述語を再度テストし、それがまだ真でない場合は待機に戻る（または失敗する）必要があります。条件述語がtrueでなくても繰り返しウェイクアップできるため、常にループ内からwaitを呼び出して、各反復で条件述語をテストする必要があります。

上記のコードでの私の編集を見てください。これで、コードはJava ConcurrencyinPracticeに記載されているとおりに正しくなるはずです。