使用可能な診断コマンドは、使用するJVMによって異なります。jcmd <process id/main class> helpを使用すると、使用可能なすべてのオプションが表示されます。

• HotSpotおよびJDKのバージョンIDの出力
  jcmd <process id/main class> VM.version
• VMに設定されているすべてのシステム・プロパティの出力

  数百行の情報が表示される可能性があります。

  jcmd <process id/main class> VM.system_properties

• VMで使用されるすべてのフラグの出力

  フラグを指定していない場合でも、いくつかのデフォルト値(初期ヒープ・サイズや最大ヒープ・サイズなど)が表示されます。

  jcmd <process id/main class> VM.flags

• 稼働時間(秒)の出力

  jcmd <process id/main class> VM.uptime

• クラス・ヒストグラムの作成

  出力結果が冗長になる可能性があるので、出力をファイルにリダイレクトできます。内部クラスとアプリケーション固有のクラスの両方がリストに含まれます。メモリーの消費量が最も多いクラスから降順に表示されます。

  jcmd <process id/main class> GC.class_histogram

• ヒープ・ダンプの作成

  jcmd GC.heap_dump filename=Myheapdump

  これはjmap -dump:file=<file> <pid>を使用する方法と同じですが、推奨ツールはjcmdです。

• ヒープ・ヒストグラムの作成

  jcmd <process id/main class> GC.class_histogram filename=Myheaphistogram

  これはjmap -histo <pid>を使用する方法と同じですが、推奨ツールはjcmdです。

• スタック・トレースのあるすべてのスレッドの出力

  jcmd <process id/main class> Thread.print

jcmdは、実行中のJava仮想マシン(JVM)またはJavaアプリケーションに診断コマンド要求を送信する場合に使用します。

• フライト・レコーダで記録を開始します。

  たとえば、識別子が7060の実行中Javaプロセスで2分間の記録を開始し、それをC:\TEMP\myrecording.jfrに保存するには、次を使用します。

  jcmd 7060 JFR.start name=MyRecording settings=profile delay=20s duration=2m filename=C:\TEMP\myrecording.jfr

• 記録の確認

  JFR.check診断コマンドは、実行中の記録を確認します。たとえば:

  jcmd 7060 JFR.check

• 記録の停止

  JFR.stop診断コマンドは、実行中の記録を停止し、記録データを破棄することもできます。たとえば:

  jcmd 7060 JFR.stop

• 記録のダンプ

  JFR.dump診断コマンドは、実行中の記録を停止し、記録をファイルにダンプすることもできます。たとえば:

  jcmd 7060 JFR.dump name=MyRecording filename=C:\TEMP\myrecording.jfr

• ヒープ・ダンプの作成

  ヒープ・ダンプを作成する推奨方法を次に示します。

  jcmd <pid> GC.heap_dump filename=Myheapdump

• ヒープ・ヒストグラムの作成

  ヒープ・ヒストグラムを作成する推奨方法を次に示します。

  jcmd <pid> GC.class_histogram filename=Myheaphistogram

ネイティブ・メモリー・トラッキングはメモリーをモニターし、開発またはメンテナンス時にアプリケーションのメモリー使用量が増え始めないように設定できます。

• サンプル出力の解釈: 次のサンプル出力から、予約済メモリーとコミット済メモリーを確認できます。コミット済メモリーのみが実際に使用されることに注意してください。たとえば、-Xms100m -Xmx1000mで実行した場合、JVMでは1000MBがJavaヒープ用に予約されます。初期のヒープ・サイズは100MBのみであるため、最初に100MBのみがコミットされます。アドレス領域がほぼ無制限である64ビット・マシンの場合、JVMで多くのメモリーが予約されても問題はありません。コミットされるメモリーが次第に増加し、スワッピングやネイティブ・メモリー不足(OOM)状態になる可能性がある場合に、問題が発生します。

  アリーナは、mallocを使用して割り当てられるメモリー・チャンクです。スコープを終了またはコード領域を離れるとき、これらのチャンクからメモリーがバルクで解放されます。これらのチャンクは、一時メモリーを保持するために他のサブシステムで再利用できます(プリスレッドの割当てなど)。アリーナのmallocポリシーでは、メモリー・リークがないことが確認されます。したがって、個々のオブジェクトではなく、Arena全体が追跡されます。一部の初期メモリーは追跡できません。

  NMTを有効にすると、JVMパフォーマンスが5-10%低下し、NMTのメモリー使用量により、すべてのmallocメモリーに2マシン・ワードがmallocヘッダーとして追加されます。NMTのメモリー使用量も、NMTにより追跡されます。

  >jcmd 17320 VM.native_memory
  Native Memory Tracking:
  
  Total: reserved=5699702KB, committed=351098KB
  -                 Java Heap (reserved=4153344KB, committed=260096KB)
                              (mmap: reserved=4153344KB, committed=260096KB)
  
  -                     Class (reserved=1069839KB, committed=22543KB)
                              (classes #3554)
                              (  instance classes #3294, array classes #260)
                              (malloc=783KB #7965)
                              (mmap: reserved=1069056KB, committed=21760KB)
                              (  Metadata:   )
                              (    reserved=20480KB, committed=18944KB)
                              (    used=18267KB)
                              (    free=677KB)
                              (    waste=0KB =0.00%)
                              (  Class space:)
                              (    reserved=1048576KB, committed=2816KB)
                              (    used=2454KB)
                              (    free=362KB)
                              (    waste=0KB =0.00%)
  
  -                    Thread (reserved=24685KB, committed=1205KB)
                              (thread #24)
                              (stack: reserved=24576KB, committed=1096KB)
                              (malloc=78KB #132)
                              (arena=30KB #46)
  
  -                      Code (reserved=248022KB, committed=7890KB)
                              (malloc=278KB #1887)
                              (mmap: reserved=247744KB, committed=7612KB)
  
  -                        GC (reserved=197237KB, committed=52789KB)
                              (malloc=9717KB #2877)
                              (mmap: reserved=187520KB, committed=43072KB)
  
  -                  Compiler (reserved=148KB, committed=148KB)
                              (malloc=19KB #95)
                              (arena=129KB #5)
  
  -                  Internal (reserved=735KB, committed=735KB)
                              (malloc=663KB #1914)
                              (mmap: reserved=72KB, committed=72KB)
  
  -                     Other (reserved=48KB, committed=48KB)
                              (malloc=48KB #4)
  
  -                    Symbol (reserved=4835KB, committed=4835KB)
                              (malloc=2749KB #17135)
                              (arena=2086KB #1)
  
  -    Native Memory Tracking (reserved=539KB, committed=539KB)
                              (malloc=8KB #109)
                              (tracking overhead=530KB)
  
  -               Arena Chunk (reserved=187KB, committed=187KB)
                              (malloc=187KB)
  
  -                   Logging (reserved=4KB, committed=4KB)
                              (malloc=4KB #179)
  
  -                 Arguments (reserved=18KB, committed=18KB)
                              (malloc=18KB #467)
  
  -                    Module (reserved=62KB, committed=62KB)
                              (malloc=62KB #1060)

• 詳細データの取得: ネイティブ・メモリー使用量の詳細ビューを取得するには、次のコマンドライン・オプションを使用してJVMを起動します: -XX:NativeMemoryTracking=detailこれは、最も多くのメモリーを割り当てるメソッドを正確に追跡します。NMTを有効にすると、JVMパフォーマンスが5-10%低下し、NMTのメモリー使用量により、すべてのmallocメモリーに2ワードがmallocヘッダーとして追加されます。NMTのメモリー使用量も、NMTにより追跡されます。

  次の例は、追跡レベルが詳細に設定された仮想メモリーの出力例です。これは、前述のサマリー出力に加えて表示されます。このサンプル出力を得るための1つの方法は、jcmd <pid> VM.native_memory detailを実行することです。

  Virtual memory map:
  
  [0x00000000a1000000 - 0x0000000800000000] reserved 30916608KB for Java Heap from
      [0x00007f5b91a2472b] ReservedHeapSpace::try_reserve_heap(unsigned long, unsigned long, bool, char*)+0x20b
      [0x00007f5b91a24de9] ReservedHeapSpace::initialize_compressed_heap(unsigned long, unsigned long, bool)+0x5a9
      [0x00007f5b91a254c6] ReservedHeapSpace::ReservedHeapSpace(unsigned long, unsigned long, bool, char const*)+0x176
      [0x00007f5b919da835] Universe::reserve_heap(unsigned long, unsigned long)+0x65
  
                 [0x00000000a1000000 - 0x0000000117000000] committed 1933312KB from
              [0x00007f5b9132c9be] G1PageBasedVirtualSpace::commit(unsigned long, unsigned long)+0x18e
              [0x00007f5b913414d1] G1RegionsLargerThanCommitSizeMapper::commit_regions(unsigned int, unsigned long, WorkGang*)+0x1a1
              [0x00007f5b913d5c78] HeapRegionManager::commit_regions(unsigned int, unsigned long, WorkGang*)+0x58
              [0x00007f5b913d6c45] HeapRegionManager::expand(unsigned int, unsigned int, WorkGang*)+0x35
  
                 [0x00000007fe000000 - 0x00000007fef00000] committed 15360KB from
              [0x00007f5b9132c9be] G1PageBasedVirtualSpace::commit(unsigned long, unsigned long)+0x18e
              [0x00007f5b913414d1] G1RegionsLargerThanCommitSizeMapper::commit_regions(unsigned int, unsigned long, WorkGang*)+0x1a1
              [0x00007f5b913d5c78] HeapRegionManager::commit_regions(unsigned int, unsigned long, WorkGang*)+0x58
              [0x00007f5b913d7355] HeapRegionManager::expand_exact(unsigned int, unsigned int, WorkGang*)+0xd5
  

• NMTベースラインからの差分の取得: サマリーおよび詳細レベルの追跡では、アプリケーションが起動され実行された後、ベースラインを設定できます。これを行うには、アプリケーションのウォーム・アップ後にjcmd <pid> VM.native_memory baselineを実行します。次に、jcmd <pid> VM.native_memory summary.diffまたはjcmd <pid> VM.native_memory detail.diffを実行できます。

  次の例は、ベースラインの設定以降に使用されたネイティブ・メモリー使用量の差分サマリーのサンプル出力で、カテゴリ別のメモリー使用量の変化を示しています:

  Native Memory Tracking:
  
  Total: reserved=33485260KB +28KB, committed=497784KB +96KB
  
  -                 Java Heap (reserved=30916608KB, committed=393216KB)
                              (mmap: reserved=30916608KB, committed=393216KB)
   
  -                     Class (reserved=1048702KB, committed=254KB)
                              (classes #507)
                              (  instance classes #421, array classes #86)
                              (malloc=126KB #635)
                              (mmap: reserved=1048576KB, committed=128KB)
                              (  Metadata:   )
                              (    reserved=8192KB, committed=192KB)
                              (    used=118KB)
                              (    free=74KB)
                              (    waste=0KB =0.00%)
                              (  Class space:)
                              (    reserved=1048576KB, committed=128KB)
                              (    used=5KB)
                              (    free=123KB)
                              (    waste=0KB =0.00%)
   
  -                    Thread (reserved=35984KB, committed=1432KB +68KB)
                              (thread #0)
                              (stack: reserved=35896KB, committed=1344KB +68KB)
                              (malloc=49KB #212)
                              (arena=39KB #68)
   
  -                      Code (reserved=247729KB, committed=7593KB)
                              (malloc=45KB #438)
                              (mmap: reserved=247684KB, committed=7548KB)
   
  -                        GC (reserved=1209971KB, committed=77267KB)
                              (malloc=29183KB #872)
                              (mmap: reserved=1180788KB, committed=48084KB)
   
  -                  Compiler (reserved=168KB, committed=168KB)
                              (malloc=3KB #34)
                              (arena=165KB #5)
  

  次の例は、ベースライン以降に使用されたネイティブ・メモリー使用量の差分詳細を示すサンプル出力で、特定のメモリー・リークを見つけるのに優れた方法です:

  [0x00007f5b9175ea8b] MemBaseline::aggregate_virtual_memory_allocation_sites()+0x11b
  [0x00007f5b9175ed68] MemBaseline::baseline_allocation_sites()+0x188
  [0x00007f5b9175efff] MemBaseline::baseline(bool)+0x1cf
  [0x00007f5b917d19a4] NMTDCmd::execute(DCmdSource, Thread*)+0x2b4
                               (malloc=1KB type=Native Memory Tracking +1KB #18 +18)
  
  [0x00007f5b917635b0] MallocAllocationSiteWalker::do_malloc_site(MallocSite const*)+0x40
  [0x00007f5b91740bc8] MallocSiteTable::walk_malloc_site(MallocSiteWalker*)+0x78
  [0x00007f5b9175ec32] MemBaseline::baseline_allocation_sites()+0x52
  [0x00007f5b9175efff] MemBaseline::baseline(bool)+0x1cf
                               (malloc=11KB type=Native Memory Tracking +10KB #156 +136)
  
  [0x00007f5b91a2472b] ReservedHeapSpace::try_reserve_heap(unsigned long, unsigned long, bool, char*)+0x20b
  [0x00007f5b91a24de9] ReservedHeapSpace::initialize_compressed_heap(unsigned long, unsigned long, bool)+0x5a9
  [0x00007f5b91a254c6] ReservedHeapSpace::ReservedHeapSpace(unsigned long, unsigned long, bool, char const*)+0x176
  [0x00007f5b919da835] Universe::reserve_heap(unsigned long, unsigned long)+0x65
                               (mmap: reserved=30916608KB, committed=475136KB +81920KB Type=Java Heap)
  
  [0x00007f5b91804557] thread_native_entry(Thread*)+0xe7
                               (mmap: reserved=34868KB, committed=1224KB +68KB Type=Thread Stack)
  
  [0x00007f5b91a23c63] ReservedSpace::ReservedSpace(unsigned long, unsigned long)+0x213
  [0x00007f5b912df57c] G1CollectedHeap::create_aux_memory_mapper(char const*, unsigned long, unsigned long)+0x3c
  [0x00007f5b912e4f13] G1CollectedHeap::initialize()+0x333
  [0x00007f5b919da5dd] universe_init()+0xbd
                               (mmap: reserved=483072KB, committed=7424KB +1280KB Type=GC)
  
  [0x00007f5b91a23c63] ReservedSpace::ReservedSpace(unsigned long, unsigned long)+0x213
  [0x00007f5b912df57c] G1CollectedHeap::create_aux_memory_mapper(char const*, unsigned long, unsigned long)+0x3c
  [0x00007f5b912e4e6a] G1CollectedHeap::initialize()+0x28a
  [0x00007f5b919da5dd] universe_init()+0xbd
                               (mmap: reserved=60384KB, committed=928KB +160KB Type=GC)

ネイティブ・メモリー・トラッキングを使用してメモリー・リークを検知する手順。

1. 次のコマンドライン・オプションを使用して、サマリーまたは詳細なトラッキングが指定されたJVMを起動します: -XX:NativeMemoryTracking=summaryまたは-XX:NativeMemoryTracking=detail。
2. 初期のベースラインを設定します。NMTベースライン機能を使用して、開発とメンテナンスのときに比較するベースラインを取得するには、次を実行します: jcmd <pid> VM.native_memory baseline。
3. 次を使用して、メモリーの変更をモニターします: jcmd <pid> VM.native_memory detail.diff
4. アプリケーションのメモリー・リークが少量の場合、それが明らかになるまで時間がかかる場合があります。

NMTで使用されるネイティブ・メモリー・トラッキングのメモリー・カテゴリのリスト。

表2-1に、NMTで使用されるネイティブ・メモリー・カテゴリを示します。これらのカテゴリは、リリースにより変更される可能性があります。

JConsoleを使用して、データをモニターします。

次のリストは、JConsoleツールを使用してモニターできるデータの概要を示しています。各見出しはツール内のタブ・ペインに対応しています。

• 概要

  このペインには、ヒープ・メモリー使用量、スレッド数、クラス数、およびCPU使用率の経時的推移を示すグラフが表示されます。この概要では、いくつかのリソースのアクティビティを一度に視覚化できます。

• メモリー

  • 選択された1つのメモリー領域(ヒープ、非ヒープ、各種メモリー・プール)について

    • メモリー使用量の経時的推移を示すグラフ

    • 現在のメモリー・サイズ

    • コミットされたメモリーの量

    • 最大メモリー・サイズ

  • ガベージ・コレクタの情報(実行されたコレクションの回数や、ガベージ・コレクションの実行に費やされた合計時間など)

  • 現在使用中のヒープおよび非ヒープ・メモリーのパーセントを示すグラフ

  さらにこのペインでは、ガベージ・コレクションの実行を要求できます。

• スレッド

  • スレッド使用量の経時的推移を示すグラフ。

  • ライブ・スレッド: 現在のライブ・スレッド数。

  • ピーク: JVM起動後のライブ・スレッドの最大数。

  • 選択された1つのスレッドの名前、状態、およびスタック・トレース、およびブロックされたスレッドの場合は、スレッドが獲得を待機しているシンクロナイザとロックを所有しているスレッド。

  • 「デッドロックの検出」ボタンは、デッドロック検出を実行する要求をターゲット・アプリケーションに送信し、各デッドロック・サイクルをそれぞれ異なるタブに表示します。

• クラス

  • ロード済クラス数の経時的推移を示すグラフ

  • 現在メモリーにロードされているクラスの数

  • JVMの起動後にメモリーにロードされたクラスの合計数(その後アンロードされたものも含む)

  • JVMの起動後にメモリーからアンロードされたクラスの合計数

• VMサマリー

  • 一般的な情報(JConsole接続データ、JVMの稼働時間、JVMで消費されたCPU時間、コンパイラ名、合計コンパイル時間など)。

  • スレッドおよびクラスのサマリー情報

  • メモリーおよびガベージ・コレクションの情報(ファイナライズ保留中のオブジェクトの数など)

  • オペレーティング・システムに関する情報(物理特性、実行中のプロセス用の仮想メモリー量、スワップ領域など)

  • JVM自体に関する情報(引数やクラス・パスなど)

• MBeans

  このペインには、接続済のJMXエージェントに登録されたすべてのプラットフォームおよびアプリケーションMBeanを示すツリー構造が表示されます。ツリー内でMBeanを選択すると、その属性、操作、通知、およびその他の情報が表示されます。

  • 操作(存在する場合)を呼び出せます。たとえば、com.sun.managementドメインに含まれるHotSpotDiagnostic MBeanの操作dumpHeapは、ヒープ・ダンプを実行します。この操作の入力パラメータは、ターゲットVMが実行されているマシン上でのヒープ・ダンプ・ファイルのパス名になります。

  • 書込み可能な属性値を設定できます。たとえば、特定のVMフラグの値を設定、設定解除、または変更するには、HotSpotDiagnostic MBeanのsetVMOption操作を呼び出します。フラグは、DiagnosticOptions属性の値のリストによって示されます。

  • 通知(存在する場合)をサブスクライブするには、「サブスクライブ」および「サブスクライブ解除」ボタンを使用します。

JConsoleは、ローカル・アプリケーションとリモート・アプリケーションの両方をモニターできます。接続先JMXエージェントを指定する引数付きでツールを起動した場合、ツールは指定されたアプリケーションのモニタリングを自動的に開始します。

ローカル・アプリケーションをモニターするには、コマンドjconsolepid (pidはアプリケーションのプロセスID)を実行します。

リモート・アプリケーションをモニターするには、コマンドjconsolehostname: portnumber (hostnameはアプリケーションを実行しているホストの名前、portnumberはJMXエージェントの有効化時に指定したポート番号)を実行します。

jconsoleコマンドを引数なしで実行した場合、このツールはまず、モニター対象のローカルまたはリモート・プロセスを指定するための「新規接続」ウィンドウを表示します。「接続」メニューを使えば別のホストにいつでも接続できます。

最新のJDKリリースでは、モニター対象アプリケーションを起動する際にオプションは不要です。

モニタリング・ツールの出力例として、図2-1はヒープ・メモリー使用量のグラフを示しています。

図2-1 JConsoleからのサンプル出力

「図2-1 JConsoleからのサンプル出力」の説明

jdbユーティリティはリモート・デバッグに使用するデバッガ・コネクタをモニターするために使用します。

JDIでは、コネクタを使用してデバッガをターゲットJVMに接続します。JDKには従来、ターゲットJVMとのデバッグ・セッションを開始して確立するコネクタと、(TCP/IPまたは共有メモリー・トランスポートを使用した)リモート・デバッグに使用されるコネクタが付属しています。

これらのコネクタは通常、NetBeans統合開発環境(IDE)や商用IDEなどのエンタープライズ・デバッガで使用されます。

コマンドjdb -listconnectorsは、使用可能なコネクタの一覧を出力します。コマンドjdb -helpは、コマンドの使用方法のヘルプを出力します。

Java Development Kitツール仕様のjdbコマンドに関する項を参照してください

jinfoの出力には、java.class.pathおよびsun.boot.class.pathの設定が表示されます。

$ jhsdb jinfo --exe java-home/bin/java --core core.19256

jhsdb jmap --heapコマンドを使用してJavaヒープ情報を取得します。

c:\Program Files\Java\jdk-13\bin>jhsdb jmap --heap --pid 19256
Attaching to process ID 19256, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 13-ea+29

using thread-local object allocation.
Garbage-First (G1) GC with 4 thread(s)

Heap Configuration:
   MinHeapFreeRatio         = 40
   MaxHeapFreeRatio         = 70
   MaxHeapSize              = 4253024256 (4056.0MB)
   NewSize                  = 1363144 (1.2999954223632812MB)
   MaxNewSize               = 2551185408 (2433.0MB)
   OldSize                  = 5452592 (5.1999969482421875MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 1048576 (1.0MB)

Heap Usage:
G1 Heap:
   regions  = 4056
   capacity = 4253024256 (4056.0MB)
   used     = 7340032 (7.0MB)
   free     = 4245684224 (4049.0MB)
   0.17258382642998027% used
G1 Young Generation:
Eden Space:
   regions  = 7
   capacity = 15728640 (15.0MB)
   used     = 7340032 (7.0MB)
   free     = 8388608 (8.0MB)
   46.666666666666664% used
Survivor Space:
   regions  = 0
   capacity = 0 (0.0MB)
   used     = 0 (0.0MB)
   free     = 0 (0.0MB)
   0.0% used
G1 Old Generation:
   regions  = 0
   capacity = 250609664 (239.0MB)
   used     = 0 (0.0MB)
   free     = 250609664 (239.0MB)
   0.0% used

-histoオプションを指定してjmapコマンドを使用するか、jhsdb jmap --histoコマンドを使用すると、クラス固有のヒープ・ヒストグラムを取得できます。

c:\Program Files\Java\jdk-13\bin>jmap -histo 19256
No dump file specified
 num     #instances         #bytes  class name (module)
-------------------------------------------------------
   1:         20913        1658720  [B (java.base@13-ea)
   2:          3647        1516888  [I (java.base@13-ea)
   3:         12321         492840  java.security.AccessControlContext (java.base@13-ea)
   4:         14806         355344  java.lang.String (java.base@13-ea)
   5:          2441         298464  java.lang.Class (java.base@13-ea)
   6:          5169         289464  jdk.internal.org.objectweb.asm.SymbolTable$Entry (java.base@13-ea)
   7:          5896         284216  [Ljava.lang.Object; (java.base@13-ea)
   8:          6887         220384  java.util.HashMap$Node (java.base@13-ea)
   9:           237         194640  [Ljdk.internal.org.objectweb.asm.SymbolTable$Entry; (java.base@13-ea)
  10:          5119         163808  java.util.ArrayList$Itr (java.base@13-ea)
  11:          1922         153760  java.awt.event.MouseEvent (java.desktop@13-ea)
  12:           672         139776  sun.java2d.SunGraphics2D (java.desktop@13-ea)
  13:          4101         131232  java.lang.ref.WeakReference (java.base@13-ea)
  14:           655         101848  [Ljava.util.HashMap$Node; (java.base@13-ea)
  15:          3915          93960  sun.awt.EventQueueItem (java.desktop@13-ea)
  16:           367          89008  [C (java.base@13-ea)
  17:          3708          88992  java.awt.Point (java.desktop@13-ea)
  18:          2158          86320  java.lang.invoke.MethodType (java.base@13-ea)
  19:          3026          81832  [Ljava.lang.Class; (java.base@13-ea)
  20:           348          77952  jdk.internal.org.objectweb.asm.MethodWriter (java.base@13-ea)
  21:          1016          73152  java.awt.geom.AffineTransform (java.desktop@13-ea)
  22:          1017          65088  java.awt.event.InvocationEvent (java.desktop@13-ea)
  23:          2013          64416  java.awt.Rectangle (java.desktop@13-ea)
  24:          1341          64368  java.lang.invoke.MemberName (java.base@13-ea)
  25:          1849          59168  java.util.concurrent.ConcurrentHashMap$Node (java.base@13-ea)
... more lines removed here to reduce output...
1414:             1             16  sun.util.resources.LocaleData$LocaleDataStrategy (java.base@13-ea)
1415:             1             16  sun.util.resources.provider.NonBaseLocaleDataMetaInfo (jdk.localedata@13-ea)
Total        145508        8388608

& jhsdb jmap --exe /usr/java/jdk_12/bin/java --core core.16395 --histo
Attaching to core core.16395 from executable /usr/java/jdk_12/bin/java please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 12-ea+30
Iterating over heap. This may take a while...
Object Histogram:

num     #instances     #bytes   Class description
--------------------------------------------------------------------------
1:           11102     564520   byte[]
2:           10065     241560   java.lang.String
3:            1421     163392   java.lang.Class
4:           26403    2997816   * ConstMethodKlass
5:           26403    2118728   * MethodKlass
6:           39750    1613184   * SymbolKlass
7:            2011    1268896   * ConstantPoolKlass
8:            2011    1097040   * InstanceKlassKlass
9:            1906     882048   * ConstantPoolCacheKlass
10:           1614     125752   java.lang.Object[]
11:           1160      64960   jdk.internal.org.objectweb.asm.Item
12:           1834      58688   java.util.HashMap$Node
13:            359      40880   java.util.HashMap$Node[]
14:           1189      38048   java.util.concurrent.ConcurrentHashMap$Node
15:             46      37280   jdk.internal.org.objectweb.asm.Item[]
16:             29      35600   char[]
17:            968      32320   int[]
18:            650      26000   java.lang.invoke.MethodType
19:            475      22800   java.lang.invoke.MemberName

jstackコマンド行ユーティリティは、指定されたプロセスに接続し、仮想マシンに接続されたすべてのスレッド(JavaスレッドやVM内部スレッドも含む)のスタック・トレースを出力する以外に、オプションでネイティブ・スタック・フレームも出力します。このユーティリティではデッドロック検出も実行されます。コア・ファイルには、jhsdb jstackを使用します。

コア・ダンプからスタック・トレースを取得するにはjhsdb jstackコマンドを使用します。

$ jhsdb jstack --exe java-home/bin/java --core core-file

jhsdb jstackユーティリティは、混合スタックの出力に使用することもできます(つまり、Javaスタックの他にネイティブ・スタック・フレームも出力できます)。ネイティブ・フレームとは、VMコードやJNI/ネイティブ・コードに関連付けられたC/C++フレームのことです。

>jhsdb jstack --mixed --pid 21177
Attaching to process ID 21177, please wait...Debugger attached successfully.
Server compiler detected.
JVM version is 14-ea+29-1384
Deadlock Detection:

No deadlocks found.

----------------- 0 -----------------
----------------- 1 -----------------
"DestroyJavaVM" #18 prio=5 tid=0x000001df4706f000 nid=0x744 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00007ffa4529f9f4      ntdll!ZwWaitForAlertByThreadId + 0x14
0x000001df2533dc50              ????????
----------------- 2 -----------------
0x00007ffa4529c144      ntdll!NtWaitForSingleObject + 0x14
----------------- 3 -----------------
0x00007ffa4529f9f4      ntdll!ZwWaitForAlertByThreadId + 0x14
----------------- 4 -----------------
0x00007ffa4529c144      ntdll!NtWaitForSingleObject + 0x14
----------------- 5 -----------------
0x00007ffa4529f9f4      ntdll!ZwWaitForAlertByThreadId + 0x14
----------------- 6 -----------------
0x00007ffa4529f9f4      ntdll!ZwWaitForAlertByThreadId + 0x14
----------------- 7 -----------------
0x00007ffa4529f9f4      ntdll!ZwWaitForAlertByThreadId + 0x14
----------------- 8 -----------------
"Reference Handler" #2 daemon prio=10 tid=0x000001df47020000 nid=0x4728 waiting on condition [0x000000a733aff000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00007ffa4529f9f4      ntdll!ZwWaitForAlertByThreadId + 0x14
0x000001df2533e280              ????????
----------------- 9 -----------------
"Finalizer" #3 daemon prio=8 tid=0x000001df4702b000 nid=0x5278 in Object.wait() [0x000000a733bfe000]
   java.lang.Thread.State: WAITING (on object monitor)
   JavaThread state: _thread_blocked
0x00007ffa4529c144      ntdll!NtWaitForSingleObject + 0x14
----------------- 10 -----------------
"Signal Dispatcher" #4 daemon prio=9 tid=0x000001df47053800 nid=0xac0 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00007ffa4529c144      ntdll!NtWaitForSingleObject + 0x14
----------------- 11 -----------------
"Attach Listener" #5 daemon prio=5 tid=0x000001df47058800 nid=0x3980 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00007ffa4529c144      ntdll!NtWaitForSingleObject + 0x14
0x000001df47059390              ????????
----------------- 12 -----------------
"Service Thread" #6 daemon prio=9 tid=0x000001df4705b800 nid=0x3350 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00007ffa4529f9f4      ntdll!ZwWaitForAlertByThreadId + 0x14
----------------- 13 -----------------
"C2 CompilerThread0" #7 daemon prio=9 tid=0x000001df47068800 nid=0x51e8 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00007ffa4529f9f4      ntdll!ZwWaitForAlertByThreadId + 0x14
0x000001df2533d590              ????????
----------------- 14 -----------------
"C1 CompilerThread0" #9 daemon prio=9 tid=0x000001df4705d800 nid=0xc20 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00007ffa4529f9f4      ntdll!ZwWaitForAlertByThreadId + 0x14
0x000001df2533d590              ????????
----------------- 15 -----------------
"Sweeper thread" #10 daemon prio=9 tid=0x000001df4706c000 nid=0x1a64 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00007ffa4529f9f4      ntdll!ZwWaitForAlertByThreadId + 0x14
----------------- 16 -----------------
"Notification Thread" #11 daemon prio=9 tid=0x000001df47070000 nid=0xddc runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00007ffa4529f9f4      ntdll!ZwWaitForAlertByThreadId + 0x14
----------------- 17 -----------------
0x00007ffa4529f9f4      ntdll!ZwWaitForAlertByThreadId + 0x14
0x00000f3e40772a94              ????????
----------------- 18 -----------------
"Common-Cleaner" #12 daemon prio=8 tid=0x000001df4706b000 nid=0x2054 in Object.wait() [0x000000a7344fe000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
   JavaThread state: _thread_blocked
0x00007ffa4529c144      ntdll!NtWaitForSingleObject + 0x14
----------------- 19 -----------------
"Java2D Disposer" #13 daemon prio=10 tid=0x000001df4706c800 nid=0x4770 in Object.wait() [0x000000a7345ff000]
   java.lang.Thread.State: WAITING (on object monitor)
   JavaThread state: _thread_blocked
0x00007ffa4529c144      ntdll!NtWaitForSingleObject + 0x14
----------------- 20 -----------------
"AWT-Shutdown" #14 prio=5 tid=0x000001df4706d800 nid=0x4ed4 in Object.wait() [0x000000a7346fe000]
   java.lang.Thread.State: WAITING (on object monitor)
   JavaThread state: _thread_blocked
0x00007ffa4529c144      ntdll!NtWaitForSingleObject + 0x14
----------------- 21 -----------------
"AWT-Windows" #15 daemon prio=6 tid=0x000001df4706e800 nid=0x15e8 runnable [0x000000a7347ff000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
----------------- 22 -----------------
"AWT-EventQueue-0" #17 prio=6 tid=0x000001df4706a000 nid=0x2f54 waiting on condition [0x000000a7348fe000]
   java.lang.Thread.State: WAITING (parking)
   JavaThread state: _thread_blocked
0x00007ffa4529c144      ntdll!NtWaitForSingleObject + 0x14
----------------- 23 -----------------
----------------- 24 -----------------
----------------- 25 -----------------

スレッド・ダンプは、仮想マシン内のすべてのJavaスレッドのスレッド・スタック(スレッドの状態など)で構成されています。

スレッド・ダンプによってアプリケーションが終了することはなく、スレッド情報が出力された後もアプリケーションは続行します。

次の例はスレッド・ダンプを示しています。

Full thread dump Java HotSpot(TM) Client VM (1.6.0-rc-b100 mixed mode):

"DestroyJavaVM" prio=10 tid=0x00030400 nid=0x2 waiting on condition [0x00000000..0xfe77fbf0]
   java.lang.Thread.State: RUNNABLE

"Thread2" prio=10 tid=0x000d7c00 nid=0xb waiting for monitor entry [0xf36ff000..0xf36ff8c0]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at Deadlock$DeadlockMakerThread.run(Deadlock.java:32)
        - waiting to lock <0xf819a938> (a java.lang.String)
        - locked <0xf819a970> (a java.lang.String)

"Thread1" prio=10 tid=0x000d6c00 nid=0xa waiting for monitor entry [0xf37ff000..0xf37ffbc0]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at Deadlock$DeadlockMakerThread.run(Deadlock.java:32)
        - waiting to lock <0xf819a970> (a java.lang.String)
        - locked <0xf819a938> (a java.lang.String)

"Low Memory Detector" daemon prio=10 tid=0x000c7800 nid=0x8 runnable [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"CompilerThread0" daemon prio=10 tid=0x000c5400 nid=0x7 waiting on condition [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x000c4400 nid=0x6 waiting on condition [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x000b2800 nid=0x5 in Object.wait() [0xf3f7f000..0xf3f7f9c0]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0xf4000b40> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
        - locked <0xf4000b40> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=10 tid=0x000ae000 nid=0x4 in Object.wait() [0xfe57f000..0xfe57f940]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0xf4000a40> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:485)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
        - locked <0xf4000a40> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x000ab000 nid=0x3 runnable 

"VM Periodic Task Thread" prio=10 tid=0x000c8c00 nid=0x9 waiting on condition 

この出力は、空白行で区切られたいくつかのスレッド・エントリで構成されます。Javaスレッド(Java言語コードを実行できるスレッド)がまず出力され、それらの後にVM内部スレッドに関する情報が続きます。各スレッド・エントリは、ヘッダー行とその後に続くスレッド・スタック・トレースで構成されます。

ヘッダー行には、スレッドに関する次の情報が含まれます。

• スレッド名

• スレッドがデーモン・スレッドかどうかのマーク

• スレッド優先度(prio)

• スレッドID (tid)。メモリー内のスレッド構造体のアドレスです

• ネイティブ・スレッドのID (nid)

• スレッド・ダンプ時にスレッドが実行していた内容を示す、スレッド状態詳細は、表2-2を参照してください。

• アドレス範囲(スレッドのおおよその有効なスタック領域を表す)

Ctrl+Breakハンドラは、スレッドのデッドロック検出にも使用できます。

Ctrl+Breakハンドラは、スレッド・スタックだけでなく、デッドロック検出アルゴリズムも実行します。デッドロックが検出された場合、次の例に示すように、Ctrl+Breakハンドラは、デッドロックされた各スレッドに関するスレッド・ダンプの後に追加情報を出力します。

Found one Java-level deadlock:
=============================
"Thread2":
  waiting to lock monitor 0x000af330 (object 0xf819a938, a java.lang.String),
  which is held by "Thread1"
"Thread1":
  waiting to lock monitor 0x000af398 (object 0xf819a970, a java.lang.String),
  which is held by "Thread2"

Java stack information for the threads listed above:
===================================================
"Thread2":
        at Deadlock$DeadlockMakerThread.run(Deadlock.java:32)
        - waiting to lock <0xf819a938> (a java.lang.String)
        - locked <0xf819a970> (a java.lang.String)
"Thread1":
        at Deadlock$DeadlockMakerThread.run(Deadlock.java:32)
        - waiting to lock <0xf819a970> (a java.lang.String)
        - locked <0xf819a938> (a java.lang.String)

Found 1 deadlock.

JVMフラグ-XX:+PrintConcurrentLocksが設定されている場合、Ctrl+Breakハンドラは各スレッドが所有している並行ロックのリストも出力します。

Ctrl+Breakハンドラはヒープ・サマリーの出力にも使用できます。

次の例では、様々な世代(ヒープ領域)がそのサイズ、使用量、アドレス範囲とともに示されています。アドレス範囲は特に、pmapなどのツールでプロセスを調査する場合にも役立ちます。

Heap
 def new generation   total 1152K, used 435K [0x22960000, 0x22a90000, 0x22e40000
)
  eden space 1088K,  40% used [0x22960000, 0x229ccd40, 0x22a70000)
  from space 64K,   0% used [0x22a70000, 0x22a70000, 0x22a80000)
  to   space 64K,   0% used [0x22a80000, 0x22a80000, 0x22a90000)
 tenured generation   total 13728K, used 6971K [0x22e40000, 0x23ba8000, 0x269600
00)
   the space 13728K,  50% used [0x22e40000, 0x2350ecb0, 0x2350ee00, 0x23ba8000)
 compacting perm gen  total 12288K, used 1417K [0x26960000, 0x27560000, 0x2a9600
00)
   the space 12288K,  11% used [0x26960000, 0x26ac24f8, 0x26ac2600, 0x27560000)
    ro space 8192K,  62% used [0x2a960000, 0x2ae5ba98, 0x2ae5bc00, 0x2b160000)
    rw space 12288K,  52% used [0x2b160000, 0x2b79e410, 0x2b79e600, 0x2bd60000)

JVMフラグ-XX:+PrintClassHistogramが設定されている場合、Ctrl+Breakハンドラはヒープ・ヒストグラムを生成します。

Java HotSpot VMにはhotspotおよびhotspot_jniという2つの組込みプローブ・プロバイダが含まれるようになりました。

これらのプロバイダは、VMの内部状態やアクティビティだけでなく、実行中のJavaアプリケーションもモニターするために使用できるプローブを配布します。

JVMプローブ・プロバイダは次のように分類できます。

• VMのライフ・サイクル: VMの初期化の開始と終了、およびVMのシャットダウン

• スレッドのライフ・サイクル: スレッドの開始と停止、スレッド名、スレッドIDなど

• クラスのロード: Javaクラスのロードとアンロード

• ガベージ・コレクション: ガベージ・コレクションの開始と停止、システム全体またはメモリー・プール別

• メソッドのコンパイル: メソッドのコンパイルの開始と終了、メソッドのロードとアンロード

• モニター・プローブ: 待機イベント、通知イベント、競合するモニターへの出入り

• アプリケーションの追跡: メソッドに入る、メソッドから戻る、Javaオブジェクトの割当て

ネイティブ・コードからJavaコードへの呼出しの場合、ネイティブ・コードはJNIインタフェース経由で呼出しを行う必要があります。hotspot_jniプロバイダは、Javaコードを呼び出したりVMの状態を検査したりするためにJNIインタフェースに用意されているメソッドごとに、入口と出口におけるDTraceプローブを管理します。

プローブ・ポイントで現在のスレッドのスタック・トレースを出力するには、ustack組込み関数を使用できます。この関数は、C/C++ネイティブ関数の名前だけでなく、Javaメソッドの名前も出力します。次の例は、あるスレッドがreadシステム・コールを呼び出したときに必ず完全なスタック・トレースを出力する単純なDスクリプトです。

#!/usr/sbin/dtrace -s
syscall::read:entry 
/pid == $1 && tid == 1/ {    
   ustack(50, 0x2000);
}

前の例のスクリプトはread.dというファイルに格納され、次の例に示すように、トレース対象のJavaプロセスのPIDを指定することで実行されます。

read.d pid

Javaアプリケーションで多数のI/Oが生成されたり、なんらかの予期しない遅延が発生したりした場合、DTraceツールやそのustack()アクションを使用すれば、問題を診断しやすくなる可能性があります。

Java Platform Debugger Architecture (JPDA)は、デバッガやデバッガに似たツールが使用するために設計されたアーキテクチャです。

Java Platform Debugger Architectureは、2つのプログラミング・インタフェースおよびワイヤ・プロトコルで構成されています。

• Java Virtual Machine Tool Interface (JVM TI)は、仮想マシンへのインタフェースです。「JVM Tool Interface」を参照してください。

• Java Debug Interface (JDI)は、ユーザー・コード・レベルでの情報および要求を定義します。これは、Javaプログラミング言語アプリケーションをデバッグするためのPure Javaプログラミング言語インタフェースです。JPDAでは、JDIは、デバッガのプロセスから見たデバッグ対象プロセスの仮想マシンのリモート・ビューです。これはフロント・エンドによって実装されます。デバッガに似たアプリケーション(IDE、デバッガ、トレーサ、モニタリング・ツールなど)はクライアントとなります。モジュールjdk.jdiを参照してください。

• Java Debug Wire Protocol (JDWP)は、デバッグされるプロセスと、JDIを実装したデバッガ・フロント・エンドとの間で転送される、情報および要求の形式を定義します。

jdbユーティリティは、コマンド行デバッガの例としてJDKに含まれています。jdbユーティリティは、JDIを使ってターゲットVMを起動または接続します。「jdbユーティリティ」を参照してください。

JDIを使用すれば、従来のデバッガ・タイプのツールだけでなく、ポストモーテム診断の際や、ツールが非協力的なプロセス(ハングアップ・プロセスなど)に接続する必要があるシナリオで役に立つツールを開発することもできます。