JavaのOutOfMemoryError発生時の対処について

JavaでOutOfMemoryが発生した時の対応策を教えていただきたいです。

処理内容は以下のような形です。コマンドの実行結果は場合によってはとても多くなる事があるのはわかっているのですが、出来ればListに詰めた後で後続処理を実行したいのです。このような場合の対応策としてはどのような方法がありますでしょうか？

JavaVMのチューニングとかは正直調べても中々すぐには理解できずどうするのが正解なのか分かりません。コード上で対応できるのが一番なのですが、、、

どうぞよろしくお願い致します。

処理内容（色々省略してますがこんな感じです）

lang
1List<String> testList = new ArrayList<>();
2Process process = Runtime.getRuntime().exec(cmd);
3BufferedReader br = new BufferedReader(new InputStreamReader(process.getInputStream(), "utf-8"));
4br.lines().forEach(line -> {
5    testList.add(line);
6});

エラー内容

lang
1java.lang.OutOfMemoryError: Java heap space
2	at java.util.Arrays.copyOf(Arrays.java:3181) ~[na:1.8.0_25]
3	at java.util.ArrayList.grow(ArrayList.java:261) ~[na:1.8.0_25]
4	at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:235) ~[na:1.8.0_25]
5	at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:227) ~[na:1.8.0_25]
6	at java.util.ArrayList.add(ArrayList.java:458) ~[na:1.8.0_25]

行動規範の内容に同意します

回答4件

出来ればListに詰めた後で後続処理を実行したい

なぜですか？そこに本質的な理由がありますか？

あるのであれば、想定される最大の入力サイズから計算して必要なメモリ量を確保するしかないです。
本質的な理由はなく、気分の問題であるなら、そのような気分でアルゴリズムを選択するのが、技術者としてあるべき姿ではないと思います。
必要に応じて、適切なアルゴリズムを選択できることが、技術者としてあるべき姿であると思います。

なぜ、Listに詰めた後で後続処理を実行したいのか、その理由を説明してください。

投稿2015/04/27 20:33

chokojori

総合スコア973

kidss

2015/04/28 04:42

言葉足らずでしたがListに詰めないで出来るならそうしてます。ヒープサイズを大きくする以外で方法があるのか知りたかったのです。回答ありがとうございました。

chokojori

2015/04/28 04:54

Listに詰めるのではなく、ストリーム的に処理すべきかと思います。入力ファイルの大きさが一定サイズ以下であることが確実であり、かつ、アプリケーションのために用意できるメモリの範囲内に収まるのであれば、Listに詰めても良いですが。実際の処理の内容が、Listに詰めてあることによって、処理しやすくなるということがあるのですか？

kidss

2015/04/29 15:51

すみません、返信遅くなりました。また言葉足らずでした。詳細は省きますが、1行づつ処理できるタイプのデータではなく複数行でひとつのデータとして扱わなければいけないので、ストリーム的に処理できないのです。メモリ管理はまだ勉強足らずですが、ヒープサイズを大きくしたりといくつか試してみたのですが、GC overhead limit exceeded のエラーも見られました。Listのコピーというよりも、そもそもBufferedReaderで読み込むサイズが大きすぎるのを何とかしないといけないような気がしています。

chokojori

2015/04/29 19:15

> 1行づつ処理できるタイプのデータではなく複数行でひとつのデータとして扱わなければいけないので、ストリーム的に処理できないのです。どんな処理なんだろう？たとえば全体を何かのキーでソートするとか？だとしても、何らか方法はあると思います。ストリーム的に処理できないと思い込んでいるだけではないでしょうか。1パスで処理するのではなく、何段階かのパスに分けて段階的に処理する等、適切なアルゴリズムがあると思います。 > GC overhead limit exceeded のエラーも見られました。このエラーは、CPU時間のほとんどがGCに使われている場合に発生します。このような現象が起きるというのは、アルゴリズムの選択が不適切である場合がほとんどであると思います。 > そもそもBufferedReaderで読み込むサイズが大きすぎるのを何とかしないといけないようなそんなことがあるのかな...そんなことがあるとは思えないんですけどね。

kidss

2015/04/30 08:00

BufferedReaderの部分は間違ってましたね。調べてみたんですが、一度に全部読み込んでる訳じゃなく、バッファサイズ分読み込んでるので、メモリ消費にはあまり影響がないという考え方であってるでしょうか？ GC overhead limit exceeded については調べてみると次の2点の場合に発生するということがわかりました。・総時間の98%以上がGCに費やされている・改修されたヒープが2%未満そしてGCについては次の通り・参照のないオブジェクトがGCの対象となる・GCのタイミングはJVMが自動で行う（ヒープが残り少ない等）以上の点を鑑みて大きいサイズのListでメモリが食い尽くされてるからGCでもメモリが解放されないということでしょうか。今ヒープの監視とか解析も調べてますので合わせて確認できたらなと思います。アルゴリズムに関しては、おっしゃる通りまだ見直す点はありますので、色々試してみたいと思います。

chokojori

2015/04/30 21:12

巨大なListがあるとき、Listに入っているオブジェクトは当然ながら、GCによって解放されません。GCは、どこからも参照されていないオブジェクトを解放するものですからね。大量のオブジェクトが生成されていて、それがもっぱらListに入っている。そして、ヒープが不足している。ということになりますと、頻繁にGCが発生する一方で、結局解放されるオブジェクトはない、ということになりますので、GC overhead limit exceededになりますね。こういう場合は、机上で、メモリを使わないようにするのはどうすれば良いか...を考えるべきです。そもそもListに大量のオブジェクトを入れることは良いことではないんです。たとえばデータベースにデータを格納するとか、中間ファイルを作るとか、巨大なファイルを小さなファイルに分割して処理した結果をマージするとか、いろいろ方法はあります。Listに大量のオブジェクトを入れることがどうして必要なのか。そこが結局は焦点です。

行動規範の内容に同意します

こんな工夫をしている例を見つけました。

Javaで大量データをメモリに展開するテクニックの考察 http://symfoware.blog68.fc2.com/blog-entry-1012.html

...
パターン Listに入った個数
通常 476
シリアライズ 4616
シリアライズ + zip 16573
...

投稿2015/04/29 21:48

katoy

総合スコア22328

kidss

2015/04/30 07:29

arguisさんのデータ圧縮案で調べてたらこのページを見つけました。これだったら大分メモリ消費変わりますよね。ただ、パフォーマンスの部分も気になるので一度計測して確認してみたいと思います。ありがとうございます。

行動規範の内容に同意します

ベストアンサー

注意：
※ここから先の内容は、各java開発者の意見が分かれる可能性があります。あくまで一個人の意見としてご覧いただけますと幸いです。僕も日々精進しております。
また参考サイトの情報も合わせて確認の上、他者の見解を仰ぎつつ、oracle公式のガイドドキュメントの確認をするなどしていただくことをお勧めします。

見解：

今回のような事例の場合ですと、まず、addし続けた結果、growが一定回数ごとに起きていますね。
またそれとは別にデータの蓄積が積み重なり、heap領域を超えてしまうこと（ヒープメモリが不足）から発生していると読めそうです。
（表示上は単純に起きるってわかるような感じなので、ここまで単純とは限らないですが）

簡易事例紹介：
DBデータで１００万件相当のデータを一度に扱うような場合があり、設計、コード、実行の結果
OutOfMemoryErrorがでたことがあります。
当時は、使用VMメモリ量や、heapサイズの調整、List初期サイズの調整と、
処理中の定期出力を行うなどをして対処をしました。
このときは、緊急性と重要性の確認、扱うデータの特殊性、システムでのデータの扱い、逐次処理であった点を鑑みての判断だったかと思います。

事象が起きた場合と今後：
扱う対象によって、他者もしくは開発アプリ自身の不具合であったり、
サーバー環境の運用上(java系のサーバー利用）で発生する場合であったりすることがあります。

その時々の状況に対してどのような手段をとるかはまちまちであったりするので、
設定の問題なのか、アプリの問題なのか、運用上の問題なのかなど考えることになります。

対策の把握も大事ですが、少なくともjavaVMのメモリ管理の仕組みについてはある程度把握しておくことが肝要ではないでしょうか。

もちろん事象が起きないように設計、定期的なコードレビューをするのは大事ですが、
推測や経験での限界もあるとは思いますので、大量データを扱うなどの規模の大きい場合は
実データを含んだ検証、調査もなるべく早めに合わせて行うことを推奨とします。
最近では、アプリ側の問題が起きないようなコーディングができるようにもなりましたね。
（eclipseではFindBugs とか）
また、事象が起きてしまった場合は、よほどの緊急性、重要性ではない限りは早計な対策の前に、
プロファイルでの事象チェックと原因の切り分け、分析調査は行うようにするなどをしてみてはいかがでしょうか。

参考情報：
参考までに僕も学習させていただいたサイトで情報は古いですが、２つほど紹介します。

ちょっと調べたら事例つきで載せているサイトもありましたので紹介します。

投稿2015/04/27 18:11