FaqNetBeansAndOOMEJa

Netbeans IDE でメモリが足りなくなった (OutOfMemoryError が投げられた) 場合どうしたらいいでしょうか?

普通は、NetBeans IDE では OutOfMemoryError には二つの理由があります。

  • アプリケーションがほんとうにより多くのメモリを必要とし、カスタマイズをしなければならない場合。Java ヒープの大きさのカスタマイズは JVM のヒープサイズはどのように設定しますか? に説明されています。恒久生成エリアの大きさは調整すべきことがあります。
    「注意」64 ビット JVM は一般に 32 ビット版よりより多くのメモリを必要としますので、このような場合は既定の構成は小さすぎるかも知れません。
  • 修正が必要なメモリ漏れの問題が存在する場合。このような問題はしばしば修正が困難ですので、良いバグ報告は速やかな修正の可能性を高めるために常に有用です。

バグ報告の提出に関する推奨事項は How to Write a Good Bug Report に纏められていますが、この件に関してはいくつかの追加手順が役に立ちます。

  • 問題を再現できる詳細な記述を書くことは、問題を解析することを容易にする、最良の方法です。
  • netbeans.conf の独自変更があれば、それにも言及してください。メモリ管理に関するものであれば特に。
  • IDE に追加インストールしたモジュールの情報も重要かも知れません (var/log/messages.log に保存された IDE ログを添付すれば十分です)。
  • ヒープダンプは、メモリ漏れのほとんどの事例において、開発者にとって最良の情報源です。
  • PERFORMANCE キーワードをバグに追加すると、そのバグへの注目度が上がります。

ダンプの生成

漏れを再現する手順を見つけることが困難であることはよくあります。 漏れのいくつかは大きくなく、Java ヒープ上にだんだんとライブオブジェクトをため込んで少しずつパフォーマンスを低下させ、最終的に OOME を起こします。 このような場合は、事後解析で使用できる Java ヒープのダンプを生成すると役に立つかもしれません。 NetBeans の開発者はこのようなダンプを処理してどのデータ構造が問題を起こしているか見つけることが出来ますし、これが問題を修正するために必要な最も重要な情報であることがしばしばあります。

JVM メモリダンパ

Alan Bateman の Heap dumps are back with a vengeance! ブログエントリは、 解析用の Java ヒープのダンプを生成する方法の概要を示しています。 Java SE 6 や最近の更新版の Java SE 5 (1.5.0_07 版以降) では、netbeans.conf ファイルに -J-XX:+HeapDumpOnOutOfMemoryError フラグを追加することで (詳細は FaqNetbeansConfJa 参照)、OOME が投げられたときに自動的にヒープダンプを生成することが可能です。 また、このフラグは -J-XX:HeapDumpPath=/path/to/dumps と一緒に使用して、ダンプを生成する場所を指定できます。 ダンプを取得する別な方法として、jmap ツールを使用して随時ダンプを生成するというのもあります。


Trouble-Shooting and Diagnostic Guide for Java SE 5 や、より新しい JavaSE 6 performance documentation はメモリ漏れやメモリ内容のダンプを生成するために使用できるツールに関する有用な情報を含んでいます。 Slides は JavaONE2005 の OutOfMemoryError に関する BOF プレゼンテーションからのものです。

INSANE ツール

さらに別のメモリダンプを生成する可能性として INSANE ツールがあります。 これは Java 1.4.2 以降で動作し、ダンプの生成に二つの方法を提供します。 メモリツールバーにボタンがあり、また別の IDE インスタンスに --dumpfile オプションを渡して起動することでダンプを引き起こすことも出来ます。 残念なことに、期待される結果を生成するためには、Java ヒープにある程度の空きが必要です。

様々な種類のメモリ漏れ

Java ヒープ空間。 もっとも一般的な種類です。 これは、しばしばコード内の問題を示唆し、ヒープダンプやヒープに置かれたオブジェクトの度数分布図が問題の根源を見つけるのに役に立ちます。

恒久生成 は特殊な領域で、確保されたオブジェクトが置かれます。 クラスオブジェクトやメソッドオブジェクトのような、VM 自身のリフレクティブを保持するのに使用されます。 通常、NetBeans の最大許容量 (etc/netbeans.conf ファイル内の -XX:MaxPermSize オプションで指定された 96MB) は 32 ビット VM では十分なはずです。 64 ビット VM が使用されるのであれば、その領域の大きさを増やす必要があるかもしれません (5.0 版の後 permgen 領域の最大量は 160MB に増やされましたので、64 ビット VM でも問題なく使えるでしょう)。

しかしながら、それが完全にふさがってしまうことも、ままあります。 しばしばクラスローダーに関する問題で、メモリから解放されず、あまりにも多くのクラスが一つの JVM にロードされたりです。 例えば、Ant のタスクが、それぞれが新規プロセスとして実行されれば問題なく動くのに、 同じ JVM 内で複数実行すると失敗するといったものです。 頻繁なモジュールの有効化と無効化 (インストールとアンインストール) もこれを引き起こします。 "java.lang.OutOfMemoryError: PermGen space" 例外を修正するには (how to fix "java.lang.OutOfMemoryError: PermGen space" exception) への処理は 見捨てられたクラスローダーと、同じクラス群を持つクラスローダー (orphaned classloaders and classloaders with the same sets of classes) を見つけることを含みます。(the dreaded "java.lang.OutOfMemoryError: PermGen space" exceptionJavaOne2007 conference slides にさらに情報があります)。

IDE 内の出力の処理 (例えばコンパイル中やプロセスの実行中) はメモリ領域のマッピングを使用して大きな出力の表示を可能にします。 古めの NetBeans や Apple の古い JVM で、この様なところで OOME が報告されたことがあります。


  バージョン: NetBeans 4.0 以降
  プラットフォーム: すべて

---

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo