パッケージ内のすべての単体テストをロードすると、makeタスクはjava.lang.OutOfMemoryError：Javaヒープ・スペース・エラーをスローします。パッケージ内のすべてのテストを実行すると、JUnit java.lang.OutOfMemoryError
各サブパッケージですべてのテストを実行すると、すべてのテストがロードされて正常に完了します。親パッケージですべてのテストを実行して、OOMエラーが発生した場合にのみ発生します。
この問題は、VMパラメータを微調整することで解決する必要はないと思います。最大のヒープとパーマサイズを増やしてみましたが、問題は解決しませんでした。
これは、さまざまなパッケージのローディングテスト間でガベージコレクションに問題があると思われるか、あまりにも熱心なクラスローディングが進行中であると考えています。
これらの問題を処理できるJUnit設定がありますか、テストケースでコードを変更または追加することで解決しなければならない問題はありますか？
CPUは空き時間があるか空きメモリが少ないときに実行されます。テストがクラッシュした場合、どこかでメモリリークが発生する可能性があります。 （はい、それもjavaに存在します）
循環参照と静的なクラス/変数があります。メモリリークの一般的な原因はIIRCです。 jconsoleも見てください。
nullには、tearDown()のテストクラスのすべてのフィールドを設定する必要があります。
なぜなら、JUnitはテストごとに1つのテストクラスのインスタンスをインスタンス化するからです。。それは、テストの結果（成功、失敗、スタックトレース）を保存するために、そのインスタンスを周りに保持します。したがって、フィールドを使用すると、それらは保持され、メモリ不足になります。
クール、まずこの修正プログラムをテストします。 –
残念ながら、これは問題を解決しませんでした。 tearDown（）はすべてのクラスがロードされた後に呼び出され、テストが実行され始めませんか？テストが実行を開始する前に、私が見ているOOMエラーがMakeタスク中に発生しています。 –
いいえ、個々のテストの後にtearDownが呼び出されます。しかし、私は "Makeタスク"を見逃していました。あなたは何の話をしていますか？あなたはAntを使っていますか？あるいはGNU Make？ –
私はTestNGを使用して同様の問題を経験し、コンソールに生成していたログ情報の量をトレースしました。これを減らしてしまえば、メモリに問題がなければテストスイートを走らせることができました。
JUnitとmavenでテストを実行しているのと同じ問題が発生しました。ログレベルがDEBUGにあり、OOMエラーを作成していましたが、ERRORに切り替えた後に問題が解決しました。 – Rich
テストクラスの静的な統計やテストクラスの静的な統計では、大量のメモリを消費していませんか？ – bmargulies
実際にVMパラメータを微調整しましたか？それらがjava.lang.Runtimeのメソッドで正しく設定されていることを確認してください。 – Bozho
静的なメモリ消費についてはわかりませんが、間違いなくそれを調べます。 VMパラメータに関しては、 -Xmx512m -XX：PermSize = 128m -XX：MaxPermSize = 512m ですが、それらを増やしてもOOMエラーを解決できませんでした。 –