JVMメモリを監視しないキャリアは不完全です

[[393678]]

この記事はWeChatの公開アカウント「New Vision of Programming」から転載したもので、著者はUgly Fat Man Second Brotherです。記事の転載については、Program New Visionの公式アカウントまでご連絡ください。

序文

長年 Java 開発に携わってきたものの、JVM 分析ツールを使用したことがなく、JVM ダンプログを通じて障害の特定やパフォーマンスの最適化を試みたことがないのであれば、これはキャリアにおける大きな後悔であり、能力不足であると言えます。

この記事は、JDK に付属するツール (VisualVM) に基づいており、メモリオーバーフローのケースを記述して、JVM 分析を開始する方法を示します。この記事には複数の知識ポイントの統合と実践的な経験の共有が含まれており、読者は注目することができます。

VisualVM の紹介

VisualVM は、JDK6.0 アップデート 7 に付属する Netbeans のプロファイルサブプロジェクトです。スレッド、メモリの状態を監視し、メソッドの CPU 時間やメモリ内のオブジェクト、GC されたオブジェクトを表示し、割り当てられたスタックを逆に表示できます (たとえば、どのオブジェクトがそれぞれ 100 個の String オブジェクトを割り当てたか)。

クラスパスが正しく設定されていれば、VisualVM の起動は非常に簡単です。コマンドラインに jvisualvm と入力するだけで、グラフィカルインターフェイスが起動します。 VisualVM はローカル監視だけでなく、リモート監視もサポートします。

リモート監視の構成は少し複雑なので、ローカル監視を例としてデモンストレーションを行います。実稼働環境では、リモート監視を選択することも、jmap を使用してダンプファイルを生成し、そのダンプファイルをダウンロードして分析することもできます。

VisualVM 関数インターフェイス

VisualVM を起動したら、JVM 分析に役立ついくつかの機能を見てみましょう。ここでは、地元で始まったアイデアを例として取り上げて説明します。

概要

VisualVM に入った後、左側の対応するプロセスをクリックすると、最初に表示されるのは [概要] の内容です。

概要には、JVM、Java バージョン、ダンプバッチなどの情報が表示されます。実際の戦闘では、この情報を使用して情報を検証できます。特に、JVM パラメータとシステムプロパティを確認してください。

かつて、Java プログラムの起動時に JVM パラメータの場所が誤って記述され、JVM パラメータが有効にならないというシナリオに遭遇しました。

例えば、以下の手順では、JVM パラメータが最後に記述されているため、パラメータ設定は無効になります。

 java -jar app.jar -Xms256m -Xmx512m

正しい書き方は次のとおりです。

 java -Xms256m -Xmx512m -jar app.jar

上記の場合、ツールは JVM パラメータ項目に指定されたパラメータ値がないことを簡単に表示できます。

監視

監視インターフェースは、より一般的に使用されるインターフェースです。このインターフェースを通じて、CPU 使用率、ヒープおよびメタスペースの使用率、スレッドの使用率、クラスの読み込みステータスなどを表示できます。

ヒープとメタスペースの使用状況を分析することで、対応するメモリ空間の使用状況と増加を確認し、適切な調整と計画を立てることができます。

右上隅の「ヒープダンプ」をクリックすると、クリックした時間ノードに基づいてダンプファイルが生成されます。

概要セクションには、生成されたダンプファイルのタイムノードとストレージパスが表示されます。メモリを分析するために主に使用するものは、このページの「クラス」メニューにあります。

ヒープ内のさまざまなインスタンスによって占有されているメモリサイズを表示するには、入力します。クラス名をダブルクリックすると、特定のクラスのインスタンスの詳細である「インスタンス数」が表示されます。

メモリ分析において私たちにとって最も重要なのは、実は「クラス」の数です。上記の基本的な操作を理解した後、例を使用してメモリオーバーフローのシナリオをシミュレートして分析してみましょう。

メモリオーバーフローシナリオ構築

まず、メモリオーバーフローをシミュレートするコードを記述します。つまり、マップを作成し、それにオブジェクトを継続的に追加します。同時に、プログラム処理中にスレッドをスリープまたはデッドループにして、VisualVM での表示を容易にします。

テストコードは次のとおりです。

パブリッククラス MemoryLeakTest { 
 
    /**
     * キャッシュオブジェクトを宣言する
     */
    プライベート静的最終 Map<String, TestMemory> CACHE_MAP = new HashMap<>(); 
 
公共 静的void main(String[] args) {
        試す {
            //visualVm を開く時間を与える
            スレッドをスリープ状態にします(10000);
        } キャッチ (InterruptedException e) {
            e.printStackTrace();
        }
        // キャッシュにオブジェクトを追加するためのループ
( int i = 0; i < 1000000; i++) {
            テストメモリ t = 新しいテストメモリ();
            CACHE_MAP.put( "キー" + i, t);
        }
        システム。出力.println( "-------1------" );
        // ヒープをダンプするための時間を提供する
        試す {
            //visualVm を開く時間を与える
            スレッドをスリープ状態にします(10000);
        } キャッチ (InterruptedException e) {
            e.printStackTrace();
        } 
 
 ( int i=0; i<1000000; i++) {
            テストメモリ t = 新しいテストメモリ();
            CACHE_MAP.put( "キー" +i,t);
        }
    }
 }

TestMemory クラスは、生成されるビジネスクラスを表します。

パブリッククラスTestMemory {
 }

プログラムがより早くメモリしきい値に到達できるように、起動時に JVM のサイズを制限することができます。ここでは次のように設定されています:

 -Xms128m -Xmx128m

また、ヒープのメモリ構造における各領域（新世代、旧世代）のメモリ使用量を分析するために、VisualVM の「ツール」および「プラグイン」にある Visual GC プラグインをインストールすることができます。このプラグインを使用した効果は後で確認できます。

準備は整いました。確認してみましょう。

メモリオーバーフロー解析

次に、プログラムを起動し、VisualVM を起動してメモリオーバーフローを分析します。

プログラムを実行すると、「ヒープ」メモリが急速に増加する曲線を示すことがわかります。

Metaspace もこの過程で成長しています。

Visual GC インターフェイスを開くと、インタビューで何度も尋ねられたヒープメモリ構造が表示されます。

この図から、ヒープメモリ内の旧世代、新世代、Metaspace 空間 (JDK8) のほか、新世代内の Eden、S0 (Survivor From)、S1 (Survivor To) が直感的にわかり、その割り当て比率もより直感的に表示されます。この方法では、ヒープメモリ構造をより直感的に学習できるでしょうか?

ここで、Eden はいっぱい、S0 と S1 は空、古い世代はほぼいっぱいです (ガベージコレクションでは参照を保持しているオブジェクトをクリアできないため)。

最も重要なことは、20 分間に古い世代で 3850 回のガベージコレクションが実行されたことです。つまり、Full GC 操作が頻繁にトリガーされ、メモリが解放されていません。実稼働システムで、システムが Full GC 操作を頻繁に実行しているのがわかる場合、それは JVM が非常に危険な信号を送信していることを意味します。

上記では表面的な部分について説明しましたが、ここからは実際にメモリ分析を始めます。上記の「モニター」、「ヒープダンプ」、「クラス」に戻ると、次の図が表示されます。

ご覧のとおり、ヒープには 100 万個の TestMemory オブジェクトがあります。ヒープ内にこのようなオブジェクトが多数ある場合は、メモリリークが発生している可能性があることに注意する必要があります。つまり、大量のオブジェクトが作成されますが、「スムーズに」リサイクルされるわけではありません。ここでリサイクルされない理由は、オブジェクトが静的変数に配置されているためです。

前述のように、オブジェクト名をダブルクリックすると、オブジェクトの詳細情報を表示できます。

上記の手順により、基本的にどのオブジェクトに処理上の問題があるかを特定できます。この時点で、コードに戻って対応するコードをチェックし、メモリオーバーフローの問題をすばやく見つけることができます。その中でも、上記のプロセスで VisualVM によって提供されるアラーム信号とデータの表示には特に注意を払う必要があります。