揮発性とArrayBlockingQueueとおそらく他の同時オブジェクト

Question

volatileキーワードの背後にある原則を理解しています。 ConcurrentHashMap源に見たとき、あなたはすべてのノードとの値が値が複数のスレッドからの書き込み/読み出しをすることができますので、理にかなっている、volatile宣言されていることがわかります、

static class Node<K,V> implements Map.Entry<K,V> { 
    final int hash; 
    final K key; 
    volatile V val; 
    volatile Node<K,V> next; 
    ... 
} 

しかし、ArrayBlockingQueueソースに探してそれは複数のスレッドから読み取る/更新されているプレーンな配列です：

private void enqueue(E x) { 
    // assert lock.getHoldCount() == 1; 
    // assert items[putIndex] == null; 
    final Object[] items = this.items; 
    items[putIndex] = x; 
    if (++putIndex == items.length) 
     putIndex = 0; 
    count++; 
    notEmpty.signal(); 
} 

それはitems[putIndex]に挿入された値は、配列内の要素が揮発性でないことを提供し、別のスレッドから見えるようになることが保証されている方法（Iその宣言を知っている配列そのものは、要素そのものには何の効果もありません）？ 他のスレッドがキャッシュされた配列のコピーを保持できませんでしたか？

おかげ

Answer 1

enqueueがprivateであることに注目してください。すべてのコールを探してください（offer(E), offer(E, long, TimeUnit), put(E)）。

public void put(E e) throws InterruptedException { 
    checkNotNull(e); 
    final ReentrantLock lock = this.lock; 
    lock.lockInterruptibly(); 
    try { 
     // Do stuff. 
     enqueue(e); 
    } finally { 
     lock.unlock(); 
    } 
} 

ですから、enqueueへのすべての呼び出しがlock.lock() ... lock.unlock()によって保護されてlock.lock/unlockは、メモリバリアであるため、あなたはvolatileを必要としないと結論づけることができますように、これらのルックスの一つ一つがいることに注意してください。

Answer 2

私の理解によれば、すべてのBlockingQueue実装は既にConcurrentHashMapとは違ってロック機構を持っているので、volatileは必要ありません。 Queueのパブリックメソッドを見ると、同時アクセスを守るReentrantLockが見つかります。