メモリー・リークの一般的な兆候の1つは、java.lang.OutOfMemoryErrorエラーです。このエラーは、ガベージ・コレクタによって新しいオブジェクトを格納するための空間を確保することも、ヒープをこれ以上拡張することもできないことを示します。また、このエラーは、Javaクラスのロードをサポートするための十分なネイティブ・メモリーがないときにスローされる場合もあります。ガベージ・コレクションの実行に過剰な時間が消費され、メモリーがほとんど解放されていない場合、まれにこのエラーがスローされることがあります。

java.lang.OutOfMemoryErrorエラーは、ネイティブ割当てを満たすことができないとき(たとえば、スワップ空間が少ない場合)に、ネイティブ・ライブラリ・コードによってスローされることもあります。

java.lang.OutOfMemoryErrorエラーがスローされると、スタック・トレースが出力されます。

java.lang.OutOfMemoryErrorエラーを診断する最初のステップは、その原因を突き止めることです。スローされた理由が、Javaヒープがいっぱいであるからなのか、それともネイティブ・ヒープがいっぱいであるからなのかを調べます。原因の特定に役立つよう、詳細メッセージが例外テキストに追加されます(次の例を参照):

詳細メッセージ: Javaヒープ領域

原因: 詳細メッセージ「Javaヒープ領域」は、Javaヒープ内でオブジェクトを割り当てることができなかったことを示しています。このエラーは、必ずしもメモリー・リークを意味しません。この問題は、指定されたヒープ・サイズ(指定されていない場合はデフォルト・サイズ)がアプリケーションにとって十分でないという、単純な構成の問題である可能性があります。Javaヒープ領域の初期および最大サイズは、–Xmsおよび–Xmxオプションを使用して構成できます。

それ以外の場合、特に長期にわたって稼働するアプリケーションでは、このメッセージはアプリケーションが誤ってオブジェクトへの参照を保持しているため、オブジェクトのガベージ・コレクションができないことを示している可能性があります。これは、Java言語ではメモリー・リークに相当します。

ノート:

アプリケーションによって呼び出されたAPIが誤ってオブジェクト参照を保持している可能性もあります。

このエラーのもう1つの潜在的な原因は、ファイナライザを過度に使用するアプリケーションで発生します。クラスにfinalizeメソッドがある場合、そのタイプのオブジェクトの空間はガベージ・コレクション時に再利用されません。かわりに、ガベージ・コレクション後にファイナライズ用のキューにオブジェクトが入れられ、後でファイナライズが実行されます。JavaランタイムのOracle実装では、ファイナライザはファイナライズ・キューを提供するデーモン・スレッドによって実行されます。スレッドがファイナライズ・キューを処理しきれなかった場合は、Javaヒープがいっぱいになる可能性があり、この種類のjava.lang.OutOfMemoryErrorエラーがスローされます。この状況を発生させるシナリオの1つは、アプリケーションが優先度の高いスレッドを作成しているため、ファイナライザ・スレッドがファイナライズ・キューを処理する速度よりキューの増加速度の方が速くなっている場合です。

処置: Javaヒープ・サイズを増やしてみてください。ファイナライズが保留されているオブジェクトのモニター方法については、「ファイナライズを保留中のオブジェクトのモニター」を参照してください。ファイナライズの検出とファイナライズからの移行の詳細は、『Java Platform, Standard Edition HotSpot仮想マシン・ガベージ・コレクション・チューニング・ガイド』の「ファイナライズと弱参照、ソフト参照およびファントム参照」を参照してください。

詳細メッセージ: GCオーバーヘッド制限を超えました

原因: 詳細メッセージ「GCオーバーヘッド制限を超えました」は、ガベージ・コレクタ(GC)がほとんどの時間、実行されているため、Javaアプリケーションの処理がほとんど進んでいないことを示しています。ガベージ・コレクション後、Javaアプリケーションでガベージ・コレクションの実行に約98%を超える時間が費やされ、ヒープのリカバリが2%未満であり、その状態が直近5回(コンパイル時間定数)の連続するガベージ・コレクションで続いている場合に、java.lang.OutOfMemoryErrorエラーがスローされます。このエラーは通常、Javaヒープに新しい割当て用の空き領域がわずかしか残っておらず、ライブ・データの容量をほとんど格納できないためにスローされます。

処置: ヒープ・サイズを増やしてください。「GCオーバーヘッド制限を超えました」のjava.lang.OutOfMemoryErrorエラーは、コマンド行フラグ-XX:-UseGCOverheadLimitを使用すると無効にできます。

詳細メッセージ: 要求された配列サイズがVM制限を超えています

原因: リクエストされた配列サイズはVMの制限を超えていますという詳細メッセージは、使用可能なヒープ・サイズに関係なく、アプリケーション(またはアプリケーションが使用するAPI)がVM実装の制限より大きいサイズの配列を割り当てようとしたことを示します。

処置: アプリケーション(またはアプリケーションが使用するAPI)が、VM実装の制限より小さいサイズの配列を割り当てることを確認してください

詳細メッセージ: メタスペース

原因: Javaクラス・メタデータ(Javaクラスの仮想マシン内部表現)がネイティブ・メモリー(ここでは、メタスペースと呼ばれる)に割り当てられています。クラス・メタデータのメタスペースが枯渇すると、詳細メッセージ「メタスペース」とともにjava.lang.OutOfMemoryErrorエラーがスローされます。クラス・メタデータに使用できるメタスペース容量は、コマンド行に指定するパラメータMaxMetaSpaceSizeにより制限されます。クラス・メタデータに必要なネイティブ・メモリー容量がMaxMetaSpaceSizeを超過すると、詳細メッセージ「メタスペース」とともにjava.lang.OutOfMemoryErrorエラーがスローされます。

処置: コマンド行でMaxMetaSpaceSizeが指定されている場合は、その値を増やしてください。メタスペースは、Javaヒープと同じアドレス空間から割り当てられます。Javaヒープのサイズを減らすと、メタスペースに使用できる領域が増えます。このトレードオフが役立つのは、Javaヒープに余分な空き領域がある場合のみです。次に示すスワップ領域の不足に関する詳細メッセージの「処置」を参照してください。

詳細メッセージ: reasonのためにsizeバイトを要求します。スワップ領域が不足していますか。

原因: 詳細メッセージ「reasonのためにsizeバイトを要求します。スワップ領域が不足していますか。」は、java.lang.OutOfMemoryErrorエラーであるように見えます。しかし、ネイティブ・ヒープからの割当てが失敗し、ネイティブ・ヒープが枯渇寸前になっている可能性があるときに、Javaはこの見かけ上のエラーを報告します。このメッセージは、失敗した要求のサイズ(バイト数)とメモリー要求の理由を示しています。通常、reasonは割当ての失敗を報告するソース・モジュールの名前になりますが、場合によっては実際の理由を示すこともあります。

処置: このエラーがスローされると、Java VM (JVM)は致命的エラー処理メカニズムを呼び出します。クラッシュ発生時のスレッド、プロセス、およびシステムに関する有用な情報を含む、致命的エラー・ログ・ファイルを生成します。ネイティブ・ヒープ不足の場合は、ログ内のヒープ・メモリーとメモリー・マップの情報が役立つ可能性があります。「致命的エラー・ログ」を参照してください。

オペレーティング・システムのトラブルシューティング・ユーティリティを使用して、問題をより詳しく診断する必要がある場合があります。「オペレーティング・システムのネイティブ・ツール」を参照してください。

詳細メッセージ: 圧縮クラス領域

原因: 64ビット・プラットフォーム上で、クラス・メタデータへのポインタが32ビットのオフセットで表現されている可能性があります(UseCompressedOopsを使用)。これはコマンド行フラグUseCompressedClassPointersで制御されます(デフォルトではtrue)。UseCompressedClassPointersがtrueの場合、クラス・メタデータに使用できる領域量はCompressedClassSpaceSizeの容量で固定されます。UseCompressedClassPointersに必要な領域がCompressedClassSpaceSizeを超える場合、詳細メッセージ「圧縮クラス領域」とともにjava.lang.OutOfMemoryErrorエラーがスローされます。

処置: CompressedClassSpaceSizeを増やすか、UseCompressedClassPointersをfalseに設定します。

ノート:

CompressedClassSpaceSizeの許容サイズには制限があります。たとえば、-XX:CompressedClassSpaceSize=4gは、許容制限を超えているため、次のようなメッセージが表示されます

CompressedClassSpaceSize of 4294967296 is invalid; must be between 1048576 and 3221225472.

ノート:

クラス・メタデータには複数の種類(–klassメタデータやその他のメタデータ)があります。CompressedClassSpaceSizeによって制限された領域に格納されるのは、klassメタデータのみです。その他のメタデータはメタスペースに格納されます。

詳細メッセージ: reason stack_trace (ネイティブ・メソッド)

原因: この詳細メッセージは、ネイティブ・メソッドで割当て失敗が発生したことを示しています。これと前のメッセージとの違いは、割当ての失敗がJVM自体ではなく、Java Native Interface (JNI)またはネイティブ・メソッドで検出されたことです。

処置: このタイプのjava.lang.OutOfMemoryErrorエラーがスローされた場合は、オペレーティング・システムのネイティブ・ユーティリティを使用して、問題をより詳しく診断する必要がある場合があります。「オペレーティング・システムのネイティブ・ツール」を参照してください。

java.lang.OutOfMemoryErrorエラーは、Javaアプリケーションのメモリー・リークの兆候である可能性があります。また、Javaヒープ、メタスペースまたは圧縮クラス領域のいずれかが、その特定のメモリー・プールに対するアプリケーションのメモリー要件よりも小さいサイズであることを示している可能性もあります。アプリケーションでメモリー・リークが発生していると想定する前に、java.lang.OutOfMemoryErrorエラーが発生しているメモリー・プールのサイズが適切であることを確認します。Javaヒープのサイズは、–Xmxおよび–Xmsコマンド行オプションを使用して設定でき、メタスペースの最大サイズおよび初期サイズは、MaxMetaspaceSizeおよびMetaspaceSizeを使用して構成できます。同様に、圧縮クラス領域のサイズは、CompressedClassSpaceSizeオプションを使用して設定できます。

メモリー・リークは、特に低速のものは検出が非常に困難な場合が多くあります。メモリー・リークは、Javaオブジェクトまたクラスへの参照がアプリケーションにより誤って保持され、ガベージ・コレクションによって解放されない場合に発生します。誤って保持されているこれらのオブジェクトまたはクラスは、時間の経過とともにメモリー内で増大し、最終的にJavaヒープまたはメタスペース全体をいっぱいにしてしまい、頻繁にガベージ・コレクションが発生して、最終的にはプロセスがjava.lang.OutOfMemoryErrorエラーで終了します。

メモリー・リークを検出するには、アプリケーションのライブ・セット(つまり、完全なガベージ・コレクション後に使用されるJavaヒープ領域またはメタスペースの量)をモニターすることが重要です。アプリケーションが安定した状態になり、安定した負荷がかかった後、ライブ・セットが時間の経過とともに増加する場合は、メモリー・リークの強い兆候である可能性があります。アプリケーションのライブ・セットおよびメモリー使用量は、JConsoleおよびJDK Mission Controlを使用してモニターできます。メモリー使用量の情報は、ガベージ・コレクション・ログから抽出することもできます。

エラーの詳細メッセージがネイティブ・ヒープの枯渇を示している場合は、アプリケーションでネイティブ・メモリー・リークが発生している可能性があります。ネイティブ・メモリー・リークを確認するには、pmapやPerfMonなどのネイティブ・ツールを使用し、定期的に収集される出力を比較して、プロセスの新しく割り当てられた、または増大しているメモリー・セクションを判断します。

複数の手法を使用してネイティブ・コードのメモリー・リークを検出し、切り分けることができます。一般に、すべてのプラットフォームに対応できる理想的な解決方法はありません。

ネイティブ・コードを診断するためのいくつかの手法を次に示します。

• すべてのメモリー割当ておよび解放呼出しの追跡

• JNIライブラリのすべてのメモリー割当ての追跡

ファイナライズが保留されているオブジェクトをモニターするための様々なコマンドやオプションが用意されています。

• JConsole管理ツールを使用して、ファイナライズを保留中のオブジェクト数をモニターできます。このツールでは、「サマリー」タブ・ペインのメモリー統計にファイナライズ保留中の数が報告されます。この数は概算ですが、アプリケーションを特徴付け、アプリケーションがファイナライズに大きく依存しているかどうかを理解するのに役立ちます。
• Linuxでは、jmapユーティリティを-finalizerinfoオプションとともに使用することで、ファイナライズを待機しているオブジェクトに関する情報を出力できます。
• アプリケーションで、java.lang.management.MemoryMXBeanクラスのgetObjectPendingFinalizationCountメソッドを使用して、ファイナライズを保留しているオブジェクトのおよその数を報告できます。APIドキュメントへのリンクおよびコード例は、「カスタム診断ツール」に記載されています。コード例を拡張して、ファイナライズ保留中の数の報告を簡単に追加できます。

致命的エラー・ログやクラッシュ・ダンプの情報を使用して、クラッシュをトラブルシューティングします。

ネイティブ・ヒープからの割当てが失敗した直後に、アプリケーションがクラッシュすることがあります。これは、メモリー割当て関数によって返されたエラーをチェックしないネイティブ・コードで発生します。

たとえば、mallocシステム・コールは使用可能なメモリーがない場合にnullを返します。mallocからの戻り値がチェックされない場合、アプリケーションは無効なメモリー位置にアクセスしようとしてクラッシュする可能性があります。状況によっては、このタイプの問題を特定することが難しいことがあります。

しかし、致命的エラー・ログやクラッシュ・ダンプの情報があれば、この問題を十分に診断できる場合もあります。致命的エラー・ログについては、「致命的エラー・ログ」で詳しく説明されています。割当ての失敗によってクラッシュが生じた場合は、割当ての失敗の理由を調べてください。ネイティブ・ヒープに関する他の問題と同様に、システムに十分な容量のスワップ空間が構成されていなかったり、システム上の別のプロセスがすべてのメモリー・リソースを消費していたり、システムのメモリー不足を引き起こすリークがアプリケーション内(またはそこから呼び出されたAPI内)で発生していたりする可能性があります。