修正されたJava SEの問題のトラブルシューティングに時間をかけることを避けるために、最新のJava SEを使用します。多くの場合、Javaランタイムのバグに起因する問題は、最新のアップデート・リリースで修正されています。最新のJava SEバージョンの使用により、いくつかの一般的な既知の問題を回避できます。

トラブルシューティングの関連データを収集可能にするためのJVMオプションやフラグを設定します。

1. コア・ファイルの有効化: Javaがクラッシュした場合、OSがコア・ファイルをディスクに保存できます。コア・ファイルは、アプリケーションのメモリー使用状況の完全なダンプです。通常、コア・ファイルの作成はデフォルトで無効になっています。コア・ファイルの作成を有効にする方法は、システム管理者に問い合せるか、OSのドキュメントを参照してください。

   たとえば、Linuxでは、コア・ファイルがデフォルトで無効になっている場合があります。Linux上のコア・ファイルを有効にするには、通常、アプリケーション・コマンドを起動する前にulimit -c unlimitedを実行するだけで十分です。一部のシステムでは、これらの制限の扱い方が異なる場合があります。

   ノート:

   コア・ファイルは、アプリケーションのメモリー使用状況によっては多くのディスク領域を占有する可能性があります。

   コア・ファイルによって、クラッシュ時のアプリケーションの状態に関する詳細情報が提供されます。これらが必ずしも問題の診断に役立つとはかぎりませんが、必要な場合には非常に重要です。多くの場合、クラッシュを再現することは困難であるため、アプリケーション・コア・ファイルを有効にしておくと、時間を節約でき、貴重な情報を得ることができます。システムが潜在的な領域の要件に対応できるかどうかを決めるのは、担当者および組織次第です。

2. JVMフラグに-XX:+HeapDumpOnOutOfMemoryErrorを追加する: -XX:+HeapDumpOnOutOfMemoryErrorフラグは、アプリケーションでOutOfMemoryErrorが発生した場合に、ディスクにJavaヒープのダンプを保存します。

   ヒープ・ダンプでは、アプリケーションのメモリー使用状況の、JVMによって直接管理される部分に関する情報が提供されます。コア・ファイルと同様にヒープ・ダンプも非常に大きくなる可能性があります。ヒープ・ダンプによって、アプリケーションの一部のみが他と比べて増大しているかどうかを識別できます。増大していると、OutOfMemoryErrorの原因になることがあります。

3. フライトの連続記録を実行する: 連続フライト記録を実行するためにJavaを設定します。

   連続フライト記録によって、JVMイベントのファイルベースの記録が提供されます。これは、問題が発生した場合に使用できる、Javaアプリケーションをモニターするための低オーバーヘッドの手段です。このような記録を設定する方法は、「フライト記録の生成」を参照してください。

4. -Xlog:gc*コマンドライン・オプションの追加: -Xlog:gcオプションを使用すると、ガベージ・コレクションに関する詳細情報が出力されます。これは、アプリケーションのパフォーマンスおよびメモリー管理に関する問題の診断に役立ちます。

   このオプションやJVM統合ロギング・フレームワークで出力できる他の情報の詳細は、javaコマンド・ドキュメントの「JVM統合ロギング・フレームワークを使用したロギングの有効化」を参照してください。

   ノート:

   個別のガベージ・コレクション・ログ・ファイルを作成すると、読みやすくなります。これはクラッシュまたはアプリケーション再起動の後も保存されます。ログ・ローテーションを設定することで、保存される情報の量と期間を管理できます。この方法は、javaコマンド・ドキュメントの「-Xlogの出力」を参照してください。

5. JavaバージョンおよびJVMフラグを出力する: Oracleサポートやフォーラムでは、アプリケーションで使用されてる正確なJavaバージョンとJVMフラグを確認されます。

   コマンドラインでjava -versionを実行して、システムのデフォルトのJavaバージョンを取得します。アプリケーションがスクリプトによって起動される場合は、スクリプトおよび関連する構成ファイルを調べて、アプリケーションでデフォルトのJavaバージョン以外が使用されているかどうかを確認します。または、アプリケーションのJVM引数に-XX:PrintFlagsFinalおよび-showversionを追加し、アプリケーションを再起動して、アプリケーション・ログで結果を確認します。

6. リモート・モニタリング用のJava Management Extensions (JMX)の設定: JMXはJavaアプリケーションをモニターするためのフレームワークです。通常、Mission ControlやVisualVMなどのツールを介して使用されます。アプリケーションがリモート・モニタリングに対応できるようにすることで、アプリケーションまたはそのシステムに直接アクセスできない場合に役立ちます。リモート・アクセスに対してJMXを開くためのオーバーヘッドはありません。これを行うには、アプリケーションのJVMフラグにcom.sun.management.jmxremote.port=portNumを追加し、アプリケーションを再起動します。詳細は、『Java Platform, Standard Editionモニタリングおよび管理ガイド』の「JMXテクノロジを使用するモニタリングと管理」を参照してください。

ロギング・フレームワークの使用は、後のデバッグを可能にするための良い方法です。

特定のモジュールで問題が発生する場合は、そのモジュールのロギングを有効にできる必要があります。また、情報、デバッグ、トレースなどの異なるロギング・レベルの指定も役立ちます。Javaロギングの詳細は、Javaロギングの概要に関する項を参照してください。

アプリケーションで問題が発生し、デバッグ・プロセスを開始しようとする場合、問題に関してデータを収集することが最初のステップです。これは非常に重要です。アプリケーションやシステムを再起動するとファイルが移動または削除されるためです。

• アプリケーションがクラッシュした場合は、次のファイルを収集します:
  • コア・ファイル
  • 致命的エラー・ログ・ファイル: 「致命的エラー・ログの場所」を参照してください
  • Javaおよびアプリケーションのログ
  • -XX:+HeapDumpOnOutOfMemoryErrorのJavaヒープ・ダンプ
  • フライト記録: 問題によってアプリケーションが終了しなかった場合は、連続記録をダンプします
• アプリケーションが応答しなくなった場合は、次のファイルを収集します:
  • スタック・トレース: システムを再起動する前に、jcmd <pid> Thread.printを使用していくつかのスタック・トレースを取得します
  • フライト記録のダンプ
  • 強制コア・ファイル: 強制的にコア・ファイルを作成する方法については、オペレーティング・システムのドキュメントを参照してください