再入可能ロックと同期の実装方法が異なる

Question

javaソースコードごと

ReentrantLockのロック（不公平）は以下のとおりです。

public boolean lock(){ 
     int c=getState(); 
     if(c==0){ 
     compareAndSetState(0,1); 
     } 
} 
//getState method 
public int getState(){ 
    return state; 
} 
public boolean compareAndSetState(int expected,int update){ 
    unsafe.compareAndSwapInt(this, stateOffset, expect, update); 
} 

とstateOffSetの値（リフレクションを使用して）メモリに状態のオフセットされています。上記のコードからわかるように、lock.lock（）を呼び出すと、の最初の値のフィールドがチェックインされ、ゼロの場合は呼び出しスレッドのみがロックされます。

だから私の質問は私たちのユーザーが同期したキーワードですか？ Synchronizedでロックのいくつかのフィールドもチェックされ、設定されていますか？

もう1つ疑問ですが、どこかで私はリエントラントロックで複数の待機キューを許可していますが、それはどういう意味ですか？

Answer 1

リエントラントロックでは複数の待機キューが可能ですが、それはどういう意味ですか？

それはあなたがReentrantLockオブジェクトから複数のConditionオブジェクトを取得できることを意味します。スレッドがロックによって保護されているものを待つ理由が複数ある場合に便利です。

典型的な例は、マルチプロデューサ、マルチコンシューマキューです。コンシューマがキューが空でなくなるのを待つために使用するConditionと、プロデューサが空でない状態になるのを待つ別のConditionを持つことができます。それが最適化です。これは、プロデューサーが他の待機中のプロデューサーを目覚めさせず、消費者が他の待機中の消費者を目覚めさせないことを保証する。

o.wait()メソッドは、待機中のイベントをスレッドが示すことができないため、​​ブロックでキューを保護すると、同じ最適化は使用できません。 2つのスレッドがオンに同期するために許可されません。私たちはあなたがJava言語仕様で読んだことあるのを確認することができます​​キーワードに

だけのものを使用するときに何が起こるか

---

同時に同じオブジェクト、メモリの可視性への影響、などが実装される方法については

は、...それは、異なるアーキテクチャ上の異なる、多分異なるオペレーティングシステムになります。ほとんどのハードウェア・アーキテクチャは、それを行うには、およそ1合理的な方法を提供するため、最低レベルで、それおそらくはどのようReentrantLock作品のようになります。しかし、​​実装（ある場合）とReentrantLock実装で使用される中間レベルのAPIとライブラリの詳細は異なる場合があります。確実に知る唯一の方法は、JVMとライブラリのソースコードを調べることです。