CodeGym/Java Course/モジュール 3/JVM のメモリ、パート 2

JVM のメモリ、パート 2

使用可能

メモリハードウェアアーキテクチャ

最新のメモリハードウェアアーキテクチャは、Java の内部メモリモデルとは異なります。したがって、Java モデルがハードウェアアーキテクチャでどのように動作するかを知るためには、ハードウェアアーキテクチャを理解する必要があります。このセクションでは一般的なメモリハードウェアアーキテクチャについて説明し、次のセクションでは Java がメモリハードウェアアーキテクチャでどのように動作するかを説明します。

以下は、最新のコンピューターのハードウェアアーキテクチャの簡略図です。

現代の世界では、コンピューターには 2 つ以上のプロセッサーが搭載されており、これはすでに標準となっています。これらのプロセッサーの中には、複数のコアを備えているものもあります。このようなコンピュータでは、複数のスレッドを同時に実行できます。各プロセッサコアは、常に 1 つのスレッドを実行できます。これは、Java アプリケーションは事前にマルチスレッド化されており、プログラム内ではプロセッサコアごとに 1 つのスレッドを同時に実行できることを意味します。

プロセッサコアには、メモリ (コア内部) に常駐する一連のレジスタが含まれています。レジスタデータに対する操作は、コンピュータのメインメモリ (RAM) にあるデータに対する操作よりもはるかに高速に実行されます。これは、プロセッサがこれらのレジスタに非常に高速にアクセスできるためです。

各 CPU は独自のキャッシュ層を持つこともできます。最新のプロセッサにはこれが搭載されています。プロセッサは、メインメモリよりもはるかに高速にキャッシュにアクセスできますが、内部レジスタほど高速ではありません。キャッシュのアクセス速度は、メインメモリと内部レジスタのアクセス速度のほぼ中間の値になります。

さらに、プロセッサにはマルチレベルキャッシュを搭載する場所があります。ただし、Java メモリモデルがハードウェアメモリとどのように対話するかを理解するために、これを知ることはそれほど重要ではありません。プロセッサにはある程度のレベルのキャッシュがある可能性があることを知っておくことが重要です。

どのコンピュータにも同様にRAM（主記憶領域）が搭載されています。すべてのコアがメインメモリにアクセスできます。メインメモリ領域は通常、プロセッサコアのキャッシュメモリよりもはるかに大きくなります。

プロセッサは、メインメモリにアクセスする必要があるときに、その一部をキャッシュメモリに読み取ります。また、キャッシュから一部のデータを内部レジスタに読み取り、それらのレジスタに対して操作を実行することもできます。CPU が結果をメインメモリに書き戻す必要がある場合、データを内部レジスタからキャッシュにフラッシュし、ある時点でメインメモリにフラッシュします。

キャッシュに格納されたデータは、通常、プロセッサがキャッシュに何か別のものを格納する必要がある場合、メインメモリにフラッシュバックされます。キャッシュには、メモリのクリアとデータの書き込みを同時に行う機能があります。プロセッサは、更新中に毎回完全なキャッシュを読み書きする必要はありません。通常、キャッシュはメモリの小さなブロックで更新され、それらは「キャッシュライン」と呼ばれます。1つまたは複数の「キャッシュライン」をキャッシュメモリに読み込むことができ、1つまたは複数のキャッシュラインをメインメモリにフラッシュバックすることができます。

Java メモリモデルとメモリハードウェアアーキテクチャの組み合わせ

すでに述べたように、Java メモリモデルとメモリハードウェアアーキテクチャは異なります。ハードウェアアーキテクチャでは、スレッドスタックとヒープが区別されません。ハードウェアでは、スレッドスタックと HEAP (ヒープ) はメインメモリに存在します。

スタックやスレッドヒープの一部が、CPU のキャッシュや内部レジスタに存在する場合があります。これを図に示します。

オブジェクトと変数がコンピュータのメモリの異なる領域に格納される場合、特定の問題が発生する可能性があります。主なものは次の 2 つです。

スレッドが共有変数に加えた変更の可視性。
共有変数の読み取り、チェック、書き込み時の競合状態。

これらの両方の問題については、以下で説明します。

共有オブジェクトの可視性

volatile 宣言や同期を適切に使用せずに 2 つ以上のスレッドがオブジェクトを共有する場合、1 つのスレッドによって行われた共有オブジェクトへの変更は他のスレッドには表示されない可能性があります。

共有オブジェクトが最初はメインメモリに格納されていると想像してください。CPU 上で実行されているスレッドは、共有オブジェクトを同じ CPU のキャッシュに読み取ります。そこで彼はオブジェクトに変更を加えます。CPU のキャッシュがメインメモリにフラッシュされるまで、共有オブジェクトの変更されたバージョンは、他の CPU で実行されているスレッドには表示されません。したがって、各スレッドは共有オブジェクトの独自のコピーを取得でき、各コピーは個別の CPU キャッシュに存在します。

次の図は、この状況の概要を示しています。左側の CPU で実行されている 1 つのスレッドは、共有オブジェクトをそのキャッシュにコピーし、count の値を 2 に変更します。 count の更新がまだメインメモリにフラッシュされていないため、この変更は右側の CPU で実行されている他のスレッドには見えません。

この問題を解決するには、変数を宣言するときに volatile キーワードを使用します。これにより、指定された変数がメインメモリから直接読み取られ、更新時に常にメインメモリに書き戻されることが保証されます。

競合状態

2 つ以上のスレッドが同じオブジェクトを共有し、複数のスレッドがその共有オブジェクト内の変数を更新すると、競合状態が発生する可能性があります。

スレッド A が共有オブジェクトのカウント変数をプロセッサのキャッシュに読み取ると想像してください。また、スレッド B が同じことを別のプロセッサのキャッシュで実行すると想像してください。ここで、スレッド A は count の値に 1 を加え、スレッド B も同じことを行います。これで、変数は 2 回増加しました (各プロセッサのキャッシュ内で個別に +1 ずつ)。

これらの増分が連続して実行されると、count 変数は 2 倍になり、メインメモリに書き戻されます (元の値 + 2)。

ただし、適切な同期が行われずに 2 つの増分が同時に実行されました。どちらのスレッド (A または B) がその更新バージョンの count をメインメモリに書き込むかに関係なく、2 つの増分にもかかわらず、新しい値は元の値より 1 増えるだけです。

この図は、上で説明した競合状態の問題の発生を示しています。