Java ガベージ コレクションと jvm での stw の分析

この記事は主に、Java コードの一時停止、JVM のスレッド、およびその他の関連コンテンツを含む、JVM の Java ガベージ コレクションと stw についての簡単な理解を紹介します。必要な方はぜひ参考にしてください。

Java の Stop-The-World メカニズム (STW と呼ばれます) は、ガベージ コレクション アルゴリズムの実行時に、Java アプリケーションの他のすべてのスレッド (ガベージ コレクション ヘルパーを除く) が一時停止されるというものです。 Java のグローバル一時停止現象、グローバル一時停止、すべての Java コードが停止する、ネイティブ コードは実行できるが JVM と対話できない、これらの現象は主に gc によって引き起こされます。

GC中のストップ・ザ・ワールド(STW)は誰にとっても最大の敵です。しかし、GC に加えて、JVM でも一時停止が発生することを知らない人も多いかもしれません。

JVM には特別なスレッド (VM スレッド) があり、GC のディスパッチ、スレッド ダンプなどの特別な VM 操作を実行するために特別に使用されます。これらのタスクでは、ヒープ全体とすべてのスレッドのステータスが静的である必要があります。一貫性のみが達成できます。したがって、JVM はセーフ ポイントの概念を導入し、VM 操作が必要なときに静的セーフ ポイントに入るようにすべてのスレッドに通知する方法を見つけました。

GC に加えて、安全性ポイントをトリガーする他の VM 操作には以下が含まれます:

1. コードの最適化解除、コード キャッシュのフラッシュなどの JIT 関連。埋め込み);

3. バイアスされたロックの取り消しにより、バイアスされたロックがキャンセルされます。

セキュリティ ポイントを監視して、JVM に何が起こったかを確認します。

最も簡単な方法は、JVM 起動パラメータの GC パラメータにもう 1 つの文を追加することです:

-XX:+PrintGCApplicationStoppedTime

これは、GC ログにすべての JVM 一時停止時間 (GC だけでなく) を出力します。内部。

2016-08-22T00:19:49.559+0800: 219.140: アプリケーション スレッドが停止された合計時間: 0.0053630 秒

これは非常に便利な必須パラメーターであり、ほとんどすべての一時停止を引き起こす可能性があります...

ただし、JDK 1.7.40 より前のバージョンではタイムスタンプが出力されなかったので、JVM が停止した時間だけを知ることができますが、いつ停止したかはわかりません。現時点での簡単な方法は、「-XX:+PrintGCApplicationConcurrentTime」を追加して、2 つの一時停止間の JVM の通常の実行時間を (これもタイムスタンプなしで) 出力することですが、少なくとも、タイムスタンプ付きの GC ログを使用して元に戻すことができます。やめてください、もうそうなる時が来ました。

2016-08-22T00:19:50.183+0800: 219.764: 適用時間: 5.6240430 秒

どのような理由で発生した一時停止を印刷するにはどうすればよいですか?

パラメータをさらに 2 つ追加します: -XX:+PrintSafepointStatistics -XX: PrintSafepointStatisticsCount=1

この時点で、同様の内容が stdout に出力されます

vmop [threads: totalInitial_running wait_to_block]1913.425: GenCollectForAllocation [ 55 2 0 ] [time: スピン ブロック同期クリーンアップ vmop] page_trap_count[ 0 0 0 0 6 ] 0

このログは 2 つのセクションに分かれています。最初のセクションはタイムスタンプ、VM 操作のタイプ、およびスレッドです。概要

total: 安全なポイント内のスレッドの総数

initially_running: 安全なポイントの開始時に実行されているスレッドの数

wait_to_block: 一時停止を待機する必要があるスレッドの数VM 操作が開始されます

2 行目は、セーフポイントに到達するときのさまざまな段階と、操作の実行にかかる時間 (最も重要なのは vmop です) です

spin: スレッドが応答するのを待つ時間

セーフポイント呼び出し

ブロック: すべてのスレッドを一時停止する時間

同期: スピン+ブロックに等しい、これは最初からセーフポイントに入るまでにかかる時間であり、これを使用して、安全ポイントに入るまでにかかる時間

cleanup: クリーンアップにかかる時間

vmop: VM 操作を実際に実行するのにかかる時間

これらの多くの、しかし非常に短い安全ポイントは、次のとおりであることがわかります。詳細については、同時実行性の高いアプリケーションでは、起動パラメータに「-XX:-UseBiasedLocking」を追加するだけでそれをキャンセルできます。さらに、一部の型は vm 操作ではなく、1 秒ごとに安全なポイントに入ることが保証されている (GC がこの秒を通過した場合は必要ありません) と書かれていることもわかりました。 -安全なポイントで実行する必要がある緊急の操作。たとえば、一部のサンプリング プロファイラー ツールは -DEAN 保証された安全ポイント間隔で調整できますが、実際にはそれが毎秒行われるわけではなく、時間は変動します。

実際の戦闘では、安全なポイントのログを使用したところ、プログラムが定期的にスレッドダンプなどを呼び出していることがわかりました。ただし、セーフポイント ログはデフォルトで stdout に出力されるため、標準出力ログのパフォーマンスとクリーンさのために、通常はデフォルトでは有効にしません。必要なときだけ開きます。

VM で何が起こっているかを詳しく知るには、次の 3 つのパラメーターを追加します。残念ながら、これら 3 つのパラメータが設定されているからといって、JVM はセキュリティ ポイント ログを vm.log に転送せず、無駄に 2 回出力します。

-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=/dev/shm/vm.log

概要

以上がJava ガベージ コレクションと jvm での stw の分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。