Java メモリモデルの詳細な分析: 概要-＆＃＆チュートリアル-php.cn

プロセッサメモリモデル

逐次整合性メモリモデルは理論的な参照モデルであり、通常、JMM およびプロセッサメモリモデルを設計する際の参照として使用されます。 JMM およびプロセッサー・メモリー・モデルは、設計時に逐次整合性モデルにある程度の緩和を加えます。これは、プロセッサーと JMM が逐次整合性モデルに従って完全に実装されると、多くのプロセッサーおよびコンパイラーの最適化が禁止され、実行パフォーマンスに悪影響を及ぼすためです。大きな影響を与えるでしょう。

さまざまなタイプの読み取り/書き込み操作の組み合わせの実行順序の緩和に従って、一般的なプロセッサのメモリモデルは次のタイプに分類できます:
プログラム内の書き込み-読み取り操作の順序を緩和し、その結果、合計ストア順序付けメモリモデル (TSO と呼ばれる)。
前の 1 に基づいて、プログラム内の書き込み-書き込み操作の順序を緩和し続け、その結果、部分ストア順序メモリモデル (PSO と呼ばれる) が誕生しました。
前の 1 と 2 に基づいて、プログラム内の読み取り-書き込みおよび読み取り-読み取り操作の順序を緩和し続けました。その結果、緩和されたメモリ順序メモリモデル (RMO と呼ばれる) と PowerPC メモリモデルが誕生しました。

ここでのプロセッサの読み取り/書き込み操作の緩和は、2 つの操作の間にデータの依存関係がないという前提に基づいていることに注意してください (プロセッサは as-if-serial セマンティクスに準拠する必要があるため、プロセッサは 2 つのメモリ操作を実行しません)相互に依存するものは並べ替えを行います)。

以下の表は、一般的なプロセッサメモリモデルの詳細な特性を示しています:
メモリモデル名
対応するプロセッサ
ストア-ロード並べ替え
ストア-ストア並べ替え
ロード-ロードおよびロード-ストア並べ替え
変更可能他のプロセッサの書き込みを読み取りますプロセッサをより早く読み込むことができます
TSO
sparc-TSOX64
Y
Y
PSO
sparc-PSO
Y
Y
Y
RMO
ia64
Y
Y
Y

Y
PowerPC
PowerPC
Y
Y
Y
Y
Y
この表では、第 1 章で説明した理由により、すべてのプロセッサーメモリモデルで書き込み/読み取りの並べ替えが可能であることがわかります。ただし、これらはすべて書き込みバッファを使用するため、書き込み/読み取り操作が発生する可能性があります。並べ替えられます。同時に、これらのプロセッサメモリモデルでは、現在のプロセッサへの以前の読み取りまたは書き込みが許可されていることがわかります。その理由は書き込みキャッシュ領域によるものでもあります。書き込みキャッシュ領域は現在のプロセッサにのみ表示されるため、この機能により原因が生じます。現在のプロセッサは、他のプロセッサが自分の書き込みバッファに一時的に保持されている書き込みを最初に認識できるようになります。

上の表のさまざまなプロセッサメモリモデルは、上から下に向かって、強力なモデルから弱いモデルへと変化します。プロセッサがパフォーマンスを重視するほど、メモリモデルは弱くなります。これらのプロセッサは、パフォーマンスを向上させるためにできるだけ多くの最適化を実行できるように、メモリモデルによる制約を最小限に抑えることを望んでいるからです。

共通プロセッサメモリモデルは JMM よりも弱いため、バイトコードを生成する際、Java コンパイラはプロセッサの並べ替えを制限するために、実行命令シーケンスの適切な位置にメモリバリアを挿入します。同時に、さまざまなプロセッサのメモリモデルには異なる長所と短所があるため、異なるプロセッサプラットフォームのプログラマに一貫したメモリモデルを提示するために、JMM が異なるプロセッサに挿入する必要があるメモリバリアの数と種類も異なります。 . 同じではありません。次の図は、JMM が異なるプロセッサメモリモデルに挿入する必要があるメモリバリアの概略図を示しています。

Java メモリモデルの詳細な分析: 概要

上の図に示すように、JMM は異なるプロセッサメモリモデルの違いをマスクし、異なるプロセッサ上にあります。プラットフォーム Java プログラマに一貫したメモリモデルを提供します。

JMM、プロセッサメモリモデルと逐次整合性メモリモデルの関係

JMM は言語レベルのメモリモデル、プロセッサメモリモデルはハードウェアレベルのメモリモデル、逐次整合性メモリモデルは理論的な参照ですモデル。以下は、言語メモリモデル、プロセッサメモリモデル、および逐次整合性メモリモデルの長所と短所を比較した図です:

Java メモリモデルの詳細な分析: 概要上の図からわかるように、4 つの一般的なプロセッサメモリモデルは、一般的に使用される 3 つの言語メモリモデルよりも弱いです。プロセッサメモリモデルと言語メモリモデルは両方とも、逐次整合性メモリモデルよりも弱いです。プロセッサのメモリモデルと同様、言語が実行パフォーマンスを追求すればするほど、メモリモデルの設計は弱くなります。

JMM の設計

JMM 設計者の観点から見ると、JMM を設計する際には 2 つの重要な要素を考慮する必要があります。
プログラマによるメモリモデルの使用。プログラマは、理解しやすく、プログラムしやすいメモリモデルを求めています。プログラマは、強力なメモリモデルに基づいてコードを作成したいと考えています。
メモリモデルのコンパイラとプロセッサの実装。コンパイラーとプロセッサーは、パフォーマンスを向上させるためにできるだけ多くの最適化を実行できるように、メモリーモデルによる制約を最小限に抑えたいと考えています。コンパイラとプロセッサは、弱いメモリモデルを実装したいと考えています。

これら 2 つの要素は矛盾しているため、JMM を設計する際の JSR-133 専門家グループの中心的な目標は、適切なバランスポイントを見つけることです。一方では、プログラマーに十分なメモリ可視性の保証を提供する必要があります。コンパイラとプロセッサの制限は可能な限り緩和する必要があります。 JSR-133 がこの目標をどのように達成するかを見てみましょう。

具体的な説明については、前述の円の面積を計算するためのコード例を参照してください:

double pi  = 3.14;    //A
double r   = 1.0;     //B
double area = pi * r * r; //C

ログイン後にコピー

円の面積を計算するための上記のコード例には、3 つの発生前関係があります:

A happens- B の前に発生;
B が C の前に発生;
A が C の前に発生操作 A は操作 B の前に行う必要があります。ただし、プログラムセマンティクスの観点から見ると、A と B を並べ替えてもプログラムの実行結果は変わりませんが、プログラムの実行パフォーマンスも向上します (この並べ替えを許可すると、コンパイラとプロセッサの最適化の制約が軽減されます)。つまり、上記 3 つの事前発生関係のうち、2 と 3 は必要ですが、1 は不要です。したがって、JMM では、事前発生要件で禁止されている並べ替えを次の 2 つのカテゴリに分類します:
プログラムの実行結果を変更する並べ替え。
順序を変更してもプログラムの実行結果は変わりません。

JMM は、これら 2 つの異なる性質の並べ替えに対して、異なる戦略を採用します。
プログラムの実行結果を変更する並べ替えの場合、JMM は、コンパイラーとプロセッサに対して、そのような並べ替えを禁止することを要求します。
JMM は、プログラムの実行結果を変更しない並べ替えについてコンパイラーとプロセッサーに要件を課しません (JMM はそのような並べ替えを許可します)。

以下は JMM の設計図です:

上の図から 2 つの点がわかります: Java メモリモデルの詳細な分析: 概要 JMM によってプログラマーに提供される前発生ルールは、プログラマーのニーズを満たすことができます。 JMM の事前発生ルールはシンプルで理解しやすいだけでなく、プログラマーに十分強力なメモリ可視性の保証を提供します (上記の A 事前発生 B など、一部のメモリ可視性保証は必ずしも実際に存在するとは限りません)。

JMM では、コンパイラーとプロセッサーに対する制約ができるだけ少なくなります。上記の分析から、JMM は実際に基本原則に従っていることがわかります。つまり、プログラムの実行結果が変更されない限り (シングルスレッドプログラムと正しく同期されたマルチスレッドプログラムを指します)、コンパイラーとプロセッサーは、どのように使用されても最適化されます。たとえば、コンパイラーが注意深く分析した結果、ロックが単一のスレッドによってのみアクセスされると判断された場合、そのロックは削除できます。別の例として、コンパイラーが慎重な分析の結果、volatile 変数が単一のスレッドによってのみアクセスされると判断した場合、コンパイラーは volatile 変数を通常の変数として扱うことができます。これらの最適化によってプログラムの実行結果は変わりませんが、プログラムの実行効率も向上します。

JMM のメモリ可視性保証

Java プログラムのメモリ可視性保証は、プログラムの種類に応じて次の 3 つのカテゴリに分類できます。
シングルスレッドプログラム。シングルスレッドプログラムにはメモリの可視性の問題はありません。コンパイラー、ランタイム、プロセッサーは連携して、シングルスレッドプログラムの実行結果が逐次整合性モデルでのプログラムの実行結果と同じになるようにします。
適切に同期されたマルチスレッドプログラム。適切に同期されたマルチスレッドプログラムの実行には、逐次一貫性が保たれます (プログラムの実行結果は、プログラムが逐次一貫性のあるメモリモデルで実行された場合と同じになります)。これが JMM の焦点であり、コンパイラとプロセッサの並べ替えを制限することでプログラマにメモリの可視性を保証します。
非同期/誤って同期されたマルチスレッドプログラム。 JMM はそれらに最小限の安全保証を提供します。スレッドの実行時に読み取られる値は、前のスレッドによって書き込まれた値、またはデフォルト値 (0、null、false) のいずれかです。

次の図は、JMM および逐次一貫性メモリモデルにおけるこれら 3 種類のプログラムの実行結果の類似点と相違点を示しています。

マルチスレッドプログラムが正しく同期されている限り、JMM は、任意のプロセッサプラットフォームでのプログラムの実行結果が、逐次一貫性のあるメモリモデルでのプログラムの実行結果と一致することを保証します。

JSR-133 による古いメモリモデルの修正

JSR-133 は、主に次の 2 つの方法で JDK5 より前の古いメモリモデルを修正します。
揮発性メモリセマンティクスを強化します。古いメモリモデルでは、揮発性変数を通常の変数と並べ替えることができました。 JSR-133 は、揮発性の書き込みと読み取りとロックの解放と取得が同じメモリセマンティクスを持つように、揮発性変数と通常の変数の並べ替えを厳しく制限します。
final のメモリセマンティクスを強化します。古いメモリモデルでは、同じ最終変数の値が複数回読み取られると異なる場合があります。この目的を達成するために、JSR-133 では、final に 2 つの並べ替えルールを追加します。現在、final には初期化の安全性があります。

上記は Java メモリモデルの詳細な分析: 概要です。その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) に注目してください。