native-memory-tracking-in-jvm

*ロードされたクラスに関するメタデータを維持するために、JVMは_Metaspace_ *と呼ばれる専用の非ヒープ領域を使用します。 Java 8より前は、同等のものは_PermGen_または_Permanent Generation_と呼ばれていました。 MetaspaceまたはPermGenには、ヒープ内に保持されるインスタンスではなく、ロードされたクラスに関するメタデータが含まれます。

ここで重要なことは、メタスペースはオフヒープデータ領域であるため、*ヒープサイズ設定がメタスペースサイズに影響しないことです。 メタスペースのサイズを制限するために、他のチューニングフラグを使用します。

JVMで最もメモリを消費するデータ領域の1つは、各スレッドと同時に作成されるスタックです。 スタックはローカル変数と部分的な結果を保存し、メソッド呼び出しで重要な役割を果たします。

デフォルトのスレッドスタックサイズはプラットフォームに依存しますが、最新の64ビットオペレーティングシステムでは、約1 MBです。 このサイズは、__- Xss __tuning flagを使用して構成できます。

対照的に、他のデータ領域とは異なり、*スレッドの数に制限がない場合、スタックに割り当てられるメモリの合計は実質的に無制限です* -in-timeコンパイル。

異なるプラットフォームでJVMバイトコードを実行するには、マシン命令に変換する必要があります。 JITコンパイラーは、プログラムの実行時にこのコンパイルを行います。

JVMにはいくつかのGCアルゴリズムが同梱されており、それぞれが異なるユースケースに適しています。 これらのすべてのGCアルゴリズムは、1つの共通の特徴を共有しています。タスクを実行するには、いくつかのオフヒープデータ構造を使用する必要があります。 これらの内部データ構造は、より多くのネイティブメモリを消費します。

アプリケーションコードとライブラリコードで最もよく使用されるデータ型の1つである__Stringsから始めましょう。 ユビキタスであるため、通常はヒープの大部分を占めます。 これらの文字列の多くに同じコンテンツが含まれている場合、ヒープのかなりの部分が無駄になります。

ヒープ領域を節約するために、各__String __の1つのバージョンを保存し、保存されたバージョンを他の人に参照させることができます。 **このプロセスは_String Interningと呼ばれます。

JVMは、かなりの数のネイティブ割り当ての通常の容疑者ですが、開発者がネイティブメモリを直接割り当てることもできます。 最も一般的なアプローチは、JNIおよびNIOのdirect _ByteBuffers._による__malloc __callです。

このセクションでは、さまざまな最適化シナリオのために、いくつかのJVMチューニングフラグを使用しました。 次のヒントを使用すると、特定の概念に関連するほぼすべてのチューニングフラグを見つけることができます。

_PrintFlagsFinal_は、JVMのすべての-__ XX ___optionsを出力します。 たとえば、すべてのメタスペース関連フラグを検索するには：

NMTが有効になっている場合、__jcmd __commandを使用して、いつでもネイティブメモリ情報を取得できます。

JVMアプリケーションのPIDを見つけるには、__jps __コマンドを使用できます。

適切な_pid_とともにwith__jcmd __を使用すると、__VM.native_memory __はJVMにネイティブ割り当てに関する情報を出力させます。

NMT出力をセクションごとに分析してみましょう。

NMTは、予約済みメモリとコミット済みメモリの合計を次のように報告します。

*予約済みメモリは、アプリが潜在的に使用できるメモリの総量を表します。 逆に、コミットされたメモリは、アプリが現在使用しているメモリ量に等しくなります。*

300 MBのヒープを割り当てていますが、アプリの合計予約メモリは約1.7 GBであり、それ以上です。 同様に、コミットされたメモリは約440 MBで、これも300 MBをはるかに超えています。

合計セクションの後、NMTは割り当てソースごとのメモリ割り当てを報告します。 それでは、各ソースを詳しく調べてみましょう。

NMTは、予想どおりにヒープ割り当てを報告します。

ヒープサイズの設定に一致する300 MBの予約済みメモリとコミット済みメモリ。

NMTがロードされたクラスのクラスメタデータについて言うことは次のとおりです。

ほぼ1 GBが予約され、45 MBが6566クラスのロードにコミットされています。

スレッドの割り当てに関するNMTレポートは次のとおりです。

合計で、37 MBのスタックに36 MBのメモリが割り当てられます。スタックあたり約1 MBです。 JVMは作成時にメモリをスレッドに割り当てるため、予約済みとコミット済みの割り当ては等しくなります。

JITによって生成およびキャッシュされたアセンブリ命令についてNMTが言っていることを見てみましょう。

現在、約13 MBのコードがキャッシュされており、この量は約245 MBに達する可能性があります。

G1 GCのメモリ使用量に関するNMTレポートは次のとおりです。

ご覧のとおり、約60 MBが予約されており、G1の支援に専念しています。

メモリ使用量がどのように見えるかを見てみましょう。はるかに単純なGC、たとえばSerial GCの場合：

シリアルGCは1 MBをほとんど使用しません。

明らかに、メモリ使用量のためだけにGCアルゴリズムを選択するべきではありません。SerialGCの世界を停止する性質により、パフォーマンスが低下する可能性があるからです。 ただし、https：//www.baeldung.com/jvm-garbage-collectors [から選択する複数のGC]があり、それぞれがメモリとパフォーマンスのバランスが異なります。

文字列テーブルや定数プールなどのシンボル割り当てに関するNMTレポートは次のとおりです。

シンボルにはほぼ10 MBが割り当てられます。

その後、しばらくして、現在のメモリ使用量とそのベースラインを比較できます。

NMTは、記号と–記号を使用して、その期間にメモリ使用量がどのように変化したかを示します。

予約メモリとコミットメモリの合計は、それぞれ3 MBと6 MB増加しました。 メモリ割り当ての他の変動も簡単に発見できます。

NMTは、メモリ空間全体のマップに関する非常に詳細な情報を提供できます。 この詳細レポートを有効にするには、__- XX：NativeMemoryTracking = detail __tuningフラグを使用する必要があります。