問題タブ [out-of-memory]

パッケージ内のすべての単体テストをロードすると、make タスクが java.lang.OutOfMemoryError: Java ヒープ スペース エラーをスローします。

ただし、各サブパッケージですべてのテストを実行すると、すべてのテストが読み込まれ、問題なく完了します。OOM エラーが発生するのは、親パッケージですべてのテストを実行しようとしたときだけです。

この問題は、VM パラメーターを調整することによって解決されるべきではないと思います。最大ヒープと perm サイズを増やしてみましたが、問題は解決しませんでした。

これにより、異なるパッケージでテストをロードする間にガベージ コレクションに問題があるか、あまりにも熱心なクラスのロードが行われていると思われます。

これらの問題を処理できる JUnit 設定はありますか、それともテスト ケースのコードを変更または追加することで問題を解決する必要がありますか?

war を何度も再展開すると、jboss がjava.lang.OutOfMemoryError: PermGen space error を返すことがあります。そうであれば、自動的に jboss を再起動しますか?

大きな XML ファイルの内容を System.out に出力するプロセスがあります。

この出力がきれいに印刷されている場合 (つまり、複数行)、すべてが機能します。しかし、それが 1 行にある場合、Eclipse は OutOfMemory エラーでクラッシュします。これを防ぐ方法はありますか？

大きなデータ フレームを扱っていて、RAM の制限に達しました。この時点で、おそらくディスク上のシリアル化されたバージョンで作業する必要があります。メモリ不足操作をサポートするパッケージがいくつかありますが、どれが私のニーズに合っているかわかりません。すべてをデータ フレームに保持したいので、ffパッケージは有望に見えますが、回避できない互換性の問題がまだ残っています。

データがメモリ不足の規模に達したことに気付いたときに、最初に使用するツールは何ですか?

Sun のサイトの Out Of Memory ヘルプを使用しました。と引用されているところ

メモリ不足: 要求された配列サイズが VM の制限を超えています

これは、アプリケーションがヒープ サイズより大きい配列を割り当てようとしたことを示します。たとえば、アプリケーションが 512MB の配列を割り当てようとしたが、最大ヒープ サイズが 256MB である場合、このエラーがスローされます。ほとんどの場合、問題は、ヒープ サイズが小さすぎるか、バグにより、アプリケーションが誤って巨大であると計算されたサイズの配列を作成しようとすることのいずれかである可能性があります。

これをシミュレートしようとしました

私のマシンで

しかし、上記の行は生産しています

私は何が欠けていますか？

更新： 私のJavaバージョンは

Java Webアプリケーションにjava.lang.OutOfMemoryError：Javaヒープスペース例外を引き起こすスレッドがありますが、try/catchブロックがエラーをキャッチしません。

サンプルコード：

出力：

バックグラウンド：

私は最近このJavaプロジェクトを引き継ぎ、Javaとこのプロジェクトに慣れるつもりです。私はC＃開発者なので、このプロジェクトやJavaにはまだ慣れていません。-Xmx設定を使用してエラーを修正できることはわかっていますが、ログに記録できるように、このエラーをキャッチすることに関心があります。エラーはどのログファイルにも表示されず、出力はEclipseのデバッグモードでコンソールに表示されます。

「mvn install」でオープンソースプロジェクトをコンパイルしていますが、java.lang.OutOfMemoryError: Java heap space. 実行しようとしましjava -Xmx256mたが、無効なコマンドであることを示す java synopsis が出力されました。

を使用してjdk1.5.0_08いますが、なぜこれが起こっているのでしょうか?

ありがとう、

私のアプリケーションは、大量のバイナリ シリアライゼーションと大きなオブジェクトの圧縮を行います。非圧縮のシリアル化されたデータセットは約 14 MB です。圧縮すると約 1.5 MB になります。データセットで serialize メソッドを呼び出すたびに、大きなオブジェクト ヒープのパフォーマンス カウンターが 1 MB 未満から約 90 MB に跳ね上がることがわかりました。また、比較的負荷の高いシステムでは、通常、このシリアライゼーション プロセスが数回発生するしばらく (数日) 実行した後、このシリアライゼーション メソッドが呼び出されると、アプリケーションがメモリ不足の例外をスローすることが知られています。メモリは十分にあるようです。断片化が問題であると推測しています (100% 確信しているとは言えませんが、ほぼ確実です)。

私が考えることができる最も簡単な短期的な修正（短期と長期の両方の答えを探していると思います）は、シリアル化プロセスが完了した直後に GC.Collect を呼び出すことです。私の意見では、これはLOHからオブジェクトをガベージコレクションし、他のオブジェクトを追加する前に行う可能性があります。これにより、断片化をあまり引き起こすことなく、他のオブジェクトがヒープ内の残りのオブジェクトにぴったりと収まるようになります。

このばかげた 90MB の割り当て以外に、失われた LOH を使用するものは他にないと思います。この 90 MB の割り当ても比較的まれです (約 4 時間ごと)。もちろん、そこにはまだ 1.5 MB の配列があり、おそらく他のいくつかの小さなシリアル化されたオブジェクトがあります。

何か案は？

良い反応の結果として更新

これが仕事をする私のコードです。私は実際にこれを変更して、シリアル化中に圧縮して、シリアル化が同時にストリームにシリアル化されるようにしましたが、あまり良い結果は得られませんでした。また、メモリ ストリームを 100 MB に事前割り当てし、同じストリームを 2 回続けて使用しようとしましたが、とにかく LOH は最大 180 MB になりました。Process Explorer を使用して監視しています。それは非常識です。次に UnmanagedMemoryStream のアイデアを試してみようと思います。

そうでない場合は、試してみることをお勧めします。この正確なコードである必要はありません。大規模なデータセットをシリアル化するだけで、驚くべき結果が得られます (私のものには、約 15 のテーブルがあり、文字列と列がたくさんあります)。

UnmanagedMemoryStream でバイナリ シリアル化を試行した後に更新する

UnmanagedMemoryStream にシリアル化しても、LOH は同じサイズにジャンプします。私が何をしても、BinaryFormatter を呼び出してこの大きなオブジェクトをシリアル化すると、LOH が使用されるようです。事前割り当てに関しては、あまり役に立たないようです。100MBを事前に割り当ててからシリアライズすると、170MBが使用されます。これがそのコードです。上記のコードよりもさらに簡単

真ん中の GC.Collect() は、LOH パフォーマンス カウンターを更新するためだけのものです。正しい 100 MB が割り当てられることがわかります。しかし、シリアライズを呼び出すと、すでに割り当てられている 100 の上にそれが追加されているように見えることに気付くでしょう。

2M レコードを含む DB の PostgreSQL で Criteria.scroll() を実行しています。メモリが増え続け、最終的に OutOfMemoryException が生成されます。これを修正する方法についてアドバイスをお願いします。

Postgresql DB バージョン: 8.4 使用する Postgresql ドライバー: postgresql-8.4-701.jdbc4.jar

PostgreSQL の Hibernate scroll() に関する既知の問題はありますか?

ガイダンス/提案に感謝します。

最近、アプリケーションで奇妙な問題が発生しました。

アプリケーションのWPFウィンドウにwin32ウィンドウがあり、WPFウィンドウのサイズを変更すると、問題が発生しました。

スタックトレース：

また、私はいくつかの関連リンクを見つけました：

relatedA

relatedB

1. この問題を回避または処理する方法はありますか？

2. 本当の問題を見つける方法は？

3. コールスタックから、問題の原因が.NET Frameworkであると判断できますか？

回答やコメントありがとうございます！