次の条件が当てはまる場合、JavaVMのクラッシュを解決するためのベストプラクティスは何ですか。
- 独自またはサードパーティのネイティブコードはありません。100％純粋なJava
- 同じプログラムが他の多くのシステムで問題なく実行されます。
PS：VMがクラッシュすると、VMがhs_err_pid1234.logのようなダンプファイルを書き込んで終了することを意味します。
3397 次
5 に答える
4
hs_err_pid1234.logファイル（またはエラーログファイル名）を読み取ります。通常、そこには手がかりがあります。次のステップは、ログで何を発見するかによって異なります。
はい、使用しているJVM実装の特定のバージョンのバグである可能性がありますが、オペレーティングシステムのメモリの断片化によって引き起こされる問題も確認しています。たとえば、Windowsは不適切な場所にdllを固定する傾向があり、結果としてJVMが要求したときに連続したメモリブロックを割り当てることができません。他のoutopfメモリの問題も、このタイプのクラッシュダンプを通じて明らかになる可能性があります。
于 2008-10-22T11:13:23.797 に答える
3
JVMを更新または交換します。現在最新バージョンを使用している場合は、古いバージョンを試してください。最新バージョンがない場合は、更新してみてください。たぶん、あなたの特定のバージョンでの既知の問題ですか？
于 2008-10-22T11:03:39.743 に答える
2
マシン間でのJVMバージョンが同じであると仮定します。
JVMがクラッシュしているマシンの違いを理解してください。同じバージョンですかOS？OSたとえば、特定のバージョンのRedHatでJVMがクラッシュするという問題があります。また、一部の古いRed Hatバージョンでは、余分なメモリを適切に処理できず、スワップスペースが不足していることがわかりました。（私たちの解決策はRedHatをアップグレードすることでした）。
また、プログラムはマシン間でまったく同じことをしていますか？共有ファイルシステムにアクセスしていますか？ファイルシステムはあなたのマシン（SMB/NFSなど）に同様にマウントされていますか？何かが違うに違いない。
mallocログファイルは、クラッシュが発生した場所（たとえば）の情報を提供するはずです。
于 2008-10-22T11:41:10.107 に答える
0
ダンプ ファイルのスタック トレースを確認すると、クラッシュが発生したときに何が起こっていたかがわかります。
ダンプ ファイルを掘り下げるだけでなく、hs_errSun または JVM の作成者にも提出します (ファイルの先頭に方法の説明があると思いますか?)。傷つくことはありません。
于 2008-10-22T14:22:46.630 に答える
0
32ビット？64ビット？クライアント マシンの RAM の量は? プロセッサー? オス？システム間に接続があるかどうかを確認します。つながりがヒントになるかもしれません。他のすべてが失敗した場合は、JVM の異なるメジャー/マイナー バージョンを使用することを検討してください。また、問題が始まったばかりの場合、(バージョン管理を介して) プログラムがクラッシュしなかった時点に到達できますか? hs_err ログを調べると、クラッシュの原因がわかる場合があります。JVM が使用する他のクライアント ライブラリのバージョンである可能性があります。最後に、デバッグ/プロファイルでプログラムを実行すると、クラッシュする前にいくつかの症状が表示される場合があります (複製できると仮定します)。
于 2008-10-23T11:45:14.327 に答える