オンライン問題レビュー、JVM Fast Throw のストーリー

[[394549]]

まず第一に、これは JVM の基盤となる最適化に関するいくつかの知識ポイントに関係する悲しい話です。初めてこのような問題に遭遇したときのことを振り返ってみると、「必要なときに十分な知識を持っていなかったことを後悔するだけだ」という古い格言があることに気付きました。

夜8時頃、担当メッセージセンターの運用保守グループから、多数のユーザーがテキストメッセージを受信できないとの報告がありました。 Kibana にログインして、対応するエラー ログを検索すると、多数の添え字範囲外例外が見つかります。

その時点でオンラインの問題は修正されました。ただし、問題が発生した場合は、その原因を突き止めなければなりません。そうしないと、次回に再び問題が発生する可能性があります。

ELK 上でログ分析を実行するのは不便であり、対応する例外に基づいて異なる緯度で統計分析を実行することは困難であるため、運用保守スタッフに連絡して、障害が発生した日の情報ログとエラー ログを取得してオフライン分析を行いました。

ログ分析の結果、異常な出力には 2 種類あることがわかりました。 1 つのタイプには次のようなスタック情報があります。

 java.lang.ArrayIndexOutOfBoundsException: -1
 ...スタック情報を省略

もう 1 つはさらに奇妙で、例外のみがあり、対応するスタック情報がありません。

 java.lang.ArrayIndexOutOfBoundsException: null  

最初のタイプの問題は見つけやすいです。例外スタック情報に基づいて、特定のコードが特定され、直接修復されます。 2番目のタイプの問題はより困難です。

実は、この 2 つは例外であり、後でそれがわかるようになります。その後私がしたことはすべて、2つのことを明確にするためでした。

• 例外メッセージに null が出力されるのはなぜですか?
• スタック情報が出力されないのはなぜですか?

JVM 高速スロー

ファストスローとは何ですか?

簡単に言えば、一部の例外タイプ (null ポインター、範囲外の添え字、算術演算など) がコード内の固定の場所で複数回スローされると、仮想マシン (HotSpot VM) は一致するタイプの事前に割り当てられた例外オブジェクトを直接スローします。この例外オブジェクトのメッセージとスタック トレースは両方とも空です。

これを読んだ後、読者は同じ例外が異なるログを出力する理由を理解したと思います。同じ場所で例外が複数回スローされるため、JVM は事前に割り当てられた例外をスローし、メッセージとスタック トレースが取り込まれます。

サーバー VM のコンパイラは、すべての「コールド」組み込み例外に対して正しいスタック バックトレースを提供するようになりました。パフォーマンス上の理由から、このような例外が数回スローされた場合、メソッドが再コンパイルされることがあります。再コンパイル後、コンパイラはスタック トレースを提供しない事前割り当て例外を使用するより高速な戦術を選択する場合があります。事前に割り当てられた例外の使用を完全に無効にするには、この新しいフラグを使用します: -XX:-OmitStackTraceInFastThrow。

この状況は、JDK 1.5 のリリース ドキュメントに記載されています。この最適化の理由はパフォーマンスを向上させるためです。同じ例外が同じ場所で複数回スローされた場合、コンパイラはメソッドを再コンパイルします。再コンパイル後、コンパイラはスタック トレースを提供しない事前割り当て例外を使用するより高速な戦略を選択する場合があります。

この事前割り当て例外メカニズムをオフにする場合は、-XX:-OmitStackTraceInFastThrow を使用できます。興味のある読者はリリースノートをご覧ください: https://sourl.cn/PMzVkC

さらに、JVM ソース コードによると、Fast Throw メカニズムは現在、次のスクリーンショットに示すように 5 つの異常な状況をサポートしています。

高速投球のシミュレーション

上記はすべて理論的な部分です。この章ではコードを使用して練習します。

リスト<String> list = new ArrayList();
 ( int j = 0; j < 10000; j++)の場合{
    試す {
        リストを取得します(-1);
    } catch (例外例) {
 int長さ = ex.getStackTrace().length;
        システム。 out .println(String.format( "例外エラー:: %s、スタック長:: %s" 、ex、length));
    }
 }

上記のプログラムは Java 8 環境で実行されます。プログラムを実行した結果から、Fast Throw は Java 8 でも依然として有効であることがわかります。

特別な状況がない場合は、この機能をオフにしないことをお勧めします。インターフェースの同時実行量が大きい場合、プログラムのバグにより、多数のリクエストが同じコードで例外をスローする可能性があり、Fast Throw メカニズムによってパフォーマンスの低下を大幅に防ぐことができます。シングルスレッドのテストデモでは、異常な呼び出しが多いほどパフォーマンスの差が大きくなることがわかっています。

オンライン環境が Fast Throw メカニズムをトリガーした場合、同じ場所と同じ例外を持つログを遡って、問題の原因を突き止めることができます。

結論

これらすべての言葉を 1 つの文にまとめると、「リファクタリングはリスクを伴うため、オンラインで起動する際には注意が必要です。」

公共機能の再構築には、あらゆるテストケースを組み込む必要があります。問題の出力背景を極限まで考慮するか、需要背景を周囲の同僚に説明する必要があります。一緒に考えることで、極端な問題の発生を大幅に回避できます。

必要なストレス テストは非常に重要であり、事前に大量のトラフィックが発生した場合にのみ発生する問題を明らかにすることができます。

障害の発生の重要性は良い面と悪い面の両方があります。悪い点は誰もが知っています。良い点は、当然ながらオンラインでの問題のトラブルシューティングの経験を積むことです。こうすることで、後で会社の女の子が同じ問題に遭遇したときに、彼女は叫ぶでしょう。「女の子、そのバグは放して、私にやらせてください！」