4

Java アプリケーションをプロファイリングすると、興味深い事実に気づきます。JVM がデス スレッド ダンプの GC スパイラルにある場合、次のようになります。

"1304802943@qtp-393978767-9985" prio=10 tid=0x00007f3ed02dd000 nid=0x74e7 in Object.wait() [0x000000004febb000]
 java.lang.Thread.State: TIMED_WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:626)
    - locked <0x00000007aed40048> (a org.mortbay.thread.QueuedThreadPool$PoolThread)

"26774405@qtp-393978767-9984" prio=10 tid=0x00007f3ee4b37000 nid=0x74e6 in Object.wait() [0x0000000045d1a000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:626)
    - locked <0x00000007aed83aa0> (a org.mortbay.thread.QueuedThreadPool$PoolThread)

"764808089@qtp-393978767-9983" prio=10 tid=0x00007f3ee4c50000 nid=0x74e5 in Object.wait() [0x000000004ad6a000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:626)
    - locked <0x00000007aed5c448> (a org.mortbay.thread.QueuedThreadPool$PoolThread)

そのため、状態には多くのスレッドがありTIMED_WAITINGます。理論的には、この状況は正常に機能しているアプリケーションで簡単に見つけることができます (アプリケーションには現時点で受信リクエストがないだけです) が、単一のリクエスト ディスパッチ スレッドで何か有用なことを行っているものは見つかりません (公称ヒット率は約 100 hp です)。

この動作は GC と関係がありますか、それとも単なる偶然ですか?

4

3 に答える 3

3

質問のタイトルだけに答える：

JVMがGCで時間を費やしたとき、スレッドダンプはどのように見えますか？

答えは次のとおりです。（通常の方法で）そのようなダンプを取得する手段はありません。

JVMは、GC内では発生しないセーフポイントに到達した後にのみ、スレッドダンプの要求を処理します。

しかし、この投稿で言及されている文書化されていないJVMTI関数AsyncGetCallTraceの助けを借りて、アクティブなGCのスレッドダンプを取得するチート方法があります。

http://jeremymanson.blogspot.com/2010/07/why-many-profilers-have-serious.html

また、 Oracle Solaris Studioを使用して、このようなネイティブ/Javaの混合スレッドダンプを取得できることも示唆しています。

于 2012-12-29T17:55:55.837 に答える
1

jmap -histo:live を時間をかけて試してみてください。出力を比較して、どのオブジェクト タイプが増加しているかを確認できます。

jmap 用に JDK をインストールする必要があります。 http://docs.oracle.com/javase/6/docs/technotes/tools/share/jmap.html

警告、jmap は負荷が高いため、実行中にすべてのスレッドが一時停止しますが、これは数秒しかかかりません。プロセスは集中的であるため、コア ダンプを実行できます。通常は迅速で安全ですが、大規模なアプリケーションやマルチギグ ヒープがロックされたり強制終了されたりするのを見てきました。

于 2011-12-30T16:57:35.477 に答える
0

私の推測では、何かをするのを待っているスレッド プールがあると思います。プロセスが効率的で、1 秒あたり 100 件のリクエストがある場合でも、何かを実行しているスレッドを 1 つでもキャッチするのに問題がある可能性があります。プロセスの CPU 負荷を確認することをお勧めします。50% の場合、何かを実行している 1 つのスレッド (おそらく要求スレッドではない) を見つける可能性は 50% です。

サーバーが何に時間を費やしているかを確認したい場合は、VisualVM のようなプロファイラー、または YourKit のような商用プロファイラーを試してみます。

あなたのコードをGoogle検索すると、別のバージョンが見つかりましたhttp://grepcode.com/file/repo1.maven.org/maven2/org.mortbay.jetty/jetty-util/7.0.0.pre5/org/mortbay /thread/QueuedThreadPool.javaただし、run() メソッド内のこのブロックでスレッドが TIMED_WAIT であると思われます

                // We are idle
                // wait for a dispatched job
                synchronized (this)
                {
                    if (_job==null)
                        this.wait(getMaxIdleTimeMs());
                    job=_job;
                    _job=null;
                }
于 2011-12-07T08:51:40.230 に答える