問題タブ [visualvm]

オブジェクトから間接参照への最初のパスを見つけようとしています。

次のコードは、私が思いついたものです。

この Javascript を VisualVM の OQL クエリ ウィンドウ内で実行します。

これは、referrerObj のすべてのレフリーを 1 つずつ最大の深さまで通過することになっています。ターゲットがまだ見つからない場合は、次のレフリー レベルを調べる必要があります。

ただし、何らかの理由で、渡された最初のリファラーの最初の直接被参照者の可能なパスをたどった後、コードは実行を停止するようです。

2 番目の while ループが完了していないように見えます。エラーコードは表示されませんが、何も返されません。

なぜこれが起こるのか、誰にも手がかりがありますか? 他の誰かが VisualVM でこれを実行し、その結果を報告できれば、それは素晴らしいことです。

ありがとう。

NetBeans プロファイラー (実際には組み込みの VisualVM) を使用して、Java アプリケーションのメモリ消費を監視しています。ヒープビュー、存続世代ビュー、およびメモリ ダンプを使用して、メモリ リークを追跡します。

ヒープ ビューには使用済みメモリの合計が表示されますが、ガベージ コレクタがメモリを管理する方法が原因で、少し混乱しています。グラフは本質的に鋸歯状であるため、特に読みにくいです。場合によっては、GC を強制的に実行して、実際のメモリ消費量をより正確に把握できるようにします。

私は疑問に思っていました:メモリプロファイリングにより適したガベージコレクタがあり、実際のメモリ使用量に近いヒープグラフを生成するものはありますか? -XXまたは、より一般的には、メモリリークを効率的に追跡するために、どの JVM 設定 (オプションまたはその他) を使用できますか?

数分後にハングする Web アプリケーションがあります。基本的に、これは非常にカスタマイズされたフォームを作成およびプレビューするためのアプリケーションであり、数分間の集中的なユーザー操作の後、アプリケーションは動作を停止します。これは、要求が完了し、応答が返されないことを意味します。

Tomcat のログやアプリケーションのログにもハングに関する手がかりが見つからないため、「少し」迷っています。lambda/psi-probe を使用しているため、アプリケーション サーバーは実行されており、他のアプリケーションや面倒なアプリケーションも問題なくチェックできます (プローブ自体は別の Web アプリケーションです)。

アプリケーションは、長い間正常に動作していた休止状態を使用していますが、最近、パフォーマンスを向上させるために (休止状態のみを使用する場合、休止状態は多くのクエリを挿入します)、java.sql 標準 API を介してネイティブ SQL を導入しました。私は両方を混在させないように注意しており、それらは jsp でのみ使用されます。最初に休止状態でいくつかの (少数の) オブジェクトを取得し、次に jdbc でいくつかのロジックを使用します。jdbc を使用する前に、Hibernate セッションが閉じられます。

データベース接続の問題 (何度か確認しましたが、データベース サーバーは正常に動作しています)、デッドロックまたはランナウェイ スレッドについて読んだことがあります。VisualVM で VisualVM を使用して確認しました。

では、誰でもハングを見つけたりトラップしたりする手がかりを与えることができますか? 仮想のランナウェイ スレッドまたはデッドロックをキャッチまたはトラップするために VisualVM を使用する手がかりを得ることができますか? 待機中のスレッドと実行中のスレッドが表示されるだけなので、後者は私を啓発します。

私は tomcat 6.0.21 を使用しています (私は常に同じ結果で 7.0.11 を試しました) Mac osx および Linux (開発および試作マシン) で Java 1.6

どんなアイデアでも大歓迎です。

ウィリー

私はこの小さな（そして残酷に非効率的な）クラスを作成し、JavaVisualVMを使用してそれをプロファイリングしたいと思いました。

結果は奇妙です。結果は、ConnectionHandler.run（）の呼び出しによって完全に支配されます。

（98.2％）sun.rmi.transport.tcp.TCPTransport $ ConnectionHandler.run（）
（1.7％）java.lang.Thread.join（long）
（0％）java.lang.String.equals（Object）
など。 。

プロファイルされたメソッドはおそらく約100あり、そのうちの1つはfib（int）ではありません。

私のプログラムが実際にすべての時間をこれらの方法に費やしているとは考えられません。それらは私のjvmに接続し、そのことを実行しているプロファイラーのようです。

私は何が間違っているのですか？

わかりやすくするために編集： nに45を渡すと、このアプリケーションは20秒間実行されます。私が最初にプロファイリングしていたプログラム（フィボナッチ計算機ではない）は、CPUの4つのコアすべてを100％でペグし、最大5分間のプロファイリング実行を実行していました。これらは同じ結果であり、私のアプリケーションのメソッドはホットスポットメソッドリストの上位に表示されませんでした。

実行ごとに異なりますが、ConnectionHandler.run（）が常に最上位にあり、通常、プロファイル時間の約99％を占めます。

2番目の編集：サンプラーを使用してみましたが、JProfilerが生成しているものと一致する結果が得られています。これの欠点は、プロファイリングに付属するスタックトレース情報を取得できないことです。しかし、私の差し迫ったニーズにとって、これは素晴らしいことです。

遊んでいるときに私が発見したことは、VisualVMがメソッド呼び出しの実時間をプロファイリング中にカウントすることです。

私の特定のケースでは、私のアプリケーションには、ワーカースレッドを起動し、キューでのメッセージの待機をすぐにブロックするメインスレッドがあります。

これは、私のCPUを消費しているのはこのメソッドではないという事実にもかかわらず、ブロッキングメソッドがプロファイラーでほとんどすべての時間を費やしているように見えることを意味します。

同じことがsun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run（）メソッドにも当てはまると思いますが、このメソッドは正常に機能しますが、終了すると、アプリケーションで最も長く実行されるメソッドの1つになります。