JVM: 自分がどうやって死んだのか知りたいだけ

[[347298]]

Java プログラムが JVM 上で実行されることは誰もが知っています。 JVM に何らかの障害が発生すると、サービスの安定性が必然的に影響を受けます。運が良ければ、サービスが不安定になり、一部のリクエストが遅延したり異常になったりする可能性があります。運が悪いと、JVM が直接クラッシュし、サービスが完全に中断されることになります。

これは良いことではありません。 JVM とともに、サービスだけでなく私たちの精神も崩壊するでしょう。

いわゆる JVM クラッシュは、一般的にメモリオーバーフロー、つまり OutOfMemoryError と StackOverflowError を指します。もう 1 つの状況は、オフヒープメモリの使用量が非常に大きい場合です。これにより、JVM が配置されているマシンのメモリが膨張し、マシンの再起動などの異常な状況が発生します。この状況をメモリリークと呼びます。

では、どのような状況で JVM がクラッシュするのでしょうか?クラッシュにはどのような種類がありますか?諺にあるように、自分と敵を知ることによってのみ、百戦錬磨の勝者となることができるのです。クラッシュの原因を理解することによってのみ、JVM クラッシュの問題をより適切に解決できます。

まず、JVM メモリモデル図を示します。 JVM は理解するのが非常に抽象的です。次の図は、JVM メモリモデルを具体的に理解するのに役立ち、オーバーフローが発生する部分も図で確認できます。 JDK 8 では、永続世代は存在しなくなり、メタスペースに置き換えられました。

次に、Hotspot JDK 8 を背景として、JVM メモリオーバーフローとメモリリークのいくつかのケースを見ていきます。

まず、ヒープ領域のサイズを制限するために JVM 起動パラメータを設定します。ヒープ領域は、新世代用に 10M、メタスペース用に 10M を含む 20M に設定され、ガベージコレクションアルゴリズムとして CMS アルゴリズムを使用するように指定します。以降のすべての例では、このパラメータセットを使用します。

 -XX:+ConcMarkSweepGC を使用する
-XX:+CMS 占有開始のみを使用する
-XX:CMS開始占有率=70
 -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
 -XX:+CMSクラスのアンロードが有効
-XX:+並列参照プロセス有効
-XX:+CMSScavengeBeforeRemark
 -詳細:gc
 -Xms20M
 -Xmx20M
 -Xmn10M
 -XX:+GC詳細を印刷
-XX:生存率=8
 -XX:+メモリ不足エラー時のヒープダンプ
-XX:メタスペースサイズ=10M
 -XX:最大メタスペースサイズ=10M
 -XX:HeapDumpPath=/Users/fengzheng/jvmlog

ヒープオーバーフロー

ヒープオーバーフローは、おそらく最も一般的なメモリオーバーフローのシナリオです。 JVM に割り当てられたほとんどのオブジェクトインスタンスと配列はヒープ上に格納されます。さらに、ヒープメモリはガベージコレクターの主戦場でもあります。

Java プログラムが起動すると、ヒープ領域のサイズが指定されます。新しいオブジェクトと配列が作成されると、それらはヒープ上に割り当てられます。新しいオブジェクトがスペースを要求したときに、ヒープメモリが不足している場合は、ガベージコレクションが発生します。ほとんどの場合、これはマイナー GC と呼ばれる新しい世代で発生します。新しい世代が収集されてもまだ十分なスペースがない場合は、FullGC が発生します。 FullGC後も領域が不足している場合は、OOMエラー（ヒープオーバーフロー）が発生します。

このシナリオをシミュレートする

プライベートファイナルスタティック 整数_1K = 1024; 
 
公共 静的void main(String[] args){
  リスト<byte[]> byteList = 新しいArrayList<>();
  静かにクラッシュヒープを待機します(byteList);
 } 
 
公共 静的void quietlyWaitingForCrashHeap(List<byte[]> byteList) {
  試す {
    （真）の間{
      byteList.add (新しいバイト[500 * _1K]);
      //スレッドスリープ(1000);
      スレッド.sleep(100);
    }
  } キャッチ (InterruptedException e) { 
 
  }
 }

上記の方法は、

以下はプログラムを実行した後の結果です。ガベージコレクション後も余分なスペースがないため、java.lang.OutOfMemoryError: Java ヒープスペース例外が発生します。

画像-20201016211017630

ヒープメモリオーバーフローの根本的な原因は、使用中のオブジェクトのサイズがヒープメモリサイズを超えていることです。

ヒープメモリスペースの設定が小さすぎます。推定される実際のヒープサイズに基づいて、ヒープ領域を適切に設定する必要があります。

プログラムの脆弱性により、一部の静的変数が増大し続けます。たとえば、キャッシュデータの初期化が不適切だと、キャッシュが際限なく大きくなり、最終的にはヒープメモリのオーバーフローが発生します。この状況には、適切なテストを実施し、問題が発生した後に適切なログ分析を行う以外に、おそらく適切な解決策はありません。

スタックオーバーフロー

仮想マシンスタックは、ローカル変数テーブル、オペランドスタック、動的リンク、メソッド終了などの情報を格納するために使用されます。Java メソッドが呼び出されるたびに、仮想マシンスタック内にこのメソッドのスタックフレームが生成されます。

スタックには、仮想マシンスタックに加えて、ネイティブメソッドスタックも含まれます。呼び出されたメソッドがネイティブメソッド (C 言語で実装されたメソッドなど) の場合、ネイティブメソッドスタックが使用されます。ただし、HotSpot 仮想マシンでは、仮想マシンスタックとローカルメソッドスタックが 1 つに結合されます。

スタックオーバーフローのシナリオをシミュレートする

公共 静的void main(String[] args){
  スタックオーバーフロー();
 } 
 
 /**
 * スタックオーバーフロー
*/
公共 静的voidスタックオーバーフロー() {
  スタックオーバーフロー();
 }

上記のコードでは、stackOverflow() メソッドの呼び出しは、再帰終了のない無限再帰プロセスです。前述したように、メソッドが呼び出されるたびに、仮想マシンスタックにスタックフレームが生成されます。無限再帰は必然的にスタックフレームの無限生成を引き起こし、最終的にはスタック領域がいっぱいになり、オーバーフローが発生します。

画像-20201019122447325

上記は最も一般的な状況をシミュレートしたものです。この状況の原因はおそらくプログラムのバグによるものです。一般的に言えば、再帰には再帰的な終了が必要です。何らかの理由でプログラムが実行中に終了条件に到達できない場合、この例外が発生します。ループ本体もございます。ループ本体の反復回数が多すぎると、スタックオーバーフローが発生する可能性があります。

スレッドが多すぎるなど、可能性の低い他の理由もあるかもしれません。スレッドを作成するには、仮想マシンスタックにスペースを割り当てる必要があります。作成されるスレッドが多すぎると、OutOfMemoryError 例外が発生する可能性があります。ただし、一般的には手動でスレッドを作成するのではなく、スレッドプール方式を使用するため、このような状況が発生する可能性は低くなります。

メタスペースオーバーフローは、クラス情報、定数、静的変数、ジャストインタイム (JIT) コンパイルコード、および仮想マシンによってロードされたその他のデータを格納するために使用されます。 JDK 8 では、permanent 世代の代わりに metaSpace が使用されています。デフォルトでは、metaSpace のサイズは無制限、つまりサーバーの実際のメモリサイズになります。ただし、一般的には、メタスペースのサイズを設定するのが最適です。

一般的に、動的に生成されるクラスが大量に生成されると、メタスペースのメモリオーバーフローが発生する可能性があります。

メタスペースオーバーフローのシミュレーション

公共 静的void main(String[] args){
  リスト<byte[]> byteList = 新しいArrayList<>();
  //静かにCrashHeapを待機します(byteList);
  // スタックオーバーフロー();
  メソッドAreaOverflow();
 } 
 
公共 静的voidメソッドAreaOverflow() {
整数i = 0;
  （真）の間{
    エンハンサー enhancer = new Enhancer();
    エンハンサー.setUseCache( false );
    エンハンサー.setSuperclass(MethodOverflow.class);
    エンハンサー.setCallback(新しいMethodInterceptor() {
      @オーバーライド
パブリックオブジェクトインターセプト(オブジェクトo、メソッドメソッド、オブジェクト[]オブジェクト、メソッドプロキシメソッドプロキシ)はThrowableをスローします{
メソッドProxy.invokeSuper(o, objects)を返します。
      }
    });
    エンハンサーを作成します();
    System.out.println (++i) ;
  }
 }

CGLIB を通じて多くの動的クラスを動的に作成すると、メタスペースに格納されるクラス情報が増え、メタスペースオーバーフローが発生します。

画像-20201019163227576

たとえば、Spring や MyBatis などの技術フレームワークを使用する場合、Bean インスタンスクラスが動的に作成されます。さらに、Spring AOP は動的プロキシクラスも生成します。

オフヒープメモリオーバーフロー

ほとんどの場合、メモリは JVM ヒープメモリ内に割り当てられますが、まれにヒープ外部に直接メモリ領域を割り当てる必要がある場合もあります。オフヒープメモリを使用することによる利点はいくつかあります。

プロセス間で共有できるため、仮想マシン間のコピーが削減されます。
ガベージコレクションの一時停止の改善: アプリケーションに、YGC または FullGC を頻繁にトリガーする長期間存続する大規模なオブジェクトがある場合は、これらのオブジェクトをヒープ外に配置することを検討できます。ヒープが大きすぎると、Java アプリケーションのパフォーマンスに影響します。オフヒープメモリが使用される場合、それは仮想マシンではなくオペレーティングシステムによって直接管理されます。その結果、ヒープメモリを小さく保つことができ、ガベージコレクションがアプリケーションに与える影響を軽減できます。
シナリオによっては、プログラムの I/O 操作のパフォーマンスが向上する場合があります。オンヒープメモリからオフヒープメモリにデータをコピーする手順は省略されます。

通常、オフヒープメモリは、大量の頻繁な IO 操作が必要な場合に使用されます。たとえば、Netty と RocketMQ はオフヒープメモリを使用してプロセスを高速化します。

したがって、システムメモリの使用量が非常に大きい場合は、スタックをチェックしても結果が出なかった場合、オフヒープメモリの使用量をチェックして、オフヒープメモリがオーバーフローしていないかどうかを確認できます。

要約する

事前に設定を行ってください

JVM の問題自体は比較的抽象的で直感的に発見するのが難しいため、プロジェクトがオンラインになる前に、コードロジックをテストするだけでなく、スタックサイズ、ガベージコレクターの種類など、アプリケーションのサイズと特性に応じて JVM パラメータを合理的に構成し、適切なパラメータを選択することも必要です。

さらに、ガベージコレクションログを保持し、メモリオーバーフローが発生したときにダンプファイルを保存する必要があります。

プロセスを監視する

プログラムがオンラインのときは、Spring Admin などの軽量監視ツールを使用したり、大規模なプロジェクトの場合は Cat や SkyWallking などの分散リンク監視システムを使用したりして、JVM を適切に監視します。

現場での保護とその後の分析を提供する

パラメータ構成と監視プラットフォームがどれほど合理的であっても、例外は必ず発生します。これは正常です。例外がない場合にのみ問題が生じます。例外が発生した後、シーンはタイムリーに保存される必要があります。マルチインスタンスアプリケーションの場合は、例外が発生したインスタンスを一時的にオフラインにして、問題をトラブルシューティングすることができます。単一インスタンスのサービスの場合は、最新のログとダンプが保存されていることを速やかに確認する必要があります。確認後、サービスを再起動するアクションを実行します。

この記事はWeChatの公開アカウント「古代の凧」から転載したものです。下のQRコードからフォローできます。この記事を転載する場合は、Ancient Kite の公開アカウントにご連絡ください。

<<: 専門家の予測：2021年にクラウドコンピューティング分野で出現するトレンド

>>: VMware が 3 年連続で Gartner Magic Quadrant の WAN エッジインフラストラクチャのリーダーに選出