フラグを使用したバイアスロックが、-XX:+UseBiasedLocking
競合のない同期のパフォーマンスをどのように改善できるかについて読み続けています。それが何をするのか、そしてそれがどのようにパフォーマンスを改善するのかについての参照を見つけることができませんでした。
誰かが私にそれが正確に何であるかを説明できますか、または説明するいくつかのリンク/リソースを私に指摘することができますか?
フラグを使用したバイアスロックが、-XX:+UseBiasedLocking
競合のない同期のパフォーマンスをどのように改善できるかについて読み続けています。それが何をするのか、そしてそれがどのようにパフォーマンスを改善するのかについての参照を見つけることができませんでした。
誰かが私にそれが正確に何であるかを説明できますか、または説明するいくつかのリンク/リソースを私に指摘することができますか?
基本的に、オブジェクトが1つのスレッドによってのみロックされている場合、JVMは最適化を行い、オブジェクトに対する後続のアトミック操作で同期コストが発生しないように、そのオブジェクトをそのスレッドに「バイアス」できます。これは通常、オブジェクトを別のスレッドに公開することなくオブジェクトをロックする、過度に保守的なコードを対象としていると思います。実際の同期オーバーヘッドは、別のスレッドがオブジェクトのロックを取得しようとしたときにのみ開始されます。
Java6ではデフォルトでオンになっています。
-XX:+UseBiasedLocking競合のない同期のパフォーマンスを向上させる手法を有効にします。オブジェクトは、monitorenterバイトコードまたは同期メソッド呼び出しを介して最初にモニターを取得するスレッドに「バイアス」されます。そのスレッドによって実行される後続のモニター関連の操作は、マルチプロセッサー・マシンでは比較的高速です。競合のない同期が大量にある一部のアプリケーションでは、このフラグを有効にすると大幅な高速化が達成される場合があります。悪影響を最小限に抑えるための試みがなされていますが、特定のロックパターンを持つ一部のアプリケーションでは速度が低下する場合があります。
これはあなたの質問に答えませんか?
http://www.oracle.com/technetwork/java/tuning-139912.html#section4.2.5
競合のない同期のパフォーマンスを向上させるための手法を有効にします。オブジェクトは、monitorenterバイトコードまたは同期メソッド呼び出しを介して最初にモニターを取得するスレッドに「バイアス」されます。そのスレッドによって実行される後続のモニター関連の操作は、マルチプロセッサー・マシンでは比較的高速です。競合のない同期が大量にある一部のアプリケーションでは、このフラグを有効にすると大幅な高速化が達成される場合があります。悪影響を最小限に抑えるための試みがなされていますが、特定のロックパターンを持つ一部のアプリケーションでは速度が低下する場合があります。
1.6ではデフォルトでオンになっていると思いますが。PrintFlagsFinal診断オプションを使用して、有効なフラグを確認します。サーバーアプリケーションを調査する場合は、フラグが異なる可能性があるため、必ず-serverを指定してください。
私は自分自身に偏ったロックについて疑問に思っていました。
ただし、Javaのバイアスロックは、Intelのnehalemプロセッサでは通常のロックよりも遅く、おそらくnehalem以降の2世代のプロセッサでは遅いようです。http://mechanical-sympathy.blogspot.com/2011/11/java-lock-implementations.html およびここhttp://www.azulsystems.com/blog/cliff/2011-11-16-a-short-を参照してください。偏ったロックでの会話
また、ここで詳細情報https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot
Intelの偏ったロックを取り消すための比較的安価な方法があることを望んでいましたが、それは不可能だと私は信じ始めています。それがどのように行われるかについて私が見た記事は、次のいずれかに依存しています。
バイアスされたロックはデフォルトでjdk15以降無効になることは言及する価値があります
過去に見られたパフォーマンスの向上は、今日ではそれほど明白ではありません。バイアスロックの恩恵を受けた多くのアプリケーションは、すべてのアクセスで同期する初期のJavaコレクションAPI(HashtableやVectorなど)を使用する古いレガシーアプリケーションです。新しいアプリケーションは通常、シングルスレッドシナリオの場合はJava 1.2で導入された非同期コレクション(HashMapやArrayListなど)を使用し、マルチスレッドシナリオの場合はJava5で導入されたさらにパフォーマンスの高い同時データ構造を使用します。
さらに遠く
バイアスロックは、同期サブシステムに多くの複雑なコードを導入し、他のHotSpotコンポーネントにも侵入します。この複雑さは、コードのさまざまな部分を理解する上での障壁であり、同期サブシステム内で重要な設計変更を行う上での障害となります。そのために、バイアスロックのサポートを無効にし、非推奨にし、最終的には削除したいと思います。
そして、もうSystem.identityHashCode(o)
魔法はありません;)
ここに2つの論文:
https://www.oracle.com/technetwork/java/biasedlocking-oopsla2006-wp-149958.pdf
Webページも: https ://blogs.oracle.com/dave/biased-locking-in-hotspot
jvmホットスポットのソースコード:
http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/oops/markOop.hpp