ReentrantLockをConcurrencyパッケージで慣用的に使用する

Question

java.util.concurrencyパッケージのソースコードを参照しながら、私が以前見たことがないReentrantLockの慣用的な使用に気付きました。メンバーRentrantLock変数は、これらのメソッドは常にローカル変数参照によって参照されていました。 java.util.concurrent.ThreadPoolExecutor

private final ReentrantLock mainLock = new ReentrantLock(); 
... 
// why a local reference to final mainlock instead of directly using it? 
final ReentrantLock mainLock = this.mainLock; 
mainLock.lock(); 
try { 
...  
} finally { 
    mainLock.unlock(); 
} 

から

スタイル＃1例えばしかしながら、他の場所で最後のメンバ変数は、最初にローカル参照を取得することなく、直接使用されます。

スタイル＃2実践

でのJava並行処理から

private final Lock lock = new ReentrantLock(); 
... 
// here the final lock is used directly 
lock.lock(); 
try { 
... 
} finally { 
lock.unlock(); 
} 

私はスタイル＃1オーバースタイル＃2を使用する利点があるかを理解したいと思いますか？

おかげ

アップデート最初のパフォーマンスを識別するための応答のすべてのための

おかげで、特にベン・マネス。 は、結果として、私はコメントダグによると「cache finals across volatiles」

2003年に

1. ダグ・リーはこのイディオムを紹介し、次の追加の詳細を発見することができた、それは「for performance-critical code like that inside j.u.c.」で、そうではありません」しながら、練習をお勧めします」、と彼 『does not discourage it eitherdon't worry『

Answer 1

ベン・メインズはトンをリンク』

ブライアン・ゲッツ（JCIPの作者）も、それは、パフォーマンス・クリティカルなアプリケーションのためである場合を除きことに同意します』 o discussionは、JITの最適化について述べたコメントに含まれています。明らかに、ホットスポットコンパイラはリフレクションまたはUnsafeクラスを使用して変更できるため、finalフィールドの負荷を最適化しません。

したがって、このメカニズムは、JITがロックインスタンスの負荷を最適化できるように、速度を少し改善します。彼らはどの最適化が起こるのか詳細には触れていませんが、最適化は主記憶からインスタンスを再ロードするのを防ぐためのものです。これにより、スレッドは再入可能ロックをペナルティなしに複数回使用することができます。

残念ながら、この回答はメーリングリストの議論に基づいた推測です。誰かが私を修正することができれば先に行ってください！