は、再入可能なロックは同期の完全な置き換えですか？

Question

記事「http://www.ibm.com/developerworks/java/library/j-jtp10264/」を読んでいます。「Lockフレームワークは同期の互換性のある置き換えです」と述べました。私は、リエントラントロックを使用することによって、メソッド間でロックを保持し、一定の時間（ロックされたブロック（または）メソッドを使用することはできません）ロックを待機できることを理解しました。私の疑問は、アプリケーションをリエントラントロックの同期メカニズムで置き換えることが可能なのでしょうか？

たとえば、すべてのpush、pop、getTopメソッドが同期するスレッドセーフスタックデータ構造を実装したいので、マルチスレッド環境では、一度に1つのスレッドだけが1つの同期メソッドにアクセスできますあるスレッドがpushメソッドを使用している場合、他のスレッドはpushクラス、popクラス、getTopクラス（またはその他のStackクラスの同期メソッド）にアクセスできません。再入可能ロックを使用して同じスレッドセーフスタックデータ構造を実装することは可能ですか？可能であれば、これを理解するための例を提供してください。

Answer 1

答えは「はい」です。

lock-unlocksynchronize() { ... }の代わりにペアが使用されます。 awaitおよびsignalのConditionは、waitおよびnotifyの代わりです。

Answer 2

​​でできることは、ReentrantLockでも可能ですが、その逆もありません。あなたが必要とするものがすべてlock/unlockセマンティクスであれば、私は​​と思っています。

Answer 3

ブライアン・ゲッツは章13.4で"Java Concurrency in Practice"でこれを説明：

ReentrantLock真性ロックが実用的でない状況のための高度なツールです。タイムリー、ポーリング、または割り込み可能なロック取得、公正なキューイング、またはブロック化されていない構造化のロックなどの高度な機能が必要な場合に使用します。それ以外の場合は、同期を優先します。

try { 
    lock.lock(); 
    // ... 
} finally { 
    lock.unlock(); 
} 

かいつまん：

synchronized (lock) { 
    // ... 
} 

方法がより読みやすく、これよりも発生しやすい小さい誤差である：IMHO、これがため

は、私は絶対に同意する技術的な観点から、はい​​をReentrantLockに置き換えることもできますが、それ自体はできません。

また、これらの質問をチェックアウト：

• Synchronization vs Lock
• Why use a ReentrantLock if one can use synchronized(this)?

Answer 4

ReentrantLockは、同期の選択肢の一つです。

リエントラント相互排除同期メソッドとステートメントを使用してアクセスされる暗黙のモニタロックと同じ基本的な動作とセマンティクスでロックされますが、拡張機能があります。

同期に他の選択肢（並行コレクション、アトミック変数、エグゼキュータ、ThreadLocalの変数）のためにこの質問をを参照してください。

Avoid synchronized(this) in Java?