回します。https：//www.cnblogs.com/wanghaoyang/p/11687329.html
数日前、ちょうどCPU-javaの高すぎる私のオンラインサービスの運用・保守を教えてください。
次のような問題を解決するための具体的な発見プロセスです。
1：によって#topトップコマンドの私のJavaサービスのように、実際にはほとんど満たされたCPUで表示します
このプロセスは、18400 CPU使用率は間違いなく正常ではない12％に達し、見ることができますので、我々はスレッドがCPUを占有し、最終的に分析しようとしています
2：-hp 18400 #topトップ我々は、スレッドの場合には、このコマンドは、以下のスクリーンショットの一部を、このプロセスを見ることができます。
その後、我々はこれらのスレッドの解析について詳述し、スレッドCPUのフロントが比較的高い占有、スクリーンショットで見ることができます
3：私たちは18400を#jstack>は18400.txt追いつくために、このスレッドのスタックjavaプロセスを命じる、あなたは、比較される数回以上のものをキャッチすることができます。
私たちは、18414このスレッドを持って、例えば、それは、私たちは、ファイル47eeでこれを発見しようとしている、Linuxは進47ee terminalコマンドに「％x」は18414スレッドIDを#printfすることができ、進数に変わりますスレッドやって次のように、いくつかのショットがあります
私たちは、47ee、ガベージコレクションのスレッドを見ることができ、我々は他の高占有CPUスレッドのために同じことを行う、GCスレッドが発見されています。このサービスは、JavaのGCを説明したが、これは非常に正常です。だから我々は状況のGC分析しようとしています。
4：コマンド18400千100 -gcutil #jstat GCがオープンケースを取っ見るために、次のように、いくつかのショットがあります
非常に直感的ではありません、この列によってYGCがyounggcの数の増加は認められなかったが、このコラムでfullgc FGCの数が増加している見るために、ひどい歳（このコラムを通じてOを参照）を回復していません。
メモリリーク：これは、あなたが名詞を考える時ではないです。はい、我々はメモリリークがある場合に分析する必要があります。
5：私たちはすることができ、フォーマット= B生きる：-dump #jmap 、ファイル= 18400.dump 18400 ダウン現在のスタックをダンプするには、このプロセスを。このファイルは、ヒープのスナップショットとして見ることができることに注意してください、そんなに現在のヒープ、ほとんどあまりダウンダンプ。私はほとんどの2Gを下にダンプします。
この文書では、我々が分析する必要がある、あなたが分析jhatコマンドを使用することができ、もちろん、私たちはしばしば、このようなJDKなどのより強力なグラフィカルツールですVisualVMのを来て、あなたも（私はこれを使用する）は、サードパーティJProfilerをを使用することができますEclipseを使用する場合は、プラグインMATをインストールすることができます。これらのツールは、ヒープ・ダンプ・ファイルを分析することができます。
大きいかもしれダンプ・ファイルに起因することを、注意してくださいので、必要なメモリ分析ツールは、それが最高のマシンの比較的良好なパフォーマンスで分析され、比較的大きいです。
ここでJProfilerを私の分析のいくつかのスクリーンショットです
メモリの97％を占めているオブジェクトがある、非常に直感的ではありません。次のステップは、参照されている製造にオブジェクトを分析することです。私はその後、私は手の込んだはありませんあなたのコードを結合する必要があるかもしれない何かを、保存されている。このLinkedListのを分析するために行く、ここにあるLinkedListのは、すべてのスペースをとり、明らかです。
非同期リクエストキューが長すぎるJestClient ElasticSearchクライアントツールのうち私の分析では、ノードは、非同期リクエスト情報をある全体のリストは、おそらく10万人以上を生成しました。消費がなく、時間内に回復することはできません、それはメモリリークが発生していました。（スレッドプールを使用すると、この場合にも発生する可能性があることに注意してください）
6：その後、残りの部分は、問題を解決することであり、その理由を分析します。私はラインに急いでいたので、私はこの問題を一時的に同期、非同期、一時的な解決策に入れてどのように非同期キュー長JestClient機能、知りません。ラインCPUの状況を確認した、ガベージコレクションは、実際に正常に戻りました。
全体として、上記の6つのステップは、もちろん、欠陥を有していてもよく、完全な分析溶液JVM仮想マシンのメモリリークプロセスであるが、一般的な考え方は正しいです。
この記事を通じて、我々は次のように結論付けることができます：
1：Javaサービスを分析するためにどのようにあまりにも多くのCPUの問題を占めています
2：キューがキューの長さに注意を払う必要がある場合にメモリリークを防ぐため、Javaのさまざまなを使用してください。
3：それは、JVMメモリモデルを理解するのが最善です