- 私の知る限りでは、ヒープ領域はインスタンス変数のみによって占有されています。これが正しい場合、オブジェクトの作成時にインスタンス変数用のスペースが割り当てられるため、しばらくの間正常に実行した後にこのエラーが発生した理由。
つまり、一定期間にわたってアプリケーション内にさらに多くのオブジェクトを作成し続けることになります。新しいオブジェクトはヒープメモリに格納され、それがヒープメモリが増加する理由です。
ヒープにはインスタンス変数だけが含まれているわけではありません。それはすべての非プリミティブデータ型(オブジェクト)を格納します。これらのオブジェクトの寿命は、短い(メソッドブロック)または長い(オブジェクトがアプリケーションで参照されるまで)の場合があります。
- ヒープ領域を増やす方法はありますか?
はい。このオラクルの記事をご覧ください詳細についてはをご覧ください。
ヒープサイズを設定するための2つのパラメーターがあります。
-Xms:、初期および最小ヒープサイズを設定します
-Xmx:、最大ヒープサイズを設定します
- ヒープ領域を少なくするために、プログラムにどのような変更を加える必要がありますか?
アプリケーションによって異なります。
アプリケーション要件に従って最大ヒープメモリを設定する
アプリケーションでメモリリークを発生させない
アプリケーションでメモリリークが見つかった場合は、MAT、Visual VM、jconsoleなどのプロファイリングツールを使用して根本的な原因を見つけます。根本的な原因を見つけたら、リークを修正します。
オラクルの記事からの重要な注意事項
原因:詳細メッセージのJavaヒープ領域は、オブジェクトをJavaヒープに割り当てることができなかったことを示しています。このエラーは、必ずしもメモリリークを意味しているわけではありません。
考えられる理由:
- 不適切な構成(十分なメモリを割り当てていない)
- アプリケーションが誤ってオブジェクトへの参照を保持しているため、オブジェクトがガベージコレクションされるのを防ぎます
- ファイナライザを過度に使用するアプリケーション。クラスにfinalizeメソッドがある場合、そのタイプのオブジェクトには、ガベージコレクション時にスペースが再利用されません。ファイナライザスレッドが、ファイナライゼーションキューに追いつくことができない場合、Javaヒープがいっぱいになり、このタイプのOutOfMemoryError例外がスローされます。
別のメモでは、より良いガベージコレクションアルゴリズム(CMSまたはG1GC)を使用してください
G1GCを理解するためにこの質問を見てください