2

約 1 ～ 2 時間実行されるマルチスレッド インポートを実行しています。およびインポートでは、データをテーブルに入れる前に。私はチェックしています

if(debug.isEnabled())
 logger.debug("Object="+MyObject);

whereメソッドでMyObjectを使用しToStringBuilderますtoString。

java.lang.OutOfMemoryError: GC overhead limit exceeded
        at java.util.Arrays.copyOfRange(Arrays.java:2694)
        at java.lang.String.<init>(String.java:203)
        at java.lang.StringBuffer.toString(StringBuffer.java:561)
        at org.apache.commons.lang3.builder.ToStringBuilder.toString(ToStringBuilder.java:1063)

toStringBuilder がこの問題を引き起こしていると考えています。私は正しいですか？はいの場合、これを修正する方法は何ですか?

4

2 に答える 2

5

必ずしも。このエラーが意味するのは、ほとんどヒープ領域が不足しており、十分な領域を再利用せずに実行しすぎたため、ガベージ コレクターが領域の再利用をあきらめていることです。コードのその時点で発生したという事実は、必ずしも何の意味もありません。まったく別の何かがスペースを食い尽くした可能性がありますが、その呼び出しが GC をもう一度開始し、最終的にあきらめました。ヒープ ダンプを取得し、 YourKitやVisualVMなどのプロファイラーで実際に何が起こっているかを確認する必要があります。

于 2013-02-26T05:08:42.913 に答える
0

オブジェクトは、おそらくtoStringBuilder（）メソッド内で、メモリ内に大きすぎる文字列を作成します。

これを回避するには、次のように行ごとにデータベースにインポートしてみてください。

if (debug.isEnabled()) {

   // since you are importing rows it must be a collection/array
   logger.debug("Object=");
   for(Row r in MyObject.getRows()) {
      logger.debug(r);
   }
}

または、まれに、ログに記録する大きなオブジェクトがある場合は、圧倒的な文字列を作成するのではなく、コンテンツをストリーミングしてログに記録することで、オブジェクト自体をログに記録します。

于 2013-02-26T05:37:58.030 に答える