問題タブ [thread-dump]

Java Web Start アプリケーションのスレッド ダンプを取得することはできますか? もしそうなら、どのように？

開発者以外 (顧客) がスレッド ダンプを作成できる簡単な解決策があればいいのですが。または、プログラムでスレッド ダンプを作成することは可能ですか?

Java Web Start コンソールでは、「t」を押すとスレッドのリストを取得できますが、スタック トレースは含まれません。

回答に特定の Java バージョンが必要な場合は、そう言ってください。

プログラムでスレッド ダンプを生成するのが好きです。基本的に2つの方法があることを学びました。

1. 「Java 仮想マシン ツール インターフェイス」JVM-TI を使用する
2. より高度に抽象化された「Java Debugger Interface」JDI を使用する

JVM-TI については、いくつかの有用な情報を見つけることができましたが、JNI-DLL を作成する必要があり、少なくとも当面は回避したいと考えています。JDI では Java を使用でき、アプリケーション内から使用できるようです。しかし、何らかのチュートリアルや HOWTO を見つけることができませんでした。私が見つけた唯一のドキュメントは Java-Docs http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdi/でした。このクラスの使い方。

それで、私が読むことができる良いチュートリアル/本を知っている人はいますか?

助けてくれてありがとう！

別の Java プロセスを実行するコンソールから実行する Java アプリケーションがあります。その子プロセスのスレッド/ヒープ ダンプを取得したい。

Unixではできましたkill -3 <pid>が、Windowsの知る限り、スレッドダンプを取得する唯一の方法はコンソールでCtrl-Breakです。しかし、それは子プロセスではなく、親プロセスのダンプのみを提供します。

そのヒープダンプを取得する別の方法はありますか?

以前は、kill -quit を実行してスレッド ダンプを生成し、サーバー ログが存在するログ ファイルにそれらを取得していました。ファイルが大きくなりすぎたので、rm を使用してファイルを削除し、同じ名前の新しいファイルを作成しました。kill -quit を使用してスレッド ダンプを取得すると、ログ ファイルに何もコピーされず、空になります。

誰でも助けることができますか？

私はWeblogicのトラブルシューティングの新人です。

実稼働環境に問題があります。環境に直接アクセスすることはできません（ホスティング担当者がアクセスしますが、質問できるようになるまでには数時間かかります）。

問題が本番環境で明らかになったときからスレッドダンプがあります。ダンプを調べていくつかのことを推測することはできますが、それは非常に構造化されており、人々がいつも何かをしていることを考えると、それらを解釈するのに役立つツールがあると思います。ある？

それができない場合、私がそれらを解釈することを学ぶのに役立ついくつかの有用な文書またはウェブサイトがありますか？

javacore、スレッドダンプ、ヒープダンプの正確な違いを教えてもらえますか? これらはそれぞれどのような状況で使用されますか??

MONOで実行されるハングしているアプリケーションでスレッド（スタックトレース）を表示するにはどうすればよいですか？

.NETでManagedStackExplorer（MSE）を使用してそれを実行できることを知っています。アプリケーションはMONOでのみハングするため、MONOで実行する必要があります。

または、ぶら下がっている場所を見つける方法は他にありますか？

私は、Tomcat で実行される実稼働 Web アプリケーション (Struts、iBatis、Hibernate) を使用しています。このアプリケーションは、6 ～ 7 日間の実行後に要求を処理している間にハングしますが、スレッド ダンプを実行すると再び正常に実行されます。

どうしてそうなったのか理解に苦しむ。

他の誰かが似たようなことに遭遇したことがあるかどうか疑問に思っていました。

プロセスの1つのスレッドダンプを取得しました。これらのスレッドがたくさんあります。彼らはたくさんの記憶を保持していると思うので、私はOOMを取得しています。

私はそれがどのようにしてこの状況に到達したのかを調べようとしています。CustomThreadedExtractorWrapperは、スレッドを起動して何らかの作業を行うラッパークラスです（ExtractionThreadは、ZipExtractorCommonsCompressを使用して圧縮ストリームからzipコンテンツを抽出します）。タスクに時間がかかりすぎる場合は、ExtractionThread.interrupt()を呼び出して操作をキャンセルします。

ログを見ると、キャンセルが25回発生したことがわかります。そして、これらのスレッドのうち21個がダンプに表示されます。私の質問：

1. これらのスレッドのステータスはどうなっていますか？生きていて走っていますか？どういうわけかブロックされましたか？
2. 彼らはどうやら.interrupt（）で死ななかったのですか？本当にスレッドを殺す確実な方法はありますか？
3. スタックトレースで「ロックされている」とはどういう意味ですか？

Inflater.javaの223行目は次のとおりです。

（jsvcの下で）デーモンとして実行されているJavaプロセスがあります。数日ごとに、作業を停止します。ログファイルへの出力は停止し（5分間隔でかなり冗長です）、CPUやIOを消費しません。

ログファイルにも、syserrまたはsysoutにも例外は記録されません。最後のログステートメントは、db commitが実行される直前ですが、dbサーバー（MySQL）に開いている接続がなく、コードを確認しているため、例外が発生した場合でも、その後は常に追加のログ出力があります。泡立つつもりだった。

私が見つけた最も興味深いことは、スレッドダンプ（以下に含まれています）には、コードにスレッドがまったくなく、メインスレッドにはコンテキストがまったくないように見えることです。

前述のように、これはjsvcを使用して実行されるデーモンプロセスですが、それがそれと関係があるかどうかはわかりません（コードを再構築して、直接実行してテストすることもできます）。

ここで何が起こっているのかについて何か提案はありますか？

ありがとう...dwh

フルスレッドダンプ：