0

OutOfMemoryError に続いて、結果のヒープダンプを IBM Support Assistant の 64 ビット メモリ アナライザー (Websphere 7.0.23 で実行されている J9 VM) で処理しました。

いくつかのリーク候補がリストされました (すべてシステム クラスローダー関連) が、そのうちの 1 つは、StringBuffer で 256 の値で初期化された char[] に実際には 7700 万の null 文字が含まれていることを示しているようです。

Support Assistant からの結果の heapdump 分析は、char[77418987] @ 0xc32* * * \u0000\u0000\u0000を示しています.....

これは StringBuffer -> PatternLayout -> TimeAndSizeRollingAppender によって参照されます

保持されたヒープは、各文字に 2 バイト、配列自体に 18 バイト、合計で 150 MB 以上をチェックアウトします。

Log4j のバージョンは 1.2.16 で、simonsite の TimeAndSizeRollingAppender を使用しています (この依存関係を削除したいのですが)。

これは Support Assistant からの誤検知でしょうか、それともヒープ上で char[256] が char[77000000+] になる方法はありますか?

4

1 に答える 1

1

デフォルトでは、WebSphere は OOM イベントに応答して PHD ファイルを生成します。注意すべきことの 1 つは、これらのダンプにはヒープ内のオブジェクトとその参照に関する情報が含まれているが、(プリミティブ型の) 属性と配列に格納されている実際のデータは含まれていないということです。そのため、メモリ アナライザーはゼロしか表示しません。根本原因に関する詳細情報を取得するには、システム ダンプを作成するように WebSphere を構成する必要があります。これにより、配列内のデータを確認できるようになり、何が起こっているかについてのヒントが得られるはずです。

次のリンクは、これを行う方法を説明しています。

http://pic.dhe.ibm.com/infocenter/isa/v4r1m0/topic/com.ibm.java.diagnostics.memory.analyzer.doc/producing.html

256 vs. 77000000+ の質問: 256 は StringBuffer の初期容量にすぎません。データが追加されると、必要に応じて自動的に拡張されます。

于 2014-02-28T08:39:22.187 に答える