jconsole は、JMX に準拠した監視ツールです。Java 仮想マシンの広範な JMX 機能を使用して、Java プラットフォームで実行されるアプリケーションのパフォーマンスとリソース消費に関する情報を提供します。
jconsole 実行可能ファイルは、JDK_HOME/bin
にあります。ここで JDK_HOME は、JDK
がインストールされているディレクトリです。このディレクトリがシステムのパスにあれば、コマンド (シェル) プロンプトで jconsole
と入力するだけで、このツールを起動できます。それ以外の場合は、実行ファイルへのフルパスを入力する必要があります。
jconsole を使用して、ローカルアプリケーション (jconsole
と同じシステム上で動作するアプリケーション) とリモートアプリケーション (他のシステム上で動作するアプリケーション) の両方を監視できます。
注:jconsole
を使って、ローカルのアプリケーションを監視するのは、開発やプロトタイプ作成には便利ですが、jconsole
自体がかなりのシステムリソースを消費するため、実稼働環境で使用することはお勧めしません。jconsole
アプリケーションを監視対象のプラットフォームから切り離すために、リモート監視をお勧めします。
jconsole コマンドの構文の詳細な説明については、「jconsole - Java
監視および管理コンソール」を参照してください。
ローカルアプリケーションを監視するためには、jconsole と同じユーザ ID
で実行する必要があります。ローカル監視のために jconsole を起動するコマンド構文は次のとおりです。
jconsole [processID]
ここで、processID は、アプリケーションのプロセス ID (PID) です。アプリケーションの PID を調べるには、次の手順を実行します。
ps コマンドを使用して、java の PID
を見つけます。jps コマンド行ユーティリティを使って、PID を調べることもできます。
たとえば、Notepad アプリケーションのプロセス ID が 2956 の場合、jconsole を次のように起動します。
jconsole 2956
jconsole
とアプリケーションは同じユーザ名で実行する必要があります。管理および監視システムは、オペレーティングシステムのファイルアクセス権を使用します。
プロセス ID を指定しない場合、jconsole は自動的にすべてのローカルの Java アプリケーションを検出して、監視したいアプリケーションを選択できるダイアログボックスを表示します (次のセクションを参照)。
詳細は、「ローカルの JMX 監視および管理」を参照してください。
リモート監視のために jconsole を起動するには、次のコマンドを使用します。
jconsole [hostName:portNum]
ここで、hostName は、アプリケーションを実行するシステムの名前で、portNum は、JVM を起動して JMX エージェントを有効にしたときに指定したポート番号です。詳細は、「リ モートの JMX 監視および管理」を参照してください。
ホスト名 / ポート番号の組み合わせを指定しない場合、jconsole は接続ダイアログボックス (次のセクションを参照) を表示し、ホスト名とポート番号を入力できるようにします。
jconsole を、接続する JMX エージェントを指定する引数で起動した場合、指定した JVM
の監視を自動的に開始します。「接続」 | 「新しい接続」を選択し、必要な情報を入力して、いつでも別のホストに接続できます。
jconsole
を起動するときに何も引数を指定しないと、最初に接続ダイアログボックスが表示されます。このダイアログボックスには、次の 3 つのタブがあります。
「Local」タブには、jconsole と同じユーザー ID で起動された、ローカルシステム上で実行されている JVM とそのプロセス ID およびクラス / 引数情報がリストされます。監視したいアプリケーションを選択して、「Connect」をクリックします。
リモートの JVM を監視するには、次の情報を入力します。
JMX エージェントのポート番号の設定方法については、「JMX 管理エージェントを有効にする」を参照してください。ユーザ名およびパスワードについては、「パスワードおよびアクセスファイルの使用」を参照してくださ い。
JVM が動作する jconsole を監視するには、ホストのローカルホストとポートゼロ (0) を使用して、「Connect」をクリックするだけです。
「Advanced」タブを使って、JMX URL およびユーザ名とパスワードを指定することにより、他の JMX エージェント (MBean サーバ) に接続できます。JMX URL の構文は、javax.management.remote.JMXServiceURL の API ドキュメントに記載されています。
jconsole インタフェースは、6 つのタブで構成されています。
以下のセクションでは、それぞれのタブについて説明します。
「Summary」タブには、スレッド使用率、メモリ使用率、クラスのロードなど、いくつかの重要な監視情報が表示され、さらに JVM およびオペレーティングシステムに関する情報が表示されます。
「Memory」タブには、メモリの消費とメモリプールに関する情報が表示されます。
上の図は、時間に対するヒープメモリとヒープ以外のメモリ、および特定のメモリプールに関する JVM のメモリ使用率を示しています。利用できるメモリプールは、使用される JVM によって異なります。HotSpot JVM の場合、プールは以下のとおりです。
これらのメモリプールの詳細は、「ガベージコレクション」を参照してください。
「Details」領域には、現在のメモリに関するメトリックスがいくつか表示されます。
右下の棒グラフは、メモリプールによって、ヒープおよびヒープ以外のメモリで使用されるメモリを示しています。使用メモリがメモリ使用率のしきい値 を超えると、棒が赤に変わります。メモリ使用率のしきい値は、MemoryMXBean の属性で設定できます。
JVM は、JVM の開始時に作成されるヒープとヒープ以外という 2 種類のメモリを管理します。
ヒープメモリは、JVM がすべてのクラスのインスタンスと配列にメモリを割り当てる実行データ領域です。ヒープは可変サイズの場合と固定サイズの場合があります。ガベージ コレクタは、ヒープメモリをオブジェクトに再利用する自動メモリ管理システムです。
ヒープ以外のメモリには、JVM の内部処理や最適化に必要なメモリと、すべてのスレッド間で共有されるメソッド領域が含まれます。ヒープ以外のメモリには、実行定数プール、フィールドお よびメソッドデータ、メソッドおよびコンストラクタのコードなどのクラス単位の構造が格納されます。メソッド領域は論理的にはヒープの一部分ですが、実装 方法によっては、JVM はこの領域をガベージコレクトしたり、圧縮したりしない場合があります。ヒープと同様に、メソッド領域のサイズは固定の場合と可変の場合があります。メ ソッド領域のメモリは連続的である必要がありません。
メソッド領域の他に、JVM の実装には、ヒープ以外のメモリに属する内部処理または最適化のためのメモリが必要になる場合があります。たとえば、JIT コンパイラには、高いパフォーマンスのために JVM コードから変換されたネイティブマシンコードを格納するためのメモリが必要です。
メモリプールとメモリマネージャは、JVM メモリシステムの重要な部分です。
メモリプールとは、JVM が管理するメモリ領域のことです。JVM には少なくとも 1 つのメモリプールがあり、実行中にメモリプールを作成または削除できます。メモリプールはヒープメモリまたはヒープ以外のメモリに属することができます。
メモリマネージャは、1 つまたは複数のメモリプールを管理します。ガベージコレクタは、メモリマネージャの一種で、アクセスできなくなったオブジェクトが使用していたメモリの再 利用を管理しています。JVM は、1 つ以上のメモリマネージャを持っている場合があります。実行中にメモリマネージャを追加または削除できます。メモリプールは 1 つ以上のメモリマネージャによって管理できます。
ガベージコレクション (GC) は、JVM が参照されていないオブジェクトが占めていたメモリを解放する方法です。アクティブな参照を持つオブジェクトを「生きている」と考え、参照されていない (アクセスできない) オブジェクトを「死んでいる」と考えるのが一般的です。ガベージコレクションは、死んだオブジェクトによって使用されているメモリを解放するプロセスで す。GC によって使用されるアルゴリズムとパラメータがパフォーマンスに劇的な効果をもたらす可能性があります。
HotSpot VM ガベージコレクタは、世代別ガベージコレクションを使用します。世代別の GC は、実際にほとんどのプログラムに見られる次のような考察を利用しています。
このため、世代別の GC は、メモリをいくつかの世代に分け、それぞれにメモリプールを割り当てます。ある世代が割り当てられたメ モリを使用すると、VM はメモリプール上で部分的なガベージコレクション (マイナーコレクションとも呼ばれる) を実行して、死んだオブジェクトによって使用されたメモリを再利用します。この部分的な GC は、通常、フル GC よりもはるかに高速です。
HotSpot VM は、young generation (「nursery」と呼ばれることもある) と old generation という 2 つの世代を定義します。young generation は、1つの「eden 領域」と 2 つの「survivor 領域」で構成されています。VM は最初にすべてのオブジェクトを eden 領域 に割り当て、ほとんどのオブジェクトはそこで死にます。マイナー GC を実行するときに、VM は残りのオブジェクトを eden 領域から survivor 領域の 1 つに移します。VM は、survivor 領域で十分に長く生きられるオブジェクトを old generation の「tenured」領域に移します。tenured generation がいっぱいになると、フル GC を実行します。これは生きているオブジェクトをすべて含むため、はるかに遅くなることがよくあります。permanent generation は、クラスやメソッドオブジェクトなどの仮想マシン自体を反映したデータをすべて保持します。
各世代のデフォルトの配置は、次のようになります。
下記のドキュメントで説明するように、ガベージコレクタがボトルネックになる場合、世代のサイズをカスタマイズすることによって、パフォーマンスを 向上させることができます。jconsole を使用して、パフォーマンスメトリックの感度をガベージコレクタのパラメータに展開します。詳細は、以下を参照してください。
「Threads」タブには、スレッドの使用に関する情報が表示されます。
左下の「Threads」リストには、アクティブなスレッドがすべて表示されます。「Filter」フィールドに文字列を入力すると、 「Threads」リストには、入力した文字列を含む名前のスレッドだけが表示されます。「Threads」リスト内のスレッドの名前をクリックすると、 スレッド名や状態、スタックトレースなど、そのスレッドに関する情報が右に表示されます。
この図は、稼働中のスレッドの数と時間を示しています。次の 3 つのラインが表示されています。
スレッドおよびデーモンスレッドの詳細は、「java.lang.Thread」を 参照してください。
「Classes」タブには、クラスのロードに関する情報が表示されます。
このグラフは、ロードされたクラスの数と時間の関係を示しています。
タブの下の「Details」セクションには、JVM が開始してからロードされたクラスの合計数、現在ロードおよびアンロードされている数が表示されます。
「MBean」タブには、platform MBean server によって登録されているすべての MBean に関する情報が表示されます。
左のツリーは、objectNames で整理したすべての MBean を示しています。ツリーで MBean を選択すると、その属性、操作、通知およびその他の情報が右に表示されます。
属性の値が書き込み可能である場合 (値が青で表示される) は、属性の値を設定できます。「Operations」タブに表示される操作を呼び出すこともできます。
属性値をダブルクリックすることにより、属性の値と時間を表示できます。たとえば、 java.lang.GarbageCollector.Copy MBean の CollectionTime プロパティの値をクリックすると、次のようなグラフが表示されます。
「VM」タブには、JVM に関する情報が表示されます。
情報の内容には次のものが含まれます。