ReentrantLocksデッドロックを防ぐために、スレッドがより高い ID のロックを取得する前に、より低い ID のロックを取得する必要がある、一意の整数 ID を持つ一連のラップがあります。3 つのロック (lock0、lock1、および lock2) は、より高い ID を持つロックよりも優先度が高く、他のすべてのロックの優先度は同じです。つまり、スレッドがこれら 3 つの優先度の高いロックのいずれかを取得すると、必要な優先度の低いロックを保持している他のスレッドを中断する必要があります。たとえば、スレッド 1 はロック 4 とロック 5 を保持しており、スレッド 0 はロック 0 を保持しており、ロック 4 とロック 5 を必要としているため、スレッド 0 はスレッド 1 に割り込みlockInterruptiblyますisInterruptedメソッド) を取得し、そのロックを取得します。Thread1 は、Thread0 から通知されるまで待機します (つまり、Thread0 がロックを終了するまで、ロックを再取得しようとはしません)。
これは、いくつかの理由で理想的ではありません。理想的には、Thread1 が Thread0 の割り込みを処理している間、他のスレッドが先にジャンプしてロックを取得しないように、Thread0 がすぐにロックが必要であることを通知するようにします (つまり、Thread0 は待機中のスレッドのキューに入り、Thread2 が試行した場合Thread0 が Thread1 に割り込んでいる間にロックを取得するには、Thread0 が Thread2 の前にロックを取得します) - たとえば、tryLock別のスレッドがロックを保持している場合に、そのスレッドをロックのキューに追加するバリアント。また、現在、ロック 4 またはロック 5 でキューに入れられたスレッドがある場合、スレッド 0 はそれらがロックを取得するのを待ってからそれらを中断する必要があります。スレッドは優先度の高いロックを保持していました)。lockInterruptibly最後に、スレッド 1がすべてのロックを放棄する必要はありません。中断されたときにすべてのロックを放棄します(スレッドがロックの取得を待機している間に中断されたと仮定します)。
車輪を再発明する前に、これらの要件の一部またはすべて、または何らかの種類を既に実装しているロック クラスがあるかどうか疑問に思っていましたPriorityReentrantLock。私は を見て、自分のニーズを満たすためにそれを変更するのにあまり多くの作業をAbstractQueuedSynchronizer必要としないとは思いません(特に優先度が 2 つしか必要ないため)。より良い。