Java SE 24およびJDK 24
機械翻訳について

javaコマンド

名前

java - Javaアプリケーションを起動

シノプシス

クラス・ファイルを起動するには:

java [options] mainclass [args ...]

JARファイルのメイン・クラスを起動するには:

java [options] -jar jarfile [args ...]

モジュールのメイン・クラスを起動するには:

java [options] -m module[/mainclass] [args ...]

or

java [options] --module module[/mainclass] [args ...]

ソース・ファイル・プログラムを起動するには:

java [options] source-file [args ...]

options
オプション: 空白で区切られたコマンド行オプションを指定します。 使用可能なオプションの説明は、「javaのオプションの概要」を参照してください。
mainclass
起動するクラスの名前を指定します。 classnameに続くコマンドライン・エントリは、mainメソッドの引数です。
-jar jarfile
JARファイルにカプセル化されたプログラムを実行します。 jarfile引数は、アプリケーションの開始点として機能するpublic static void main(String[] args)メソッドを使用してクラスを定義する、Main-Class: classname形式の行を含むマニフェストを含むJARファイルの名前です。 -jarを使用すると、指定したJARファイルがすべてのユーザー・クラスのソースとなり、他のクラスパス設定は無視されます。 JARファイルを使用している場合は、jarを参照してください。
-mまたは--module module [/ mainclass]

mainclassが指定した場合は、mainclassによって指定されたモジュール内のメイン・クラスを実行し、指定されていない場合は、module内の値を実行します。 つまり、mainclassは、モジュールによって指定されない場合や、指定されている場合に値をオーバーライドする場合に使用できます。

「javaの標準オプション」を参照してください。

source-file
ソース・ファイル・プログラムの起動にのみ使用されます。 ソース・ファイル・モードを使用する場合に、メイン・クラスが含まれているソース・ファイルを指定します。 「ソース・ファイル・モードを使用したソース・コード・プログラムの起動」を参照
args ...
オプション: さらに、mainclass、source-file、-jar jarfile、および-mまたは--module module / mainclassの引数がメイン・クラスに引数として渡されます。

説明

javaコマンドはJavaアプリケーションを起動します。 それには、Java Virtual Machine (JVM)を起動し、指定されたクラスをロードして、そのクラスmain()メソッドを呼び出します。 このメソッドは、publicおよびstaticを宣言する必要があり、値を返すことはできません。また、パラメータとしてString配列を受け入れる必要があります。 メソッド宣言の形式は次のとおりです。

public static void main(String[] args)

ソース・ファイル・モードでは、javaコマンドはソース・ファイルで宣言されたクラスを起動できます。 ソース・ファイル・モードの使用方法については、「ソース・ファイル・モードを使用したソース・コード・プログラムの起動」を参照してください。

ノート: JDK_JAVA_OPTIONSランチャ環境変数を使用すると、その内容をjavaランチャの実際のコマンド行に付加できます。 「JDK_JAVA_OPTIONSランチャ環境変数の使用方法」を参照してください。

デフォルトでは、javaコマンドのオプションではない最初の引数は、コールされるクラスの完全修飾名です。 -jarが指定されている場合、その引数は、アプリケーションのクラスおよびリソース・ファイルを含むJARファイルの名前です。 起動クラスは、マニフェスト・ファイルのMain-Classマニフェスト・ヘッダーで指定する必要があります。

クラス・ファイル名またはJARファイル名の後にある引数は、main()メソッドに渡されます。

javaw

Windows: javawコマンドは、javaと同じです。ただし、javawにはコンソール・ウィンドウが関連付けられていない点が異なります。 コマンド・プロンプト・ウィンドウが表示されないようにする場合は、javawを使用します。 ただし、javawランチャは、起動に失敗すると、エラー情報を示すダイアログ・ボックスを表示します。

ソース・ファイル・モードを使用したソース・コード・プログラムの起動

ソース・ファイルで宣言されたクラスを起動するには、javaランチャをソース・ファイル・モードで実行します。 ソース・ファイル・モードの入力は、javaコマンドラインの2つのアイテムによって決まります:

クラスが.java拡張子を持つ既存のファイルを識別する場合、または--sourceオプションが指定されている場合は、ソース・ファイル・モードが選択されます。 その後で、ソース・ファイルがコンパイルされて実行されます。 --sourceオプションを使用すると、ソース・コードのソースversionまたはNを指定できます。 これにより、使用可能なAPIが決まります。 --source Nを設定する場合は、JDK Nで定義された公開APIのみを使用できます。

ノート: リリースごとにNの有効な値が変更され、新しい値が追加され、古い値が削除されます。 サポートされなくなったNの値を使用すると、エラー・メッセージが表示されます。 Nでサポートされている値は、現在のJava SEリリースの(24)、およびjavac、--sourceおよび--releaseオプションの下のコマンドライン・ヘルプに記載されている限られた数の以前のリリースです。

ファイルに.java拡張子がない場合は、--sourceオプションを使用して、javaコマンドにソース・ファイル・モードを使用するように指示する必要があります。 --sourceオプションは、ソース・ファイルが実行される"script"であり、ソース・ファイルの名前がJavaソース・ファイルの通常の命名規則に従っていない場合に使用されます。

ソース・ファイル・モードでは、ソース・ファイルがメモリーにコンパイルされた場合と同様に、ソース・ファイル内で最初に検出されたクラスが実行されます。 元のコマンド行でソース・ファイル名の後に引数が指定されていた場合、それらの引数はコンパイル済クラスの実行時に、そのコンパイル済クラスに渡されます。

たとえば、ファイルがHelloWorld.javaという名前で、HelloWorldという名前のクラスが含まれていた場合、クラスを起動するsource-file modeコマンドは次のようになります。

java HelloWorld.java

このソース・ファイル・モードの使用は、次の2つのコマンドを使用することと非公式に同等です。

javac -d <memory> --source-path <source-root> HelloWorld.java
java --class-path <memory> HelloWorld

ここで、<source-root>が計算されます。

ソース・ファイル・モードでは、追加のコマンド行オプションは次のように処理されます:

ソース・ファイル・モードでは、次のようにコンパイルが続行されます:

ソース・ファイル・モードでは、次のように実行されます:

詳細は、「JEP 458: 複数ファイル・ソース・コード・プログラムの起動」を参照してください。

JDK_JAVA_OPTIONSランチャ環境変数の使用方法

JDK_JAVA_OPTIONSは、コマンド行から解析されたオプションの前にその内容を付加します。 JDK_JAVA_OPTIONS環境変数の内容は、空白文字(isspace()によって決定される)で区切られた引数のリストです。 これらは、javaランチャに渡されるコマンドライン引数の前に付加されます。 環境変数に対するエンコーディング要件は、システム上のjavaコマンドラインと同じです。 JDK_JAVA_OPTIONS環境変数コンテンツは、コマンドラインで指定されたものと同じ方法で処理されます。

単一の(')または二重(")引用符を使用して、空白文字を含む引数を囲みます。 開始引用符と対応する最初の終了引用符の間の内容すべてが引用符のペアを除いて保存されます。 一致する引用符が見つからない場合、ランチャはエラー・メッセージで中止します。@ファイルは、コマンド行で指定されているとおりにサポートされています。 JDK_JAVA_OPTIONS環境変数のコンテンツに含まれるワイルドカード・リテラル*は展開されず、そのまま開始VMに渡されます。 JDK_JAVA_OPTIONS動作の潜在的な誤用を軽減するために、メイン・クラス (-jarなど)を指定するオプション、またはメイン・クラス (-hなど)を実行せずにjavaランチャを終了させるオプションは、環境変数では許可されません。 このようなオプションのいずれかが環境変数に指定されている場合、ランチャはエラー・メッセージを発行して停止します。 JDK_JAVA_OPTIONSが設定されている場合、ランチャはメッセージを標準エラー出力にリマインダとして出力します。

例:

$ export JDK_JAVA_OPTIONS='-g @file1 -Dprop=value @file2 -Dws.prop="white spaces"'
$ java -Xint @file3

これは次のコマンド行と同等です。

java -g @file1 -Dprop=value @file2 -Dws.prop="white spaces" -Xint @file3

javaのオプションの概要

javaコマンドは、次のカテゴリで幅広いオプションをサポートしています:

拡張オプションは、不用意に使用しないことをお薦めします。 これらは、特定のシステム要件があり、システム構成パラメータに特権付きアクセスを必要とするようなJava HotSpot仮想マシンの操作の特定の領域のチューニングに使用するための開発者用オプションです。 パフォーマンス・チューニングのいくつかの例が「パフォーマンス・チューニングの例」で提供されています。 これらのオプションは、すべてのJVM実装でサポートされている保証はなく、変更されることがあります。 拡張オプションは-XXから始まります。

ブール・オプションは、デフォルトで無効にされている機能を有効にするか、デフォルトで有効にされている機能を無効にするために使用します。 このようなオプションはパラメータを必要としません。 ブール-XXオプションは、プラス記号を使用して有効にし(-XX:+OptionName)、マイナス記号を使用して無効にします(-XX:-OptionName)。

引数を必要とするオプションの場合、引数とオプション名はスペース、コロン(:)または等号(=)で区切るか、またはオプションの後に直接引数を続けることもできます(正確な構文はオプションごとに異なります)。 サイズをバイト単位で指定する場合は、サフィクスを使用しないか、キロバイト(KB)にサフィクスkまたはKを使用するか、メガバイト(MB)にmまたはM、またはギガバイト(GB)にgまたはGを使用することができます。 たとえば、サイズを8Gバイトに設定するには、引数として、8g、8192m、8388608kまたは8589934592と指定できます。 パーセンテージを指定する必要がある場合は、0から1までの数値を使用します。 たとえば、25%には0.25を指定します。

次のセクションでは、非推奨、廃止、および削除されるオプションについて説明します:

javaの標準オプション

これらは、JVMのすべての実装でサポートされる最も一般的に使用されるオプションです。

ノート: ロング・オプションの引数を指定する場合、--name=valueまたは--name valueを使用できます。

-agentlib:libname[=options]

指定したネイティブ・エージェント・ライブラリをロードします。 ライブラリ名の後に、ライブラリに固有のオプションのカンマ区切りのリストを使用できます。 オプション-agentlib:fooが指定されている場合、JVMはプラットフォーム固有のネーミング規則およびロケーションを使用して、fooという名前のライブラリをロードしようとします:

  • Linuxおよびその他のPOSIXのようなプラットフォーム: JVMは、LD_LIBRARY_PATHシステム変数で指定されたロケーションにlibfoo.soという名前のライブラリをロードしようとします。

  • macOS: JVMは、DYLD_LIBRARY_PATHシステム変数で指定されたロケーションにlibfoo.dylibという名前のライブラリをロードしようとします。

  • Windows: JVMは、PATHシステム変数で指定されたロケーションにfoo.dllという名前のライブラリをロードしようとします。

    次の例では、ava Debug Wire Protocol (JDWP)ライブラリをロードし、ポート8000でソケット接続をリスニングし、メイン・クラスのロード前にJVMを一時停止する方法を示しています。

    -agentlib:jdwp=transport=dt_socket,server=y,address=8000

-agentpath:pathname[=options]
絶対パス名で指定されたネイティブ・エージェント・ライブラリをロードします。 このオプションは-agentlibと同等ですが、ライブラリのフル・パスとファイル名を使用します。
--class-path classpath、-classpath classpathまたは-cp classpath

クラス・ファイルを検索するディレクトリ、JARファイルおよびZIPアーカイブのリストを指定します。

Windowsでは、セミコロン(;)によってこのリストのエンティティが分離されます。他のプラットフォームでは、コロン(:)です。

classpathを指定すると、CLASSPATH環境変数の設定がオーバーライドされます。 クラス・パス・オプションが使用されておらず、classpathが設定されていない場合、ユーザー・クラス・パスは現在のディレクトリ(.)で構成されます。

特殊な便宜上、アスタリスク(*)のベース名を含むクラスパス要素は、.jarまたは.JARという拡張子でディレクトリ内のすべてのファイルのリストを指定するのと同等です。 Javaプログラムはこの2つの呼出しの違いを認識できません。 たとえば、mydirディレクトリにa.jarとb.JARが含まれる場合、クラス・パス要素mydir/*はA.jar:b.JARに拡張されますが、JARファイルの順序は指定されていません。 指定されたディレクトリ内のすべての.jarファイル(隠しファイルも含む)がリストに含まれます。 アスタリスク(*)からなるクラス・パス・エントリは、現在のディレクトリ内のすべてのjarファイルのリストに展開されます。 CLASSPATH環境変数(定義されているとき)も同様に展開されます。 Java VMの起動前に発生するクラスパスのワイルドカード展開。 Javaプログラムでは、System.getenv("CLASSPATH")をコールするなどして環境を問い合せる以外は、拡張されていないワイルドカードは表示されません。

--disable-@files
コマンドライン上の任意の場所(引数ファイル内も含む)で使用して、@filenameの拡張を回避できます。 このオプションでは、オプションのあとで@-argfilesの展開を停止します。
--enable-preview
クラスがリリースの「プレビュー機能」に依存できるようにします。
--enable-native-access module[,module...]

ネイティブ・アクセスには、Javaランタイム外のコードまたはデータへのアクセスが含まれます。 これは一般的に安全ではなく、誤って実行するとJVMがクラッシュしたり、メモリーが破損したりする可能性があります。 ネイティブ・アクセスは、「制限付き」またはnativeのいずれかのメソッドをコールした結果として発生する可能性があります。 このオプションを使用すると、指定したモジュールのコードでネイティブ・アクセスを実行できます。 明示的に有効化されていないモジュールで発生するネイティブ・アクセスは、illegalと見なされます。

moduleはモジュール名、またはクラス・パスのコードを示すALL-UNNAMEDです。

---illegal-native-access=parameter

このオプションは、不正なネイティブ・アクセスがどのように処理されるかを示すモードを指定します:

ノート: このオプションは今後のリリースで削除される予定です。

  • allow: このモードでは、すべてのモジュールで不正なネイティブ・アクセスを、警告なしで許可します。

  • warn: このモードは、モジュールで最初に検出された不正なネイティブ・アクセスに対して警告メッセージが発行される点を除き、allowと同じです。 このモードは、現在のJDKのデフォルトですが、将来のリリースでは変更される予定です。

  • deny: このモードでは、不正なネイティブ・アクセスが無効になります。 つまり、不正なネイティブ・アクセスによってIllegalCallerExceptionが発生します。 このモードは、将来のリリースでデフォルトとなる予定です。

アプリケーションが将来のバージョンのJDKに対応できることを確認するには、必要な--enable-native-accessオプションとともに--illegal-native-access=denyを指定して実行します。

--finalization=value
JVMがオブジェクトのファイナライズを実行するかどうかを制御します。 有効な値は、"enabled"および"disabled"です。 ファイナライズはデフォルトで有効になっているため、値"enabled"は何もしません。 値"disabled"は、ファイナライザが起動されないように、ファイナライズを無効にします。
--module-path modulepath... or -p modulepath

パス要素のリストを含むアプリケーション・モジュールの検索場所を指定します。 モジュール・パスの要素は、モジュールへのファイル・パス、またはモジュールを含むディレクトリです。 各モジュールは、モジュラJARまたは展開モジュール・ディレクトリです。

Windowsでは、セミコロン(;)はこのリスト内の個別のパス要素です。他のプラットフォームでは、コロン(:)です。

--upgrade-module-path modulepath...

ランタイム・イメージ内のアップグレード可能モジュールのモジュール置換をパス要素のリストとともに検索する場所を指定します。 モジュール・パスの要素は、モジュールへのファイル・パス、またはモジュールを含むディレクトリです。 各モジュールは、モジュラJARまたは展開モジュール・ディレクトリです。

Windowsでは、セミコロン(;)はこのリスト内の個別のパス要素です。他のプラットフォームでは、コロン(:)です。

--add-modules module[,module...]
初期モジュールに加えて解決するルート・モジュールを指定します。moduleには、ALL-DEFAULT、ALL-SYSTEMおよびALL-MODULE-PATHを指定することもできます。
--list-modules
参照可能なモジュールをリストして終了します。
-d module_nameまたは--describe-module module_name
指定されたモジュールの説明を表示して終了します。
--dry-run
VMを作成しますが、メイン・メソッドは実行しません。 この--dry-runオプションは、モジュール・システム構成などのコマンド行オプションを検証する場合に役立つことがあります。
--validate-modules
すべてのモジュールを検証して終了します。 このオプションは、モジュール・パス上のモジュールで競合などのエラーを検出する場合に役立ちます。
-Dproperty=value
システム・プロパティの値を設定します。 property変数はプロパティの名前を表すスペースなしの文字列です。 value変数はプロパティの値を表す文字列です。 valueがスペースのある文字列の場合、それを引用符で囲みます(-Dfoo="foo bar"など)。
-disableassertions[:[packagename]...|:classname]または-da[:[packagename]...|:classname]

アサーションを無効にします。 デフォルトでは、すべてのパッケージとクラスでアサーションは無効になっています。 引数なしで、-disableassertions (-da)は、すべてのパッケージとクラスでアサーションを無効にします。 ...で終わるpackagename引数を指定すると、スイッチは指定したパッケージとサブパッケージ内でアサーションを無効にします。 引数が...のみの場合、スイッチは現在の作業ディレクトリにある名前のないパッケージ内でアサーションを無効にします。 classname引数を指定すると、スイッチは指定したクラス内でアサーションを無効にします。

-disableassertions (-da)オプションは、すべてのクラス・ローダーおよびシステム・クラス (クラス・ローダーがない)に適用されます。 このルールには1つの例外があります。引数なしでオプションが指定された場合、システム・クラスには適用されません。 これにより、システム・クラスを除くすべてのクラスでアサーションを簡単に無効にできます。 -disablesystemassertionsオプションは、すべてのシステム・クラスでアサーションを無効にできます。 特定のパッケージまたはクラスでアサーションを明示的に有効にするには、-enableassertions (-ea)オプションを使用します。 両方のオプションを同時に使用することはできません。 たとえば、パッケージcom.wombat.fruitbat (サブパッケージ)で有効になっているが、クラスcom.wombat.fruitbat.Brickbatで無効になっているアサーションを使用してMyClassアプリケーションを実行するには、次のコマンドを使用します:

java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat MyClass

-disablesystemassertionsまたは-dsa
すべてのシステム・クラス内でアサーションを無効にします。
-enableassertions[:[packagename]...|:classname]または-ea[:[packagename]...|:classname]

アサーションを有効にします。 デフォルトでは、すべてのパッケージとクラスでアサーションは無効になっています。 引数なしで、-enableassertions (-ea)は、すべてのパッケージとクラスでアサーションを有効にします。 ...で終わるpackagename引数を指定すると、スイッチは指定したパッケージとすべてのサブパッケージ内でアサーションを有効にします。 引数が...のみの場合、スイッチは現在の作業ディレクトリにある名前のないパッケージ内でアサーションを有効にします。 classname引数を指定すると、スイッチは指定したクラス内でアサーションを有効にします。

-enableassertions (-ea)オプションは、すべてのクラス・ローダーおよびシステム・クラス (クラス・ローダーがない)に適用されます。 このルールには1つの例外があります。引数なしでオプションが指定された場合、システム・クラスには適用されません。 これにより、システム・クラスを除くすべてのクラスでアサーションを簡単に有効にできます。 -enablesystemassertionsオプションは、すべてのシステム・クラスでアサーションを有効にするために個別のスイッチを提供します。 特定のパッケージまたはクラスでアサーションを明示的に無効にするには、-disableassertions (-da)オプションを使用します。 単一のコマンドにこれらのスイッチのインスタンスを複数指定した場合は、指定したスイッチが順番に処理されてからクラスがロードされます。 たとえば、パッケージcom.wombat.fruitbat (サブパッケージ)でのみ有効になっているが、クラスcom.wombat.fruitbat.Brickbatでは無効になっているアサーションを使用してMyClassアプリケーションを実行するには、次のコマンドを使用します:

java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat MyClass

-enablesystemassertionsまたは-esa
すべてのシステム・クラス内でアサーションを有効にします。
-help、-hまたは-?
ヘルプ・メッセージをエラー・ストリームに出力します。
--help
ヘルプ・メッセージを出力ストリームに出力します。
-javaagent:jarpath[=options]
指定したJavaプログラミング言語エージェントをロードします。 java.lang.instrumentを参照してください。
--show-version
製品バージョンを出力ストリームに出力して続行します。
-showversion
製品バージョンをエラー・ストリームに出力して続行します。
--show-module-resolution
起動時にモジュール解決出力を表示します。
-splash:imagepath

imagepathで指定されたイメージのスプラッシュ画面を表示します。 利用可能であれば、HiDPIスケーリングされたイメージは自動的にサポートされ、使用されます。 スケーリングされていないイメージ・ファイル名(image.extなど)は、常に-splashオプションの引数として渡される必要があります。 指定された最も適切なスケーリング済のイメージが自動的に選択されます。

たとえば、アプリケーションの起動時に、imagesディレクトリのsplash.gifファイルを表示するには、次のオプションを使用します。

-splash:images/splash.gif

詳細は、SplashScreen APIのドキュメントを参照してください。

-verbose:class
ロードされる各クラスに関する情報を表示します。
-verbose:gc
各ガベージ・コレクション(GC)イベントに関する情報を表示します。
-verbose:jni
ネイティブ・メソッドおよびその他のJava Native Interface (JNI)アクティビティの使用に関する情報を表示します。
-verbose:module
使用中のモジュールに関する情報を表示します。
--version
製品バージョンを出力ストリームに出力して終了します。
-version
製品バージョンをエラー・ストリームに出力して終了します。
-X
余分なオプションに関するヘルプをエラー・ストリームに出力します。
--help-extra
余分なオプションに関するヘルプを出力ストリームに出力します。
@argfile

javaコマンドで使用される@のプレフィクスが付いた1つ以上の引数ファイルを指定します。 クラスパスで.jarファイルが必要なため、javaコマンドラインが長すぎることは珍しくありません。 @argfileオプションは、シェル展開後で引数ファイルの内容を展開するためにランチャを有効にし、引数の処理前に、コマンド行の長さ制限を解決します。 引数ファイルの内容は、それ以外の場合は--disable-@filesオプションが見つかるまでコマンドラインに指定されるため、展開されます。

引数ファイルには、メイン・クラス名とすべてのオプションも含めることができます。 引数ファイルにjavaコマンドで必要なすべてのオプションが含まれている場合、コマンドラインは次のようになります:

java @argfile

@-argfilesの使用例については、「javaコマンドライン引数ファイル」を参照してください。

javaの追加オプション

次のjavaオプションは、Java HotSpot仮想マシンに固有の汎用オプションです。

-Xbatch
バックグラウンド・コンパイルを無効にします。 デフォルトで、JVMは、メソッドをバックグラウンド・タスクとしてコンパイルし、バックグラウンド・コンパイルが終了するまでインタプリタ・モードでメソッドを実行します。 -Xbatchフラグは、バックグラウンド・コンパイルを無効にするため、すべてのメソッドのコンパイルが完了するまでフォアグラウンド・タスクとして処理されます。 このオプションは-XX:-BackgroundCompilationと同等です。
-Xbootclasspath/a:directories|zip|JAR-files

デフォルトのブートストラップ・クラス・パスの末尾に追加するディレクトリ、JARファイル、およびZIPアーカイブのリストを指定します。

Windowsでは、セミコロン(;)によってこのリストのエンティティが分離されます。他のプラットフォームでは、コロン(:)です。

-Xcheck:jni

Java Native Interface (JNI)機能に対して追加チェックを行います。

次のチェックは、ネイティブ・コードで重大な問題を示しており、このような場合、JVMは回復不能なエラーで終了します:

  • コールを実行しているスレッドはJVMにアタッチされていません。
  • コールを実行するスレッドは、別のスレッドに属するJNIEnvを使用しています。
  • パラメータ検証チェックは失敗します:
    • jfieldIDまたはjmethodIDが無効として検出されます。 たとえば:
      • 間違った型
      • 間違ったクラスに関連付けられます
    • 間違ったタイプのパラメータが検出されました。
    • 無効なパラメータ値が検出されました。 たとえば:
      • 許可されないNULL
      • バインド外配列索引またはフレーム・キャパシティ
      • UTF-8以外の文字列
      • 無効なJNI参照
      • 対応するGetXXXファンクションで作成されていないパラメータに対してReleaseXXXファンクションを使用しようとした場合

次のチェックのみで警告が出力されます:

  • 以前のJNIコールから保留中の例外をチェックせずにJNIコールが行われ、例外が保留されている可能性がある場合、現在のコールは安全ではありません。
  • クラス記述子の形式は、(Lname;)にならないと修飾されます。
  • NULLパラメータは使用できますが、その使用には問題があります。
  • Get/ReleasePrimitiveArrayCriticalまたはGet/ReleaseStringCriticalの範囲で他のJNI関数を呼び出す

このオプションを使用すると、パフォーマンス低下が予想されます。

-Xcomp
JITコンパイラを実行するテスト・モード。 このオプションは、本番環境では使用しないでください。
-Xdebug
何も行いません。将来のリリースで削除のために非推奨になりました。
-Xdiag
追加の診断メッセージを表示します。
-Xint
インタプリタ専用モードでアプリケーションを実行します。 ネイティブ・コードへのコンパイルは無効になり、すべてのバイト・コードがインタプリタによって実行されます。 Just-In-Time (JIT)コンパイラが提供するパフォーマンス上の利点は、このモードでは実現されません。
-Xinternalversion
-versionオプションよりも詳しいJVMバージョン情報を表示して、終了します。
-Xlog:option
Java仮想マシン(JVM)統合ロギング・フレームワークを使用したロギングを構成または有効にします。 「JVM統合ログ・フレームワークでのログを有効にします」を参照してください。
-Xmixed
ネイティブ・コードにコンパイルされるホット・メソッドを除くすべてのバイトコードをインタプリタによって実行します。 デフォルトで有効 -Xintを使用してオフに切り替えます。
-Xmn size

若い世代(ナーサリ)が世代コレクタで生成するためのヒープの初期サイズおよび最大サイズ(バイト単位)を設定します。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 ヒープのYoung世代領域は新しいオブジェクトに使用されます。 この領域では他の領域よりも頻繁にGCが実行されます。 Young世代のサイズが小さすぎる場合は、大量のマイナー・ガベージ・コレクションが実行されます。 そのサイズが大きすぎる場合は、フル・ガベージ・コレクションのみが実行されますが、これは完了までに長時間かかることがあります。 G1コレクタの若い世代のサイズを設定せず、他のコレクタの全体的なヒープ・サイズの25%より大きく50%未満のサイズを維持することをお薦めします。 次の例では、様々な単位を使用して、Young世代の初期および最大サイズを256Mバイトに設定する方法を示します。 

-Xmn256m
-Xmn262144k
-Xmn268435456

Young世代のヒープの初期サイズと最大サイズの両方を設定する-Xmnオプションの代わりに、-XX:NewSizeを使用して、初期サイズを設定し、-XX:MaxNewSizeを使用して、最大サイズを設定できます。

-Xms size

ヒープの最小サイズおよび初期サイズ(バイト単位)を設定します。 この値は、1024の倍数で、1Mバイトより大きくなければなりません。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 次の例では、様々な単位を使用して、割り当てられたメモリーのサイズを6Mバイトに設定する方法を示します。 

-Xms6291456
-Xms6144k
-Xms6m

このオプションを設定しない場合、初期サイズは、Old世代とYoung世代に割り当てられたサイズの合計として設定されます。 Young世代のヒープの初期サイズは、-Xmnオプションまたは-XX:NewSizeオプションを使用して設定できます。

-XX:InitialHeapSizeオプションを使用して初期ヒープ・サイズを設定することもできます。 コマンドラインで-Xmsの後に表示される場合、初期ヒープ・サイズは-XX:InitialHeapSizeで指定された値に設定されます。

-Xmx size

ヒープの最大サイズの(バイト単位)を指定します。 この値は、1024の倍数で、2Mバイトより大きくなければなりません。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 デフォルト値は、実行時にシステムの設定に基づいて選択されます。 サーバー配備の場合、-Xmsと-Xmxが同一の値に設定されていることがよくあります。 次の例では、様々な単位を使用して、割り当てられたメモリーの最大許容サイズを80Mバイトに設定する方法を示します。 

-Xmx83886080
-Xmx81920k
-Xmx80m

-Xmxオプションは-XX:MaxHeapSizeと同等です。

-Xnoclassgc
クラスのガベージ・コレクション(GC)を無効にします。 これによりいくらかのGC時間が節約され、アプリケーション実行時の割込みが短くなります。 起動時に-Xnoclassgcを指定すると、アプリケーションのクラス・オブジェクトはGC中は変更されず、常にライブとみなされます。 これにより、より多くのメモリーが永続的に占有されることになるため、慎重に使用しないと、メモリー不足の例外がスローされる可能性があります。
-Xrs

JVMによるオペレーティング・システム・シグナルの使用を減らします。 シャットダウン・フックにより、JVMが突然終了した場合でも、シャットダウン時にユーザー・クリーン・アップ・コード(データベース接続のクローズなど)を実行して、Javaアプリケーションの正常なシャットダウンができるようになりました。

  • Windows以外:

    • JVMは、シグナルをキャッチすることによって、異常終了のためのシャットダウン・フックを実装します。 JVMは、SIGHUP、SIGINT、およびSIGTERMを使用して、シャットダウン・フックの実行を開始します。

    • JVMを埋め込んでいるアプリケーションがSIGINTやSIGTERMなどのシグナルを頻繁にトラップする必要があると、JVMのシグナル・ハンドラの処理に支障が出る可能性があります。 -Xrsオプションを使用すると、この問題に対処できます。 -Xrsを使用する場合、SIGINT、SIGTERM、SIGHUPおよびSIGQUITのシグナル・マスクはJVMによって変更されず、これらのシグナルのシグナル・ハンドラはインストールされません。

  • Windows:

    • JVMは、コンソール制御イベントを監視して予期しない終了のシャットダウン・フックを実装します。 具体的には、JVMは、シャットダウン・フック処理を開始するコンソール制御ハンドラを登録し、CTRL_C_EVENT、CTRL_CLOSE_EVENT、CTRL_LOGOFF_EVENTおよびCTRL_SHUTDOWN_EVENTに対してTRUEを返します。

    • JVMは、デバッグ用のスレッド・スタックをダンプする機能を実現するためにも、同様のメカニズムを使用します。 JVMは、スレッド・ダンプを実行するためにCTRL_BREAK_EVENTを使用します。

    • JVMがサービスとして実行されている場合(たとえば、Webサーバーのサーブレット・エンジンとして)、JVMはCTRL_LOGOFF_EVENTを受信できますが、オペレーティング・システムが実際にプロセスを終了しないため、停止を開始しないでください。 このような干渉の可能性を避けるため、-Xrsオプションを使用できます。 -Xrsオプションを使用すると、JVMはコンソール制御ハンドラをインストールしません。これは、CTRL_C_EVENT、CTRL_CLOSE_EVENT、CTRL_LOGOFF_EVENTまたはCTRL_SHUTDOWN_EVENTを監視または処理しないことを意味します。

-Xrsを指定した場合は、2つの影響があります。

  • 非Windows: SIGQUITスレッド・ダンプは使用できません。

  • Windows: Ctrl + Breakスレッド・ダンプは使用できません。

シャットダウン・フックの実行は、JVMが終了しようとしている時点でSystem.exit()を呼び出すなどして、ユーザー・コード側で行います。

-Xshare:mode

クラス・データ共有(CDS)モードを設定します。

このオプションのmode引数には次を指定できます。

auto
可能な場合は共有クラス・データを使用します(デフォルト)
on
共有クラス・データの使用が必須で、使用しないと失敗します。

ノート: -Xshare:onオプションは、テスト目的でのみ使用されます。 CDSアーカイブを使用できない場合(たとえば、特定のVMパラメータが変更された場合や、別のJDKが使用されている場合)、起動時にVMが予期せず終了することがあります。 このオプションは、本番環境では使用しないでください。

off
共有クラス・データを使用しないようにします。
-XshowSettings
すべての設定を表示してから、続行します。
-XshowSettings:category

設定を表示し、続行します。 このオプションのcategory引数には次を指定できます。

all
すべてのカテゴリの設定を「冗長」の詳細に表示します。
locale
ロケールに関連する設定を表示します。
properties
システム・プロパティに関連する設定を表示します。
security

セキュリティに関連するすべての設定を表示します。

securityのサブカテゴリ引数には、次のものがあります:

  • security:all : すべてのセキュリティ設定を表示
  • security:properties : セキュリティ・プロパティを示します
  • security:providers : 静的セキュリティ・プロバイダ設定の表示
  • security:tls : TLS関連のセキュリティ設定を表示
vm
JVMの設定を表示します。
system
Linuxのみ: ホスト・システムまたはコンテナの構成を表示し、続行します。
-Xss size

スレッド・スタック・サイズ(バイト単位)を設定します。 文字kまたはKを追加してKBを示し、mまたはMはMBを示し、gまたはGはGBを示します。 実際のサイズは、オペレーティングが必要とするシステム・ページ・サイズの倍数に切り上げることができます。 デフォルト値はプラットフォームによって異なります。 たとえば:

  • Linux/x64: 1024 KB

  • Linux/Aarch64: 2048 KB

  • macOS/x64: 1024 KB

  • macOS/Aarch64: 2048 KB

  • Windows: デフォルト値は仮想メモリーに依存

次の例では、様々な単位でスレッド・スタック・サイズを1024Kバイトに設定します。

-Xss1m
-Xss1024k
-Xss1048576

このオプションは、-XX:ThreadStackSizeと似ています。

--add-reads module=target-module(,target-module)*
モジュール宣言に関係なく、moduleを更新してtarget-moduleを読み取ります。target-moduleをALL-UNNAMEDにすると、名前のないすべてのモジュールを読み取ることができます。
--add-exports module/package=target-module(,target-module)*
モジュール宣言に関係なく、moduleを更新し、packageをtarget-moduleにエクスポートします。target-moduleをALL-UNNAMEDにすると、名前のないすべてのモジュールにエクスポートできます。
--add-opens module/package=target-module(,target-module)*
モジュール宣言に関係なく、moduleを更新してpackageからtarget-moduleを開きます。
--limit-modules module[,module...]
観測可能なモジュールのユニバースの制限を指定します。
--patch-module module=file(;file)*
JARファイルまたはディレクトリ内のクラスおよびリソースでモジュールをオーバーライドまたは拡張します。
--source version
ソース・ファイル・モードのソースのバージョンを設定します。
--sun-misc-unsafe-memory-access= value

サポートされていないAPI sun.misc.Unsafeの使用を許可または拒否します。valueは次のいずれかです:

allow
実行時に警告なしでメモリー・アクセス・メソッドを使用できます。
warn
メモリー・アクセス・メソッドの使用を許可しますが、メモリー・アクセス・メソッドが最初に使用される場合は警告を発行します。 最大1つの警告が発行されます。
debug
メモリー・アクセス・メソッドの使用を許可しますが、メモリー・アクセス・メソッドが使用されている場合は、1行の警告とスタック・トレースを発行します。
deny
使用量ごとにUnsupportedOperationExceptionをスローして、メモリー・アクセス・メソッドの使用を許可しません。

このオプションを指定しない場合のデフォルト値はwarnです。

macOSの追加オプション

macOS固有のオプションは、次のとおりです。

-XstartOnFirstThread
最初の(AppKit)スレッドでmain()メソッドを実行します。
-Xdock:name=application_name
ドックに表示されるデフォルトのアプリケーション名をオーバーライドします。
-Xdock:icon=path_to_icon_file
ドックに表示されるデフォルトのアイコンをオーバーライドします。

Javaの詳細なオプション

これらのjavaオプションは、その他の詳細オプションを使用可能にする場合に使用できます。

-XX:+UnlockDiagnosticVMOptions

JVMの診断目的のオプションをロック解除します。 デフォルトでは、このオプションは無効になっており、診断オプションを使用できません。

このオプションを使用して有効化されているコマンド行オプションはサポートされていません。 これらのオプションの使用時に問題が発生した場合は、Oracle Supportで調査を支援する前に、サポートされていないこれらのオプションを使用しないと問題を再現する必要がある可能性が高くなります。 これらのオプションを削除したり、その動作を警告なしに変更したりすることもできます。

-XX:+UnlockExperimentalVMOptions
JVMに実験的な機能を提供するオプションのロックを解除します。 デフォルトでは、このオプションは無効になっており、試験的機能は使用できません。

javaの拡張ランタイム・オプション

これらのjavaオプションは、Java HotSpot VMの実行時動作を制御します。

-XX:ActiveProcessorCount=x

ガベージ・コレクションやForkJoinPoolなどの様々な操作に使用するスレッド・プールのサイズを計算するために、VMが使用するCPUの数をオーバーライドします。

通常、VMはオペレーティング・システムから使用可能なプロセッサの数を決定します。 このフラグは、Dockerコンテナ内で複数のJavaプロセスを実行するときに、CPUリソースをパーティション化するために役立ちます。 UseContainerSupportが有効になっていない場合でも、このフラグが使用されます。 コンテナのサポートの有効化および無効化の説明は、-XX:-UseContainerSupportを参照してください。

-XX:AllocateHeapAt=path

ファイル・システムへのパスを取得し、メモリー・マッピングを使用してメモリー・デバイスにオブジェクト・ヒープを割り当てます。 このオプションを使用すると、ユーザーが指定したNV-DIMMなどの代替メモリー・デバイスに、HotSpot VMがJavaオブジェクト・ヒープを割り当てられるようになります。

DRAMと同じセマンティクス(アトミック操作のセマンティクスを含む)を持つ代替メモリー・デバイスを、既存のアプリケーション・コードを変更せずに、オブジェクト・ヒープ用のDRAMのかわりに使用できます。 他のメモリー構造体(コード・ヒープ、メタスペース、スレッド・スタックなど)はすべて、引き続きDRAM内に残ります。

一部のオペレーティング・システムでは、ファイル・システムを使用して非DRAMメモリーを公開します。 これらのファイル・システムのメモリー・マップ・ファイルは、ページ・キャッシュをバイパスして、デバイスの物理メモリーに対する仮想メモリーのダイレクト・マッピングを提供します。 既存のヒープ関連のフラグ(-Xmxや-Xmsなど)およびガベージ・コレクション関連のフラグは、以前と同じように動作し続けます。

-XX:-CompactStrings

コンパクト文字列機能を無効にします。 デフォルトでは、このオプションは有効です。 このオプションが有効になっていると、シングルバイト文字のみが含まれるJava文字列は、ISO-8859-1またはLatin-1エンコーディングを使用して1文字当たり1バイトの文字列として内部的に表され、格納されます。 これにより、シングルバイト文字列のみが含まれる文字列に必要な容量が50%削減されます。 1つ以上のマルチバイト文字が含まれるJava文字列の場合、これらはUTF-16エンコーディングを使用して1文字当たり2バイトとして表され、格納されます。 コンパクト文字列機能を無効にすると、すべてのJava文字列の内部表現としてUTF-16エンコーディングが使用されます。

コンパクト・ストリングを無効にすると有益な場合があります:

  • アプリケーションで圧倒的にマルチバイト文字の文字列を割り当てることがわかっている場合

  • Java SE 8からJava SE 9への移行でパフォーマンス低下が観測され、コンパクト文字列がその低下を招いていることを分析が示している予期しないイベント

これらのシナリオの両方で、コンパクト・ストリングを無効にすることは意味があります。

-XX:ErrorFile=filename

回復不能なエラーが発生した場合に、エラー・データが書き込まれるパスとファイル名を指定します。 デフォルトでは、このファイルは、現在の作業ディレクトリとhs_err_pid pid .logという名前で作成されます。pidはエラーが発生したプロセスの識別子です。

次の例では、デフォルトのログ・ファイルを設定する方法を示します(プロセスの識別子は%pで指定されることに注意してください)。

-XX:ErrorFile=./hs_err_pid%p.log

  • 非Windows: 次の例では、エラー・ログを/var/log/java/java_error.logに設定する方法を示します :

    -XX:ErrorFile=/var/log/java/java_error.log

  • Windows: 次の例は、エラー・ログ・ファイルをC:/log/java/java_error.logに設定する方法を示しています :

    -XX:ErrorFile=C:/log/java/java_error.log

このファイルが存在し、書込み可能である場合は、上書きされます。 指定したディレクトリ(領域不足、権限の問題、または別の問題が原因)にファイルを作成できない場合、ファイルはオペレーティング・システムの一時ディレクトリに作成されます:

  • 非Windows: 一時ディレクトリは/tmpです。

  • Windows: 一時ディレクトリは、TMP環境変数の値で指定されます。その環境変数が定義されていない場合は、TEMP環境変数の値が使用されます。

-XX:+ExtensiveErrorReports
ErrorFileでより広範なエラー情報を報告できるようにします。 このオプションは、最大情報が必要な環境で有効にできます。結果のログが非常に大きい場合、または機密とみなされる可能性がある情報が含まれる場合(あるいはその両方)でも有効です。 情報は、リリースごと、異なるプラットフォーム間で異なる場合があります。 デフォルトではこのオプションは無効になっています。
-XX:FlightRecorderOptions=parameter=value (or) -XX:FlightRecorderOptions:parameter=value

JFRの動作を制御するパラメータを設定します。 複数のパラメータは、カンマで区切って指定できます。

次のリストに、使用可能なJFR parameter=valueエントリを示します:

globalbuffersize=size
データ保存に使用される主メモリーの合計量を指定します。 デフォルト値は、memorysizeに指定された値に基づきます。 memorysizeパラメータを変更して、グローバル・バッファのサイズを変更します。
maxchunksize=size
記録のデータ・チャンクの最大サイズ(バイト単位)を指定します。 mまたはMを追加して、サイズをメガバイト (MB)、またはgまたはGで指定してギガバイト (GB)で指定します。 デフォルトでは、データ・チャンクの最大サイズは12Mバイトに設定されます。 最小許容値は1 MBです。
memorysize=size
使用するバッファ・メモリーの量を決定し、指定されたサイズに基づいてglobalbuffersizeおよびnumglobalbuffersパラメータを設定します。 mまたはMを追加して、サイズをメガバイト (MB)、またはgまたはGで指定してギガバイト (GB)で指定します。 デフォルトでは、メモリー・サイズは10 MBに設定されます。
numglobalbuffers
使用するグローバル・バッファの数を指定します。 デフォルト値は指定されたメモリー・サイズに基づきます。 memorysizeパラメータを変更して、グローバル・バッファの数を変更します。
old-object-queue-size=number-of-objects
追跡する古いオブジェクトの最大数。 デフォルトでは、オブジェクトの数は256に設定されます。
preserve-repository={true|false}
JVMの終了後にディスク・リポジトリに格納されているファイルを保持するかどうかを指定します。 falseの場合、ファイルは削除されます。 デフォルトでは、このパラメータは無効になっています。
repository=path
一時ディスク・ストレージのリポジトリ(ディレクトリ)を指定します。 デフォルトでは、システムの一時ディレクトリが使用されます。
retransform={true|false}
JVMTIを使用してイベント・クラスを再変換するかどうかを指定します。 falseの場合、イベント・クラスのロード時にインストゥルメンテーションが追加されます。 デフォルトで、このパラメータは有効です。
stackdepth=depth
スタック・トレースのスタックの深さ。 デフォルトでは、この深さは64回のメソッド呼出しに設定されます。 最大値は2048です。 64よりも大きい値を指定すると、大量のオーバーヘッドが発生し、パフォーマンスが低下する可能性があります。
threadbuffersize=size
スレッドごとのローカル・バッファ・サイズ(バイト単位)を指定します。 デフォルトでは、ローカル・バッファ・サイズは8キロバイトに設定され、最小値は4キロバイトです。 このパラメータをオーバーライドするとパフォーマンスが低下する可能性があるため、お薦めしません。
-XX:LargePageSizeInBytes=size

JVMで使用される最大サイズの大きいページ・サイズ(バイト単位)を設定します。 size引数は、環境でサポートされている有効なページ・サイズで、有効にする必要があります。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 デフォルトでは、サイズは0に設定されます。つまり、JVMは、大規模ページの最大サイズとして環境に対してデフォルトの大きなページ・サイズを使用します。 「大きなページ」を参照してください。

次の例では、大きいページ・サイズを1ギガバイト(GB)に設定する方法について説明します:

-XX:LargePageSizeInBytes=1g

-XX:MaxDirectMemorySize=size

java.nioパッケージの最大合計サイズ(バイト単位)、ダイレクト・バッファ割当てを設定します。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 設定しない場合、フラグは無視され、JVMはNIO直接バッファ割当てのサイズを自動的に選択します。

次の例では、様々な単位でNIOのサイズを1024Kバイトに設定する方法を示しています。

-XX:MaxDirectMemorySize=1m
-XX:MaxDirectMemorySize=1024k
-XX:MaxDirectMemorySize=1048576
-XX:-MaxFDLimit
オープン・ファイル・ディスクリプタ数のソフト制限をハード制限に設定する試みを無効にします。 デフォルトでは、このオプションはすべてのプラットフォームで有効になっていますが、Windowsでは無視されます。 これを無効にする必要があるのはmacOSだけです。この場合、その使用によって最大10240が設定され、実際のシステムの最大値より小さくなります。
-XX:NativeMemoryTracking=mode

JVMネイティブ・メモリーの使用状況の追跡のモードを指定します。 このオプションのmode引数には次を指定できます。

off
JVMネイティブ・メモリーの使用状況を追跡しないように指示します。 -XX:NativeMemoryTrackingオプションを指定しない場合、これはデフォルトの動作です。
summary
Javaヒープ、クラス、コード、スレッドなどのJVMサブシステムによるメモリー使用状況のみを追跡します。
detail
JVMサブシステムによるメモリー使用状況の追跡に加えて、各CallSite、各仮想メモリー領域およびそのコミット済領域によるメモリー使用状況を追跡します。
-XX:TrimNativeHeapInterval=millis

JVMがネイティブ・ヒープをトリミングする間隔(ミリ秒)。 値を小さくすると、オーバーヘッドが高くなるため、メモリーがより熱心に再生されます。 0の値 (デフォルト)は、ネイティブ・ヒープ・トリミングを無効にします。 ネイティブ・ヒープ・トリミングは専用スレッドで実行されます。

このオプションは、GNU Cライブラリ (glibc)を持つLinuxでのみサポートされています。

-XX:+NeverActAsServerClassMachine

C1 JITコンパイラ、32Mb CodeCacheおよびシリアルGCのみを使用する"クライアントVMエミュレーション"モードを有効にします。 JVMで(-XX:MaxRAM=nフラグによって制御されます)を使用できるメモリーの最大量は、デフォルトで1GBに設定されています。 文字列"emulated-client"がJVMバージョン文字列に追加されます。

デフォルトでは、フラグは32ビット・モードのWindowsでのみtrueに設定され、その他の場合はfalseに設定されます。

"クライアントVMエミュレーション"モードは、コマンドラインで次のいずれかのフラグが使用されている場合、有効になりません:

-XX:{+|-}TieredCompilation
-XX:CompilationMode=mode
-XX:TieredStopAtLevel=n
-XX:{+|-}EnableJVMCI
-XX:{+|-}UseJVMCICompiler
-XX:ObjectAlignmentInBytes=alignment

Javaオブジェクトのメモリー配置を設定します(バイト単位)。 デフォルトでは、値が8バイトに設定されます。 指定する値は、2の累乗で8から256の範囲内(両端を含む)にする必要があります。 このオプションにより、大きいJavaヒープ・サイズで圧縮ポインタを使用できます。

バイト単位のヒープ・サイズ制限は次のように計算されます:

4GB * ObjectAlignmentInBytes

ノート: 整列値が増えると、オブジェクト間の未使用領域も増えます。 結果として、大きいヒープ・サイズで圧縮ポインタを使用するメリットがわからない可能性があります。

-XX:OnError=string

回復不能なエラーが発生した場合に実行するカスタム・コマンドまたは一連のセミコロン区切りのコマンドを設定します。 文字列にスペースを含む場合は、二重引用符で囲む必要があります。

  • 非Windows: 次の例は、-XX:OnErrorオプションを使用して、gcoreコマンドを実行してコア・イメージを作成し、gdbデバッガを起動して、リカバリ不能なエラー(%pは現在のプロセス識別子を指定)の場合にプロセスにアタッチする方法を示しています :

    -XX:OnError="gcore %p;gdb -p %p"

  • Windows: 次の例では、リカバリ不能なエラー(%pによって現在のプロセス識別子が指定されます。)の場合に、-XX:OnErrorオプションを使用してuserdump.exeユーティリティを実行してクラッシュ・ダンプを取得する方法を示します。 この例では、userdump.exeユーティリティへのパスがPATH環境変数に指定されていることを前提としています:

    -XX:OnError="userdump.exe %p"

-XX:OnOutOfMemoryError=string
OutOfMemoryError例外が最初にスローされた場合に実行するカスタム・コマンドまたは一連のセミコロン区切りのコマンドを設定します。 文字列にスペースを含む場合は、二重引用符で囲む必要があります。 コマンド文字列の例については、-XX:OnErrorオプションの説明を参照してください。
-XX:+PrintCommandLineFlags
コマンド行に表示されるエルゴノミクスに従って選択されたJVMフラグの出力を有効にします。 これは、ヒープ領域サイズや選択されたガベージ・コレクタなどのJVMによって設定されたエルゴノミクス値を知るために役立つ可能性があります。 デフォルトでは、このオプションは無効になっており、フラグは出力されません。
-XX:+PreserveFramePointer
RBPレジスタを汎用レジスタ (-XX:-PreserveFramePointer)として使用するか、RBPレジスタを使用して現在実行中のメソッドのフレーム・ポインタを保持するかを選択します(-XX:+PreserveFramePointer)。 フレーム・ポインタが使用可能な場合は、外部プロファイリング・ツール(Linux perfなど)でより正確なスタック・トレースを構成できます。
-XX:+PrintNMTStatistics
メモリー追跡が有効にされている場合(-XX:NativeMemoryTrackingを参照)、JVMで収集されたネイティブ・メモリー追跡データの出力を有効にします。 デフォルトでは、このオプションは無効になっており、ネイティブ・メモリー追跡データは出力されません。
-XX:SharedArchiveFile=path

クラス・データ共有(CDS)アーカイブ・ファイルのパスと名前を指定します

「アプリケーション・クラス・データ共有」を参照してください。

-XX:+VerifySharedSpaces
このオプションが指定されている場合、JVMはCRC32チェックサムに基づく整合性チェックに合格した場合にのみ、CDSアーカイブ・ファイルをロードします。 このフラグの目的は、転送またはストレージ内のCDSアーカイブ・ファイルに意図しない損傷がないかどうかを確認することです。 CDSのセキュリティおよび適切な動作を保証するために、ユーザーは、Javaアプリケーションで使用されるCDSアーカイブ・ファイルを適切な承認なしに変更できないようにする必要があります。
-XX:SharedArchiveConfigFile=shared_config_file
アーカイブ・ファイルに追加されるその他の共有データを指定します。
-XX:SharedClassListFile=file_name

クラス・データ共有(CDS)アーカイブに格納するクラスの名前を含むテキスト・ファイルを指定します。 このファイルには、スラッシュ(/)がドット(.)を置き換えることを除き、1行に1つのクラスのフルネームが含まれています。 たとえば、クラスjava.lang.Objectおよびhello.Mainを指定するには、次の2行を含むテキスト・ファイルを作成します: 

java/lang/Object
hello/Main

このテキスト・ファイルで指定するクラスには、アプリケーションでよく使用されるクラスを含める必要があります。 アプリケーション、機能拡張またはブートストラップ・クラス・パスからのあらゆるクラスが含まれる場合があります。

「アプリケーション・クラス・データ共有」を参照してください。

-XX:+ShowCodeDetailsInExceptionMessages
改善されたNullPointerExceptionメッセージの出力を有効にします。 アプリケーションがNullPointerExceptionをスローした場合、このオプションによりJVMでプログラムのバイトコード命令を分析して、どの参照がnullであるのかを正確に判断でき、null詳細メッセージが含まれるソースを記述できます。 Null詳細メッセージは、計算されてNullPointerException.getMessage()から返され、例外メッセージとしてメソッド、ファイル名および行番号とともに出力されます。 デフォルトでは、このオプションは有効です。
-XX:+ShowMessageBoxOnError
JVMで回復不能なエラーが発生した場合に、ダイアログ・ボックスの表示を有効にします。 これにより、JVMの終了を回避し、プロセスをアクティブに維持するため、これにデバッガを接続して、エラーの原因を調査できます。 デフォルトでは、このオプションは無効になっています。
-XX:StartFlightRecording:parameter=value

JavaアプリケーションのJFR記録を開始します。 このオプションは、実行時に記録を開始するJFR.start診断コマンドと同等です。-XX:StartFlightRecording:helpは、使用可能なオプションおよびコマンドラインの例を出力します。 JFRレコーディングの開始時に、次のparameter = valueエントリを設定できます:

delay=time
Javaアプリケーションの起動時間から記録を開始するまでの遅延時間を指定します。 時間を秒で指定するためにはs、分の場合はm、時間の場合はhまたは日の場合はdを追加します(たとえば、10mの指定は、10分を意味します)。 デフォルトでは、遅延はなく、このパラメータは0に設定されます。
disk={true|false}
記録中にディスクにデータを書き込むかどうかを指定します。 デフォルトで、このパラメータは有効です。
dumponexit={true|false}
JVMが停止するときに、実行中の記録をダンプするかどうかを指定します。 有効になっていて、filenameが入力されていない場合、レコーディングは、プロセスが起動されたディレクトリ内のファイルに書き込まれます。 ファイル名は、プロセスID、記録IDおよび現在のタイムスタンプを含む(hotspot-pid-47496-id-1-2018_01_25_19_10_41.jfrのような)システム生成名になります。 デフォルトでは、このパラメータは無効になっています。
duration=time
記録の継続時間を指定します。 時間を秒で指定するためにはs、分の場合はm、時間の場合はhまたは日の場合はdを追加します(たとえば、5hの指定は、5時間を意味します)。 デフォルトでは、期間は制限されず、このパラメータは0に設定されています。
filename=path

記録が停止するときに、記録が書き込まれるファイルのパスと名前を指定します。たとえば:

  • recording.jfr
  • /home/user/recordings/recording.jfr
  • c:\recordings\recording.jfr

ファイル名に%pまたは%t(あるいはその両方)が指定されている場合は、JVMのPIDおよび現在のタイムスタンプにそれぞれ拡張されます。 ファイル名は、PIDからファイル名を生成し、指定したディレクトリに現在の日付を生成するディレクトリでもあります。

name=identifier
記録の名前と識別子の両方を取ります。
maxage=time
記録用保持するディスク・データの最大保持期間を指定します。 このパラメータは、diskパラメータがtrueに設定されている場合にのみ有効です。 時間を秒で指定するためにはs、分の場合はm、時間の場合はhまたは日の場合dを追加します(たとえば、30sの指定は、30秒を意味します)。 デフォルトでは、最大経過時間は制限されず、このパラメータは0sに設定されます。
maxsize=size
記録用に保持するディスク・データの最大サイズ(バイト単位)を指定します。 このパラメータは、diskパラメータがtrueに設定されている場合にのみ有効です。 値は、-XX:FlightRecorderOptionsで設定されたmaxchunksizeパラメータの値より小さくできません。 mまたはMを追加してサイズをメガバイト単位で指定するか、gまたはGを追加してサイズをギガバイト単位で指定します。 デフォルトでは、ディスク・データの最大サイズは制限されず、このパラメータは0に設定されます。
path-to-gc-roots={true|false}

記録の終了時にガベージ・コレクション(GC)のルートへのパスを収集するかどうかを指定します。 デフォルトでは、このパラメータは無効になっています。

GCルートへのパスはメモリー・リークを探すのに役立ちますが、この収集には時間がかかります。 メモリー・リークが疑われるアプリケーションの記録を開始する場合にのみ、このオプションを有効にします。 settingsパラメータがprofileに設定されている場合、潜在的なリーク・オブジェクトの割当て元のスタック・トレースが収集される情報に含まれます。

settings=path

イベント設定ファイル(種類はJFC)のパスと名前を指定します。 デフォルトでは、JAVA_HOME/lib/jfrにあるdefault.jfcファイルが使用されます。 このデフォルト設定ファイルは低いオーバーヘッドで定義済の情報セットを収集するため、パフォーマンスに及ぼす影響は最小となり、継続的に実行される記録で使用できます。

2つ目の設定ファイルprofile.jfcも用意されており、デフォルト構成より多くのデータを提供しますが、オーバーヘッドおよびパフォーマンスに影響を与える可能性があります。 より多くの情報が必要な場合に、この構成を短期間で使用します。

複数のパラメータの値を指定するには、それらをコロンで区切ります。 イベント設定および.jfcオプションは、次の構文を使用して指定できます:

option=value
変更するオプション値を指定します。 使用可能なオプションをリストするには、JAVA_HOME/bin/jfrツールを使用します。
event-setting=value
変更するイベント設定値を指定します。 フォームの使用: <event-name>#<setting-name>=<value>。 新しいイベント設定を追加するには、イベント名の前に'+'を付けます。

複数のイベント設定および.jfcオプションの値をカンマで区切って指定できます。 パラメータと.jfcオプション間で競合する場合は、パラメータが優先されます。 空白デリミタは、タイムスパン値には省略できます。つまり20msと書けます。 設定構文の詳細は、jdk.jfrパッケージのJavadocを参照してください。

起動時にJFRからの警告とエラーのみを表示するには、 -Xlog:jfr+startup=warningを設定します。

-XX:ThreadStackSize=size

Javaスレッドのスタック・サイズ(キロバイト単位)を設定します。 kなどのスケーリング・サフィクスを使用すると、-XX:ThreadStackSize=1kがJavaスレッド・スタック・サイズを1024*1024バイトまたは1メガバイトに設定するようにキロバイト値がスケーリングされます。 デフォルト値はプラットフォームによって異なります。 たとえば:

  • Linux/x64: 1024 KB

  • Linux/Aarch64: 2048 KB

  • macOS/x64: 1024 KB

  • macOS/Aarch64: 2048 KB

  • Windows: デフォルト値は仮想メモリーに依存

次の例は、スレッド・スタック・サイズを1メガバイト単位で設定する方法を示しています:

-XX:ThreadStackSize=1k
-XX:ThreadStackSize=1024

このオプションは、-Xssと似ています。

-XX:-UseCompressedOops

圧縮されたポインタの使用を無効にします。 デフォルトではこのオプションが有効になっており、圧縮ポインタが使用されます。 これにより、自動的に最大人間工学的に決定されるJavaヒープ・サイズが、圧縮ポインタの対象とできるメモリーの最大量に制限されます。 デフォルトでは、この範囲は32 GBです。

圧縮oopが有効になっている場合、オブジェクト参照は、64ビット・ポインタではなく32ビット・オフセットとして表され、通常、圧縮されたoopsポインタ範囲より小さいJavaヒープ・サイズでアプリケーションを実行するときに、パフォーマンスが向上します。 このオプションは64ビットJVMの場合にのみ機能します。

32 GBを超えるJavaヒープ・サイズでは、圧縮ポインタを使用できます。 -XX:ObjectAlignmentInBytesオプションを参照してください。

-XX:-UseContainerSupport

Linuxのみ: VMでは、自動コンテナ検出のサポートが提供されるようになりました。これにより、VMは、dockerコンテナで実行されているJavaプロセスで使用可能なメモリーの量とプロセッサの数を決定できます。 この情報はシステム・リソースを割り当てるために使用されます。 このフラグのデフォルトはtrueで、コンテナのサポートはデフォルトで有効になっています。 -XX:-UseContainerSupportを使用して無効にできます。

このサポートに関連する問題を診断する際に、統合ロギングが役立ちます。

コンテナ情報の最大ロギングには、-Xlog:os+container=traceを使用します。 統合ロギングの使用の説明は、JVM統合ロギングフレームワークを使用したロギングの有効化を参照してください。

-XX:+UseLargePages

ラージ・ページ・メモリーの使用を有効にします。 デフォルトでは、このオプションは無効になっており、ラージ・ページ・メモリーは使用されません。

「大きなページ」を参照してください。

-XX:+UseTransparentHugePages
Linuxのみ: 動的に拡大または縮小できるラージ・ページの使用を有効にします。 このオプションはデフォルトでは無効です。 OSが他のページを移動してヒュージ・ページを作成するため、透過的ヒュージ・ページでパフォーマンスの問題が検出される場合があります。このオプションは試験的に使用できます。
-XX:+AllowUserSignalHandlers
非Windows: アプリケーションによるシグナル・ハンドラのインストールを有効にします。 デフォルトでは、このオプションは無効になっており、アプリケーションはシグナル・ハンドラをインストールできません。
-XX:VMOptionsFile=filename
ファイル内のVMオプションを指定できます(例:java -XX:VMOptionsFile=/var/my_vm_options HelloWorld)。
-XX:UseBranchProtection=mode

Linux AArch64のみ: ブランチ保護モードを指定します。 none以外のすべてのオプションでは、ブランチ保護を有効にしてVMが構築されている必要があります。 さらに、完全な保護のために、アプリケーションによって提供されるネイティブ・ライブラリはすべて、同じレベルの保護でコンパイルする必要があります。

このオプションのmode引数には次を指定できます。

none
ブランチ保護を使用しないでください。 これはデフォルト値です。
standard
現在のプラットフォームで使用可能なすべてのブランチ保護モードを有効にします。
pac-ret
ROPベースの攻撃に対する保護を有効にします。 (AArch64 8.3+のみ)

Java用の高度なJITコンパイラ・オプション

これらのjavaオプションは、Java HotSpot VMによって実行される動的ジャスト・イン・タイム (JIT)コンパイルを制御します。

-XX:AllocateInstancePrefetchLines=lines

インスタンス割当てポインタの前にプリフェッチする行数を設定します。 デフォルトでプリフェッチする行数は1に設定されています。

-XX:AllocateInstancePrefetchLines=1

-XX:AllocatePrefetchDistance=size

オブジェクト割当てのプリフェッチ距離のサイズ(バイト単位)を設定します。 新しいオブジェクトの値で書き込まれようとしているメモリーが、最後に割り当てられたオブジェクトのアドレスからこの距離まで、プリフェッチされます。 各Javaスレッドは独自の割当てポイントがあります。

マイナスの値は、プリフェッチ距離がプラットフォームに基づいて選択されたことを示します。 プラスの値はプリフェッチするバイトです。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 デフォルト値は-1に設定されます。

次の例は、プリフェッチ距離を1024バイトに設定する方法を示しています。

-XX:AllocatePrefetchDistance=1024

-XX:AllocatePrefetchInstr=instruction

割当てポインタの前にプリフェッチするプリフェッチ命令を設定します。 指定可能な値は0から3です。 値の背後にある実際の命令はプラットフォームによって異なります。 デフォルトで、プリフェッチ命令は0に設定されます。

-XX:AllocatePrefetchInstr=0

-XX:AllocatePrefetchLines=lines

コンパイル済コードで生成されるプリフェッチ命令を使用して、最後のオブジェクトの割当て後にロードされるキャッシュ行数を設定します。 デフォルト値は、最後に割り当てられたオブジェクトがインスタンスの場合は1で、配列の場合は3になります。

次の例は、ロードされるキャッシュ行数を5に設定する方法を示しています。

-XX:AllocatePrefetchLines=5

-XX:AllocatePrefetchStepSize=size

連続したプリフェッチ命令のステップ・サイズ(バイト単位)を設定します。 キロバイトを指定するには文字kまたはK、メガバイトを指定するには文字mまたはM、ギガバイトを指定するには文字gまたはGを付けます。 デフォルトでは、ステップ・サイズは16バイトに設定されます。

-XX:AllocatePrefetchStepSize=16

-XX:AllocatePrefetchStyle=style

プリフェッチ命令の生成されるコード・スタイルを設定します。 style引数は0から3の整数です。

0
プリフェッチ命令を生成しません。
1
各割当て後にプリフェッチ命令を実行します。 これはデフォルトの設定です。
2
スレッドローカル割当てブロック(TLAB)ウォーターマーク・ポインタを使用して、プリフェッチ命令を実行するタイミングを決定します。
3
キャッシュ行ごとにプリフェッチ命令を1つ生成します。
-XX:+BackgroundCompilation
バックグラウンド・コンパイルを有効にします。 このオプションはデフォルトでは有効になります。 バックグラウンド・コンパイルを無効にするには、-XX:-BackgroundCompilationを指定します(これは-Xbatchを指定するのと同等です)。
-XX:CICompilerCount=threads

コンパイルに使用するコンパイラ・スレッド数を設定します。 デフォルトでは、コンパイルされたコードに使用できるCPUとメモリーの数によっては、コンパイラのスレッド数が自動的に選択されます。 次の例は、スレッド数を2に設定する方法を示しています。

-XX:CICompilerCount=2

-XX:+UseDynamicNumberOfCompilerThreads
-XX:CICompilerCountで指定されている制限まで、コンパイラ・スレッドを動的に作成します。 このオプションはデフォルトでは有効になります。
-XX:CompileCommand=command,method[,option]

methodで実行するcommandを指定します。 たとえば、StringクラスのindexOf()メソッドをコンパイルから除外するには、次を使用します。

-XX:CompileCommand=exclude,java/lang/String.indexOf

スラッシュ(/)で区切られたすべてのパッケージとサブパッケージを含む完全クラス名を指定することに注意してください。 カット&ペースト操作を容易にするために、-XX:+PrintCompilationおよび-XX:+LogCompilationオプションによって生成されるメソッド名形式を使用することもできます:

-XX:CompileCommand=exclude,java.lang.String::indexOf

メソッドがシグネチャなしで指定された場合、そのコマンドは指定した名前のすべてのメソッドに適用されます。 ただし、クラス・ファイル形式でメソッドの署名を指定することもできます。 この場合、引数を引用符で囲んでください。そうしないと、シェルではセミコロンをコマンドの終了として扱います。 たとえば、StringクラスのindexOf(String)メソッドのみをコンパイルから除外する場合は、次を使用します。

-XX:CompileCommand="exclude,java/lang/String.indexOf,(Ljava/lang/String;)I"

クラスおよびメソッド名にワイルドカードとしてアスタリスク(*)を使用することもできます。 たとえば、すべてのクラスのすべてのindexOf()メソッドをコンパイルから除外するには、次を使用します。

-XX:CompileCommand=exclude,*.indexOf

カンマとピリオドはスペースの別名で、シェル経由でコンパイラ・コマンドを簡単に渡せるようになります。 引数を引用符で囲んで、セパレータとしてスペースを使用して、-XX:CompileCommandに引数を渡すことができます。

-XX:CompileCommand="exclude java/lang/String indexOf"

-XX:CompileCommandオプションを使用して、コマンド行に渡されたコマンドが解析されると、JITコンパイラは.hotspot_compilerファイルからコマンドを読み取ります。 このファイルにコマンドを追加するか、-XX:CompileCommandFileオプションを使用して別のファイルを指定できます。

複数のコマンドを追加するには、-XX:CompileCommandオプションを複数回指定するか、各引数を改行区切り文字 (\n)で区切ります。 次のコマンドを使用できます。

break
JVMをデバッグする際、指定されたメソッドのコンパイルの開始時に停止するブレークポイントを設定します。
compileonly
指定されたメソッドを除くすべてのメソッドをコンパイルから除外します。 代わりに、-XX:CompileOnlyオプションを使用すると、複数のメソッドを指定できます。
dontinline
指定されたメソッドのインライン化を防ぎます。
exclude
指定されたメソッドをコンパイルから除外します。
help
-XX:CompileCommandオプションのヘルプ・メッセージを出力します。
inline
指定されたメソッドのインライン化を試みます。
log
指定されたメソッドを除くすべてのメソッドのコンパイル・ロギング(-XX:+LogCompilationオプション付き)を除外します。 デフォルトで、ロギングはすべてのコンパイル済メソッドに対して実行されます。
option

最後の引数(option)のかわりに、指定されたメソッドにJITコンパイル・オプションを渡します。 このコンパイル・オプションは、メソッド名の後の最後に設定します。 たとえば、StringBufferクラスのappend()メソッドのBlockLayoutByFrequencyオプションを有効にするには、次を使用します。

-XX:CompileCommand=option,java/lang/StringBuffer.append,BlockLayoutByFrequency

カンマまたはスペースで区切った複数のコンパイル・オプションを指定できます。

print
指定されたメソッドのコンパイル後に生成されたアセンブラ・コードを出力します。
quiet

コンパイル・コマンドを出力しないように指示します。 デフォルトでは、-XX:CompileCommandオプションで指定したコマンドが出力されます。たとえば、StringクラスのindexOf()メソッドのコンパイルから除外する場合、次が標準出力に出力されます:

CompilerOracle: exclude java/lang/String.indexOf

これを抑制するには、他の-XX:CompileCommandオプションの前に-XX:CompileCommand=quietオプションを指定します。

-XX:CompileCommandFile=filename

JITコンパイラ・コマンドが読み取られるファイルを設定します。 デフォルトで、.hotspot_compilerファイルは、JITコンパイラによって実行されるコマンドを格納するために使用されます。

コマンド・ファイルの各行は、コマンド、クラス名、およびコマンドが使用されるメソッド名を表します。 たとえば、この行は、StringクラスのtoString()メソッドのアセンブリ・コードを出力します。

print java/lang/String toString

JITコンパイラがメソッドに対して実行するコマンドを使用している場合は、-XX:CompileCommandオプションを参照してください。

-XX:CompilerDirectivesFile=file

プログラムの開始時に、ディレクティブ・スタックにファイルからディレクティブを追加します。 コンパイラ・コントロールを参照してください。

-XX:CompilerDirectivesFileオプションは、診断JVMオプションのロックを解除する-XX:UnlockDiagnosticVMOptionsオプションと一緒に使用する必要があります。

-XX:+CompilerDirectivesPrint

プログラムの起動時または新しいディレクティブの追加時にディレクティブ・スタックを印刷します。

-XX:+CompilerDirectivesPrintオプションは、診断JVMオプションのロックを解除する-XX:UnlockDiagnosticVMOptionsオプションと一緒に使用する必要があります。

-XX:CompileOnly=methods

コンパイルを制限すべきメソッドのリスト(カンマ区切り)を設定します。 指定されたメソッドのみをコンパイルします。

-XX:CompileOnly=method1,method2,...,methodNは、次の別名です。

-XX:CompileCommand=compileonly,method1
-XX:CompileCommand=compileonly,method2
...
-XX:CompileCommand=compileonly,methodN
-XX:CompileThresholdScaling=scale
最初のコンパイルの統一された制御を提供します。 このオプションは、操作の層モードと無層モードの両方のためにメソッドを初めてコンパイルする時期を制御します。 CompileThresholdScalingオプションには、0から+Infまでの浮動小数点値があり、現在の操作(階層と非階層の両方)モードに対応するしきい値をスケールします。 CompileThresholdScalingを1.0より小さい値に設定すると、コンパイルは早くなり、値は1.0より遅延コンパイルになります。 CompileThresholdScalingを0に設定することは、コンパイルを無効にすることと同等です。
-XX:+DoEscapeAnalysis
エスケープ解析の使用を有効にします。 このオプションはデフォルトでは有効になります。 エスケープ解析の使用を無効にするには-XX:-DoEscapeAnalysisを指定します。
-XX:InitialCodeCacheSize=size

初期コード・キャッシュ・サイズ(バイト単位)を設定します。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 デフォルト値はプラットフォームによって異なります。 初期コード・キャッシュ・サイズは、システムの最小メモリー・ページ・サイズより小さくしないでください。 次の例は、初期コード・キャッシュ・サイズを32Kバイトに設定する方法を示しています。

-XX:InitialCodeCacheSize=32k

-XX:+Inline
メソッドのインライン化を有効にします。 このオプションは、パフォーマンス向上のため、デフォルトで有効になっています。 メソッドのインライン化を無効にするには、-XX:-Inlineを指定します。
-XX:InlineSmallCode=size

インライン化される可能性のあるすでにコンパイルされたメソッドの最大コード・サイズ(バイト単位)を設定します。 このフラグは、C2コンパイラにのみ適用されます。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 デフォルト値は、プラットフォームおよび階層コンパイルが有効かどうかによって異なります。 次の例では、1000バイトに設定されます:

-XX:InlineSmallCode=1000

-XX:+LogCompilation

現在の作業ディレクトリ内のhotspot.logというファイルへのコンパイル・アクティビティのロギングを有効にします。 -XX:LogFileオプションを使用して、別のログ・ファイル・パスと名前を指定できます。

デフォルトでは、このオプションは無効になっており、コンパイル・アクティビティはログに記録されません。 -XX:+LogCompilationオプションは、診断JVMオプションのロックを解除する-XX:UnlockDiagnosticVMOptionsオプションと一緒に使用する必要があります。

-XX:+PrintCompilationオプションを使用して、メソッドがコンパイルされるたびに、コンソールにメッセージが出力される詳細診断出力を有効にできます。

-XX:FreqInlineSize=size

インライン化されるホット・メソッドの最大バイト・コード・サイズの(バイト単位)を設定します。 このフラグは、C2コンパイラにのみ適用されます。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 デフォルト値はプラットフォームによって異なります。 次の例では、325バイトに設定されています:

-XX:FreqInlineSize=325

-XX:MaxInlineSize=size

インライン化されるコールド・メソッドの最大バイト・コード・サイズ(バイト単位)を設定します。 このフラグは、C2コンパイラにのみ適用されます。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 デフォルトでは、最大バイトコード・サイズは35バイトに設定されます。

-XX:MaxInlineSize=35

-XX:C1MaxInlineSize=size

インライン化されるコールド・メソッドの最大バイト・コード・サイズ(バイト単位)を設定します。 このフラグは、C1コンパイラにのみ適用されます。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 デフォルトでは、最大バイトコード・サイズは35バイトに設定されます。

-XX:MaxInlineSize=35

-XX:MaxTrivialSize=size

インライン化する簡易メソッドの最大バイトコード・サイズ(バイト単位)を設定します。 このフラグは、C2コンパイラにのみ適用されます。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 デフォルトでは、簡易メソッドの最大バイトコード・サイズは6バイトに設定されます。

-XX:MaxTrivialSize=6

-XX:C1MaxTrivialSize=size

インライン化する簡易メソッドの最大バイトコード・サイズ(バイト単位)を設定します。 このフラグは、C1コンパイラにのみ適用されます。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 デフォルトでは、簡易メソッドの最大バイトコード・サイズは6バイトに設定されます。

-XX:MaxTrivialSize=6

-XX:MaxNodeLimit=nodes

単一のメソッドのコンパイル時に使用されるノードの最大数を設定します。 デフォルトでは、有効な機能によって値が異なります。 次の例では、ノードの最大数は100,000に設定されています:

-XX:MaxNodeLimit=100000

-XX:NonNMethodCodeHeapSize=size

非メソッド・コードが含まれるコード・セグメントのサイズ(バイト単位)を設定します。

非メソッド・コードが含まれる非メソッド・コード・セグメントには、コンパイラ・バッファやバイトコード・インタプリタなどがあります。 このコード・タイプは永遠にコード・キャッシュにとどまります。 このフラグは、-XX:SegmentedCodeCacheが有効な場合にのみ使用されます。

-XX:NonProfiledCodeHeapSize=size
非プロファイル・メソッドが含まれるコード・セグメントのサイズ(バイト単位)を設定します。 このフラグは、-XX:SegmentedCodeCacheが有効な場合にのみ使用されます。
-XX:+OptimizeStringConcat
String連結操作の最適化を有効にします。 このオプションはデフォルトでは有効になります。 String連結操作の最適化を有効にするには、-XX:-OptimizeStringConcatを指定します。
-XX:+PrintAssembly

外部のhsdis-<arch>.soまたは.dllライブラリを使用して、バイトコードおよびネイティブ・メソッドのアセンブリ・コードの印刷を有効にします。 Windows上の64ビットVMの場合は、hsdis-amd64.dllです。 これにより、生成されたコードを確認できるため、パフォーマンス問題の診断に役立つことがあります。

デフォルトでは、このオプションは無効になっており、アセンブリ・コードは出力されません。 -XX:+PrintAssemblyオプションは、診断JVMオプションのロックを解除する-XX:UnlockDiagnosticVMOptionsオプションと一緒に使用する必要があります。

-XX:ProfiledCodeHeapSize=size
プロファイルされたメソッドを含むコード・セグメントのサイズをバイト単位で設定します。 このフラグは、-XX:SegmentedCodeCacheが有効な場合にのみ使用されます。
-XX:+PrintCompilation

メソッドがコンパイルされるたびに、コンソールにメッセージを出力することによって、JVMからの詳細診断出力を有効にします。 これにより、実際にコンパイルされるメソッドを確認できます。 デフォルトでは、このオプションは無効になっており、診断出力は出力されません。

-XX:+LogCompilationオプションを使用して、コンパイル・アクティビティをファイルに記録することもできます。

-XX:+PrintInlining

インライン化の出力の決定を有効にします。 これにより、インライン化されるメソッドを確認できます。

デフォルトでは、このオプションは無効になっており、インライン化情報は出力されません。 -XX:+PrintInliningオプションは、診断JVMオプションのロックを解除する-XX:UnlockDiagnosticVMOptionsオプションと一緒に使用する必要があります。

-XX:ReservedCodeCacheSize=size
JITでコンパイルされたコードの最大コード・キャッシュ・サイズ(バイト単位)を設定します。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 デフォルトの最大コード・キャッシュ・サイズは240 MBです。-XX:-TieredCompilationオプションで階層コンパイルを無効にした場合、デフォルト・サイズは48 MBです。 このオプションは2GBの制限があります。そうでない場合は、エラーが生成されます。 最大コード・キャッシュ・サイズは、初期コード・キャッシュ・サイズより小さくしないでください。オプション-XX:InitialCodeCacheSizeを参照してください。
-XX:+SegmentedCodeCache

コード・キャッシュが1つの大きなセグメントで構成されていないコード・キャッシュのセグメンテーションを有効にします。 -XX:+SegmentedCodeCacheでは、非メソッド、プロファイル・メソッドおよび非プロファイル・メソッド・コードに対して個別のセグメントが使用されます。 実行時にセグメントのサイズは変更されません。 この利点は、メモリー・フットプリントの制御が向上し、コードの断片化が減少し、CPU iTLB (命令変換ルックアサイドバッファ)および命令キャッシュの動作が向上するためです。

階層化コンパイルが(-XX:+TieredCompilation)で、予約済コード・キャッシュ・サイズ(-XX:ReservedCodeCacheSize)が240 MB以上である場合、この機能はデフォルトで有効になります。

-XX:StartAggressiveSweepingAt=percent
指定されたパーセンテージのコード・キャッシュのみが空いている場合、積極的に未使用のコードを削除するようにアクティブ・メソッドのスタック・スキャンを強制します。 デフォルト値は10%です。
-XX:-TieredCompilation
階層化コンパイルの使用を無効にします。 デフォルトでは、このオプションは有効です。
-XX:UseSSE=version
指定されたバージョンのSSE命令セットを使用できます。 デフォルトで、サポートされている最高バージョンの(x 86のみ)に設定されます。
-XX:UseAVX=version
指定されたバージョンのAVX命令セットを使用できます。 デフォルトで、サポートされている最高バージョンの(x 86のみ)に設定されます。
-XX:+UseAES
ハードウェア・ベースのAES組込みをサポートするハードウェアに対して有効化します。 このオプションは、必要な命令が含まれるハードウェア上で、デフォルトでオンになっています。 -XX:+UseAESは、UseAESIntrinsicsとともに使用されます。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseAESIntrinsics

AESの組込みを有効にします。 -XX:+UseAESIntrinsicsを指定することは、-XX:+UseAESを使用可能にすることと同じです。 ハードウェアベースのAES組込みを無効化するには、-XX:-UseAES -XX:-UseAESIntrinsicsを指定します。 たとえば、ハードウェアAESを有効化するには、次のフラグを使用します。

-XX:+UseAES -XX:+UseAESIntrinsics

組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。

-XX:+UseAESCTRIntrinsics
-XX:+UseAESIntrinsicsへの対応により、AES/CTR組込みが有効になります。
-XX:+UseGHASHIntrinsics
GHASH組込みの使用を制御します。 対応する指示をサポートするプラットフォームでは、デフォルトで有効になっています。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseChaCha20Intrinsics
ChaCha20組み込みを有効にします。 このオプションは、サポートされているプラットフォームではデフォルトでオンになっています。 ChaCha20組み込み機能を無効にするには、-XX:-UseChaCha20Intrinsicsを指定します。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UsePoly1305Intrinsics
Poly1305組み込みを有効にします。 このオプションは、サポートされているプラットフォームではデフォルトでオンになっています。 Poly1305組み込み機能を無効にするには、-XX:-UsePoly1305Intrinsicsを指定します。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseBASE64Intrinsics
java.util.Base64の高速化BASE64エンコーディング・ルーチンの使用を制御します。 その情報をサポートするプラットフォームでは、デフォルトで有効になっています。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseAdler32Intrinsics
java.util.zip.Adler32に固有のAdler32チェックサム・アルゴリズムの使用を制御します。 その情報をサポートするプラットフォームでは、デフォルトで有効になっています。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseCRC32Intrinsics
java.util.zip.CRC32のCRC32組込みの使用を制御します。 その情報をサポートするプラットフォームでは、デフォルトで有効になっています。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseCRC32CIntrinsics
java.util.zip.CRC32CにCRC32C組込みの使用を制御します。 その情報をサポートするプラットフォームでは、デフォルトで有効になっています。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseSHA

一部のハードウェアでSHA暗号ハッシュ関数のハードウェア・ベースの組み込みを有効にします。 UseSHAオプションは、UseSHA1Intrinsics、UseSHA256Intrinsics、およびUseSHA512Intrinsicsオプションと組み合わせて使用されます。

UseSHAおよびUseSHA*Intrinsicsのフラグは、対応する指示をサポートするマシンでデフォルトで有効になります。

この機能は、SHA操作にsun.security.provider.Sunプロバイダを使用する場合にのみ適用できます。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。

すべてのハードウェア・ベースのSHA組み込み機能を無効にするには、-XX:-UseSHAを指定します。 特定のSHA組込みのみ無効化するには、適切な対応するオプションを使用してください。 例えば : -XX:-UseSHA256Intrinsics。

-XX:+UseSHA1Intrinsics
SHA-1暗号化ハッシュ関数の組込みを有効にします。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseSHA256Intrinsics
SHA-224およびSHA-256暗号化ハッシュ関数の組込みを有効にします。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseSHA512Intrinsics
SHA-384およびSHA-512暗号化ハッシュ関数の組込みを有効にします。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseMathExactIntrinsics
様々なjava.lang.Math.*Exact()ファンクションの組込みを使用可能にします。 デフォルトで有効になっています。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseMultiplyToLenIntrinsic
BigInteger.multiplyToLen()の組込みを使用可能にします。 その情報をサポートするプラットフォームでは、デフォルトで有効になっています。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseSquareToLenIntrinsic
BigInteger.squareToLen()の組込みを使用可能にします。 その情報をサポートするプラットフォームでは、デフォルトで有効になっています。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseMulAddIntrinsic
BigInteger.mulAdd()の組込みを使用可能にします。 その情報をサポートするプラットフォームでは、デフォルトで有効になっています。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseMontgomeryMultiplyIntrinsic
BigInteger.montgomeryMultiply()の組込みを使用可能にします。 その情報をサポートするプラットフォームでは、デフォルトで有効になっています。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseMontgomerySquareIntrinsic
BigInteger.montgomerySquare()の組込みを使用可能にします。 その情報をサポートするプラットフォームでは、デフォルトで有効になっています。 組み込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。
-XX:+UseCMoveUnconditionally
収益性分析に関係なく、CMove (スカラーおよびベクター)命令を生成します。
-XX:+UseCodeCacheFlushing
コンパイラのシャットダウン前に、コード・キャッシュのフラッシュを有効にします。 このオプションはデフォルトでは有効になります。 コンパイラのシャットダウン前に、コード・キャッシュのフラッシュを無効にするには、-XX:-UseCodeCacheFlushingを指定します。
-XX:+UseCondCardMark
カード表を更新する前にカードが既にマークされているかどうかをチェックすることができます。 このオプションはデフォルトでは無効です。 複数のソケットを持つマシンでのみ使用してください。これにより、同時操作に依存するJavaアプリケーションのパフォーマンスが向上します。
-XX:+UseCountedLoopSafepoints
セーフ・ポイントをカウントされたループに保持します。 このデフォルト値は、選択したガベージ・コレクタが低遅延の安全性が必要かどうかによって異なります。
-XX:LoopStripMiningIter=number_of_iterations
内部ストリップ・ループ内の反復数を制御します。 カウントされたマイニング変換を2レベルのネステッド・ループに削除します。 Safepointsは外部ループに保持され、内部ループは高速で実行できます。 このオプションは、内部ループにおける反復の最大数を制御します。 デフォルト値は1,000です。
-XX:LoopStripMiningIterShortLoop=number_of_iterations
ループ・ストリップのマイニング最適化を制御します。 指定された反復数より少ないループには、ループ内の安全なポイントがありません。 デフォルト値は-XX:LoopStripMiningIterの1から10です。
-XX:+UseFMA
FMA命令が使用可能なハードウェアにハードウェア・ベースのFMA組み込み関数を有効にします。(IntelやARM64など)。 FMAの侵入者は、( a * b + c )式の値を計算するjava.lang.Math.fma(a, b, c)メソッドに生成されます。
-XX:+UseSuperWord
スカラー操作のスーパーワード操作への変換を有効にします。 スーパー・ワードはベクトル化の最適化です。 このオプションはデフォルトでは有効になります。 スカラー操作のスーパーワード操作への変換を無効にするには、-XX:-UseSuperWordを指定します。

javaの拡張保守性オプション

これらのjavaオプションは、システム情報を収集し、広範なデバッグを実行する機能を提供します。

-XX:+DisableAttachMechanism

ツールをJVMにアタッチするためのメカニズムを無効にします。 デフォルトでは、このオプションは無効になっています。つまり、アタッチ・メカニズムが有効になっており、診断およびトラブルシューティング・ツール(jcmd, jstack, jmap、jinfoなど)を使用できます。

ノート: JDKに同梱されているjcmd、jinfo、jmapおよびjstackなどのツールは、あるJDKバージョンのツールを使用して別のJDKバージョンのトラブルシューティングを行う場合、サポートされません。

-XX:+DTraceAllocProbes
LinuxおよびmacOS: オブジェクト割当てのdtraceツール・プローブを有効にします。
-XX:+DTraceMethodProbes
LinuxおよびmacOS: メソッド・エントリおよびメソッド終了に対してdtraceツール・プローブを有効にします。
-XX:+DTraceMonitorProbes
LinuxおよびmacOS: モニター・イベントのdtraceツール・プローブを有効にします。
-XX:+HeapDumpOnOutOfMemoryError
java.lang.OutOfMemoryError例外がスローされた場合に、ヒープ・プロファイラ(HPROF)を使用して、Javaヒープの現在のディレクトリ内のファイルへのダンプを有効にします。 ヒープ・ダンプ・ファイルのパスと名前を明示的に設定するには、-XX:HeapDumpPathオプションを使用します。 デフォルトでは、このオプションは無効になっており、OutOfMemoryError例外がスローされたときにヒープはダンプされません。
-XX:HeapDumpPath=path

-XX:+HeapDumpOnOutOfMemoryErrorオプションが設定されている場合に、ヒープ・プロファイラ(HPROF)によって提供されるヒープ・ダンプを書き込むパスとファイル名を設定します。 デフォルトでは、ファイルは現在の作業ディレクトリに作成され、java_pid<pid>.hprofという名前になります。<pid>はエラーの原因となったプロセスの識別子です。 次の例は、デフォルト・ファイルを明示的に(%pは、現在のプロセス識別子を表します)に設定する方法を示しています:

-XX:HeapDumpPath=./java_pid%p.hprof

  • 非Windows: 次の例では、ヒープ・ダンプ・ファイルを/var/log/java/java_heapdump.hprofに設定する方法を示します :

    -XX:HeapDumpPath=/var/log/java/java_heapdump.hprof

  • Windows: 次の例では、ヒープ・ダンプ・ファイルをC:/log/java/java_heapdump.logに設定する方法を示します :

    -XX:HeapDumpPath=C:/log/java/java_heapdump.log

-XX:LogFile=path

ログ・データが書き込まれるパスとファイル名を設定します。 デフォルトでは、ファイルは現在の作業ディレクトリに作成され、hotspot.logという名前になります。

  • 非Windows: 次の例では、ログ・ファイルを/var/log/java/hotspot.logに設定する方法を示します :

    -XX:LogFile=/var/log/java/hotspot.log

  • Windows: 次の例では、ログ・ファイルをC:/log/java/hotspot.logに設定する方法を示します :

    -XX:LogFile=C:/log/java/hotspot.log

-XX:+PrintClassHistogram

次のいずれかのイベントの後にクラス・インスタンス・ヒストグラムを出力できるようにします:

  • 非Windows: Control+\ (SIGQUIT)

  • Windows: Control+C (SIGTERM)

デフォルトでは、このオプションは無効になっています。

このオプションを設定することは、jmap -histoコマンドまたはjcmd pid GC.class_histogramコマンドを実行することと同等で、pidは現在のJavaプロセス識別子です。

-XX:+PrintConcurrentLocks

次のいずれかのイベントのあとのjava.util.concurrentロックの印刷を有効にします:

  • 非Windows: Control+\ (SIGQUIT)

  • Windows: Control+C (SIGTERM)

デフォルトでは、このオプションは無効になっています。

このオプションを設定することは、jstack -lコマンドまたはjcmd pid Thread.print -lコマンドを実行することと同等で、pidは現在のJavaプロセス識別子です。

-XX:+PrintFlagsRanges
指定された範囲を出力し、値の自動テストを可能にします。 「Java Virtual Machineのフラグ引数を検証」を参照してください。
-XX:+PerfDataSaveToFile

有効にすると、Javaアプリケーションが終了するとjstatバイナリ・データが保存されます。 このバイナリ・データは、hsperfdata_ pidという名前のファイルに保存されます。pidは、実行したJavaアプリケーションのプロセス識別子です。 jstatコマンドを使用して、このファイルに含まれるパフォーマンス・データを次のように表示します:

jstat -class file:///path/hsperfdata_pid

jstat -gc file:///path/hsperfdata_pid

-XX:+UsePerfData
perfdata機能を有効にします。 このオプションはデフォルトで有効にされており、JVMのモニタリングとパフォーマンスのテストが許可されます。 これを無効にすると、hsperfdata_useridディレクトリの作成が抑制されます。 perfdata機能を無効にするには、-XX:-UsePerfDataを指定します。

javaの拡張ガベージ・コレクション・オプション

これらのjavaオプションは、Java HotSpot VMによるガベージ・コレクション(GC)の実行方法を制御します。

-XX:+AggressiveHeap
Javaヒープ最適化を有効にします。 これにより、コンピュータの構成(RAMおよびCPU)に基づいて、メモリーが集中的に割り当てられる長時間実行ジョブに最適になるように、各種パラメータを設定します。 デフォルトでは、このオプションは無効になっており、ヒープ・サイズは積極的に構成されています。
-XX:+AlwaysPreTouch
オペレーティング・システムからリクエストした後、メモリーをアプリケーションに渡す前に、JavaヒープのすべてのページにタッチするようVMにリクエストします。 デフォルトでは、このオプションは無効になっており、アプリケーションでヒープ領域が使用されるためすべてのページがコミットされます。
-XX:ConcGCThreads=threads

並行GCに使用されるスレッド数を設定します。 threadsをパラレル・ガベージ・コレクション・スレッド数の約1/4に設定します。 デフォルト値は、JVMに使用可能なCPUの数によって異なります。

たとえば並行GCのスレッド数を2に設定するには、次のオプションを指定します。

-XX:ConcGCThreads=2

-XX:+DisableExplicitGC
System.gc()メソッドへのコールの処理を無効化するオプションを有効にします。 このオプションはデフォルトで無効にされ、System.gc()の呼出しが処理されることを意味します。 System.gc()へのコールの処理が無効になっている場合、JVMは必要に応じてGCを実行します。
-XX:+ExplicitGCInvokesConcurrent
System.gc()要求を使用して、並行GCの呼出しを有効にします。 このオプションはデフォルトでは無効になっており、-XX:+UseG1GCオプションでのみ有効にできます。
-XX:G1AdaptiveIHOPNumInitialSamples=number
-XX:UseAdaptiveIHOPが有効な場合、G1が-XX:InitiatingHeapOccupancyPercentの最適な値を決定するまでサンプルの収集に使用される完了マーク付けサイクル数は、このオプションによって設定されます。 この目的のために、G1が-XX:InitiatingHeapOccupancyPercentの値を直接使用します。 デフォルト値は3です。
-XX:G1HeapRegionSize=size

ガベージファースト(G1)コレクタを使用した場合に、Javaヒープが再分割される領域のサイズを設定します。 この値は2の累乗で、1MBから32MBの範囲で指定できます。 デフォルトのリージョンのサイズは、約2048リージョンの目標のヒープ・サイズに基づいて人間工学的に決定されます。

次の例では、ビジョンのサイズを16 MBに設定しています:

-XX:G1HeapRegionSize=16m

-XX:G1HeapWastePercent=percent
未使用にするヒープの許容パーセンテージを設定します。 再生可能率がヒープの未使用率を下回ると、Java HotSpot VMは混合ガベージ・コレクション・サイクルを開始しません。 デフォルトは5パーセントです。
-XX:G1MaxNewSizePercent=percent

young世代の最大サイズとして使用するヒープ・サイズのパーセンテージを設定します。 デフォルト値はJavaヒープの60%です。

これは試験的なフラグです。 この設定は-XX:DefaultMaxNewGenPercent設定にかわるものです。

-XX:G1MixedGCCountTarget=number
マーキング・サイクル後に古いリージョンのライブ・データ(最大でG1MixedGCLIveThresholdPercent%)を収集する混合ガベージ・コレクションの目標回数を設定します。 デフォルトは、8回の混合ガベージ・コレクションです。 混合コレクションの目的は、この目標数内にあることです。
-XX:G1MixedGCLiveThresholdPercent=percent

混合ガベージ・コレクション・サイクルに含める古い世代の占有率のしきい値を設定します。 デフォルトの占有率は85%です。

これは試験的なフラグです。 この設定は-XX:G1OldCSetRegionLiveThresholdPercent設定にかわるものです。

-XX:G1NewSizePercent=percent

若い世代の最小サイズとして使用するヒープの割合を設定します。 デフォルト値はJavaヒープの5%です。

これは試験的なフラグです。 この設定は-XX:DefaultMinNewGenPercent設定にかわるものです。

-XX:G1OldCSetRegionThresholdPercent=percent
混合ガベージ・コレクション・サイクル時に収集する古い世代の数に上限を設定します。 デフォルトはJavaヒープの10%です。
-XX:G1ReservePercent=percent

G1コレクタの昇格の失敗の可能性を減らすために、失敗の上限として予約されるヒープのパーセンテージ(0から50)を設定します。 このパーセンテージを増減するときは、必ずJavaヒープの合計量を同量分調整してください。 デフォルトで、このオプションは10%に設定されます。

次の例では、予約されたヒープを20%に設定しています:

-XX:G1ReservePercent=20

-XX:+G1UseAdaptiveIHOP

古い世代収集用のバックグラウンド作業準備を開始するために、古い世代占有データの適応型計算を制御します。 有効の場合、G1では、-XX:G1AdaptiveIHOPNumInitialSamplesの値で指定されたとおりに最初の数回にわたって-XX:InitiatingHeapOccupancyPercentが使用され、その後、開始占有領域の新しい最適値が自動的に計算されます。 それ以外の場合、古い世代の収集プロセスは常に、-XX:InitiatingHeapOccupancyPercentによって決定された古い世代の占有データで開始されます。

デフォルトは有効です。

-XX:InitialHeapSize=size

メモリー割当てプールの初期サイズ(バイト単位)を設定します。 この値は0または1Mバイトより大きい1024の倍数にする必要があります。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 デフォルト値は、実行時にシステム構成に基づいて選択されます。

次の例では、様々な単位を使用して、割り当てられたメモリーのサイズを6Mバイトに設定する方法を示します。

-XX:InitialHeapSize=6291456
-XX:InitialHeapSize=6144k
-XX:InitialHeapSize=6m

このオプションを0に設定した場合、初期サイズは、Old世代とYoung世代に割り当てられたサイズの合計として設定されます。 Young世代のヒープのサイズは、-XX:NewSizeオプションを使用して、設定できます。 -Xmsオプションは、ヒープの最小ヒープ・サイズと初期ヒープ・サイズの両方を設定します。 コマンドラインで-XX:InitialHeapSizeの後に-Xmsが表示された場合、初期ヒープ・サイズは、-Xmsで指定された値に設定されます。

-XX:InitialRAMPercentage=percent

JVMがJavaヒープに使用するメモリーの初期容量を設定します。これを超えると、人間工学に基づくヒューリスティックが-XX:MaxRAMオプションの記述に従って決定される最大量のパーセンテージとして適用されます。 デフォルト値は1.5625%です。

次の例は、Javaヒープに使用される初期メモリー容量の割合を設定する方法を示しています:

-XX:InitialRAMPercentage=5

-XX:InitialSurvivorRatio=ratio

スループット・ガベージ・コレクタ(これは、-XX:+UseParallelGCオプションによって有効になります。)で使用される初期survivor領域率を設定します。 -XX:+UseParallelGCオプションを使用すると、スループットのガベージ・コレクタで適応サイズ設定がデフォルトで有効になり、survivor領域は初期値から始まるアプリケーションの動作に従ってサイズ変更されます。 適応型のサイズ変更が無効にされている場合(-XX:-UseAdaptiveSizePolicyオプションを使用して)、-XX:SurvivorRatioオプションを使用して、アプリケーションの全体の実行のSurvivor領域のサイズを設定してください。

次の公式を使用して、Young世代のサイズ(Y)に基づいて、Survivor領域の初期サイズ(S)と初期Survivor領域率(R)を計算できます。

S=Y/(R+2)

方程式の2は2つのSurvivor領域を示します。 初期Survivor領域率として指定する値が大きいほど、初期Survivor領域のサイズが小さくなります。

デフォルトで初期Survivor領域率は8に設定されます。 Young世代の領域サイズにデフォルト値を使用する場合(2 MB)、Survivor領域の初期サイズは0.2 MBになります。

次の例は、初期Survivor領域率を4に設定する方法を示しています。

-XX:InitialSurvivorRatio=4

-XX:InitiatingHeapOccupancyPercent=percent

G1ガベージ・コレクタの最初の数個のコンカレント・マーク・サイクルを開始する古い世代占有データ(0〜100)の割合を設定します。

デフォルトでは、開始値は45%に設定されます。 値0は、G1がこの値を適切に設定するまで、最上位の同時GCサイクルが最初から開始されることを意味します。

-XX:G1UseAdaptiveIHOPおよび-XX:G1AdaptiveIHOPNumInitialSamplesオプションも参照してください。

次の例は、開始ヒープ占有率を75%に設定する方法を示しています。

-XX:InitiatingHeapOccupancyPercent=75

-XX:MaxGCPauseMillis=time

GCの最大一時停止時間(ミリ秒単位)の目標を設定します。 これはソフト・ゴールのため、JVMはその実現のために最善の努力をします。 指定された値はヒープ・サイズには適応されません。 G1の場合、デフォルトでは、一時停止時間の最大ターゲットは200ミリ秒です。 その他の一般的なコレクタは、デフォルトでは一時停止時間の目標を使用しません。

次の例は、最大目標一時停止時間を500msに設定する方法を示しています。

-XX:MaxGCPauseMillis=500

-XX:MaxHeapSize=size

メモリー割当てプールの最大サイズ(バイト単位)を設定します。 この値は、1024の倍数で、2Mバイトより大きくなければなりません。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 デフォルト値は、実行時にシステム構成に基づいて選択されます。 サーバー・デプロイメントでは、多くの場合、-XX:InitialHeapSizeおよび-XX:MaxHeapSizeオプションは同じ値に設定されます。

次の例では、様々な単位を使用して、割り当てられたメモリーの最大許容サイズを80Mバイトに設定する方法を示します。

-XX:MaxHeapSize=83886080
-XX:MaxHeapSize=81920k
-XX:MaxHeapSize=80m

-XX:MaxHeapSizeオプションは-Xmxと同等です。

-XX:MaxHeapFreeRatio=percent

GCイベント後の空きヒープ領域の最大許容率(0から100)を設定します。 空きヒープ領域がこの値を超えて拡大した場合、ヒープが縮小されます。 デフォルトで、この値は70%に設定されます。

コマンドライン・オプション-XX:MaxHeapFreeRatioおよび-XX:MinHeapFreeRatioを使用して、パラメータMaxHeapFreeRatio (デフォルト値は70%)およびMinHeapFreeRatio (デフォルト値は40%)の値を小さくして、Javaヒープ・サイズを最小化します。 MaxHeapFreeRatioを10%に減らし、MinHeapFreeRatioを5%に下げると、パフォーマンスを低下させることなくヒープ・サイズが正常に削減されました。ただし、結果はアプリケーションによって大きく異なる場合があります。 これらのパラメータの値を可能なかぎり小さくし、許容できるパフォーマンスを維持するように、様々な値を試してください。

-XX:MaxHeapFreeRatio=10 -XX:MinHeapFreeRatio=5

ヒープを小さく保つことを試みるお客様は、オプション-XX:-ShrinkHeapInStepsも追加する必要があります。 このオプションを使用して、組み込みアプリケーションの動的フットプリントを減らしてJavaヒープを小さく保つ方法については、「パフォーマンス・チューニングの例」を参照してください。

-XX:MaxMetaspaceSize=size

クラス・メタデータに割当て可能なネイティブ・メモリーの最大量を設定します。 デフォルトでは、サイズは無制限です。 アプリケーションのメタデータの量は、アプリケーション自体、その他の実行中のアプリケーション、およびシステムで使用可能なメモリーの量によって異なります。

次の例は、最大クラス・メタデータ・サイズを256Mバイトに設定する方法を示しています。

-XX:MaxMetaspaceSize=256m

-XX:MaxNewSize=size
Young世代(ナーサリ)のヒープの最大サイズ(バイト単位)を設定します。 デフォルト値はエルゴノミクスに従って設定されます。
-XX:MaxRAM=size

JVMが人間工学ヒューリスティックを適用する前に、Javaヒープに使用できるメモリーの最大量を設定します。 デフォルト値は、JVMプロセスで使用可能なメモリーの最大量か、128 GBのいずれか少ない方です。

JVMプロセスで使用可能なメモリーの最大量は、マシンの物理メモリーの最小量および環境(例、コンテナ)で設定された任意の制約です。

このオプションを指定すると、このオプションを組み合せた結果と、メモリーの最大量に影響するその他のオプションが、圧縮されたoopで圧縮可能なメモリー・アドレスの範囲よりも大きい場合に、圧縮されたoopsの自動使用が無効になります。 圧縮oopsの詳細は、-XX:UseCompressedOopsを参照してください。

次の例は、Javaヒープのサイズを2 GBに設定するために使用可能なメモリーの最大量を設定する方法を示しています:

-XX:MaxRAM=2G

-XX:MaxRAMPercentage=percent

JVMがJavaヒープに使用できる最大メモリー容量を設定します。これを超えると、人間工学に基づいたヒューリスティックを-XX:MaxRAMオプションで指定された最大量の割合として適用します。 デフォルト値は25%です。

このオプションを指定すると、このオプションを組み合せた結果と、メモリーの最大量に影響するその他のオプションが、圧縮されたoopで圧縮可能なメモリー・アドレスの範囲よりも大きい場合に、圧縮されたoopsの自動使用が無効になります。 圧縮oopsの詳細は、-XX:UseCompressedOopsを参照してください。

次の例は、Javaヒープに使用される最大メモリー容量の割合を設定する方法を示しています:

-XX:MaxRAMPercentage=75

-XX:MinRAMPercentage=percent

JVMがJavaヒープに使用できる最大メモリー容量を設定します。これを超えると、小さなヒープの-XX:MaxRAMオプションで説明されているとおり、人間工学に基づいた最大量の割合として検証されます。 小さいヒープは、約125 MBのヒープです。 デフォルト値は50%です。

次の例では、Javaヒープに使用される小さいヒープの最大メモリー量の割合を設定する方法を示します:

-XX:MinRAMPercentage=75

-XX:MaxTenuringThreshold=threshold

適応型GCサイズ変更に使用する最大殿堂入りしきい値を設定します。 最大値は15です。 パラレル(throughput)コレクタの場合のデフォルト値は15です。

次の例は、最大殿堂入りしきい値を10に設定する方法を示しています。

-XX:MaxTenuringThreshold=10

-XX:MetaspaceSize=size
初めて超えたときにガベージ・コレクションがトリガーされる、割り当てられるクラス・メタデータ領域のサイズを設定します。 ガベージ・コレクションのこのしきい値は、使用されるメタデータの量に応じて増加または減少します。 デフォルトのサイズはプラットフォームによって異なります。
-XX:MinHeapFreeRatio=percent

GCイベント後の空きヒープ領域の最小許容率(0から100)を設定します。 空きヒープ領域がこの値を下回った場合、ヒープが拡張されます。 デフォルトで、この値は40%に設定されます。

コマンドライン・オプション-XX:MaxHeapFreeRatioおよび-XX:MinHeapFreeRatioを使用して、パラメータMaxHeapFreeRatio (デフォルト値は70%)およびMinHeapFreeRatio (デフォルト値は40%)の値を小さくして、Javaヒープ・サイズを最小化します。 MaxHeapFreeRatioを10%に減らし、MinHeapFreeRatioを5%に下げると、パフォーマンスを低下させることなくヒープ・サイズが正常に削減されました。ただし、結果はアプリケーションによって大きく異なる場合があります。 可能な限り低い値になるまで、これらのパラメータの値を変えてみてください。

-XX:MaxHeapFreeRatio=10 -XX:MinHeapFreeRatio=5

ヒープを小さく保つことを試みるお客様は、オプション-XX:-ShrinkHeapInStepsも追加する必要があります。 このオプションを使用して、組み込みアプリケーションの動的フットプリントを減らしてJavaヒープを小さく保つ方法については、「パフォーマンス・チューニングの例」を参照してください。

-XX:MinHeapSize=size

メモリー割当てプールの最小サイズの(バイト単位)を設定します。 この値は0または1Mバイトより大きい1024の倍数にする必要があります。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 デフォルト値は、実行時にシステム構成に基づいて選択されます。

次の例は、さまざまな単位を使用して割り当て済みメモリーの最小サイズを6 MBに設定する方法を示しています:

-XX:MinHeapSize=6291456
-XX:MinHeapSize=6144k
-XX:MinHeapSize=6m

このオプションを0に設定すると、最小サイズは初期サイズと同じ値に設定されます。

-XX:NewRatio=ratio

Young世代のサイズとOld世代のサイズの比率を設定します。 デフォルトでは、このオプションは2に設定されます。 次の例は、年齢と年齢の比率を1に設定する方法を示しています:

-XX:NewRatio=1

-XX:NewSize=size

Young世代(ナーサリ)のヒープの初期サイズ(バイト単位)を設定します。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。

ヒープのYoung世代領域は新しいオブジェクトに使用されます。 この領域では他の領域よりも頻繁にGCが実行されます。 Young世代のサイズが小さすぎる場合は、大量のマイナーGCが実行されます。 そのサイズが大きすぎる場合は、フルGCのみが実行されますが、これは完了までに長時間かかることがあります。 若い世代のサイズは、25%より大きく、ヒープ・サイズ全体の50%未満にすることをお薦めします。

次の例は、様々な単位を使用して、Young世代の初期サイズを256MBに設定する方法を示しています。

-XX:NewSize=256m
-XX:NewSize=262144k
-XX:NewSize=268435456

-XX:NewSizeオプションは-Xmnと同等です。

-XX:ParallelGCThreads=threads

stop-the-world (STW)ワーカー・スレッドの数を設定します。 デフォルト値は、JVMで使用可能なcpuの数および選択したガベージ・コレクタによって異なります。

たとえば、G1 GCのスレッド数を2に設定するには、次のオプションを指定します:

-XX:ParallelGCThreads=2

-XX:+ParallelRefProcEnabled
パラレル参照処理を有効にします。 デフォルトでは、このオプションは無効になっています。
-XX:+PrintAdaptiveSizePolicy
適応型生成サイジングに関する情報の印刷を有効にします。 デフォルトでは、このオプションは無効になっています。
-XX:SoftRefLRUPolicyMSPerMB=time

ソフトに到達可能なオブジェクトが最後に参照された後にヒープで有効なまま維持される時間の量(ミリ秒単位)を設定します。 デフォルト値は、ヒープ内の空きメガバイト当たり1秒の寿命です。 -XX:SoftRefLRUPolicyMSPerMBオプションは、現在のヒープ・サイズ(Java HotSpot Client VMの場合)または最大許容ヒープ・サイズ(Java HotSpot Server VMの場合)の1メガバイト当たりのミリ秒を表す整数値を受け付けます。 この違いは、Client VMがヒープを拡大するより、ソフト参照をフラッシュする傾向があり、Server VMがソフト参照をフラッシュするより、ヒープを拡大する傾向があることを意味します。 後者の場合、-Xmxオプションの値は、ソフト参照がガベージ・コレクションされる速さに大きく影響します。

次の例は、値を2.5秒に設定する方法を示しています。

-XX:SoftRefLRUPolicyMSPerMB=2500

-XX:-ShrinkHeapInSteps

-XX:MaxHeapFreeRatioオプションで指定されたターゲット・サイズにJavaヒープを増分的に削減します。 このオプションはデフォルトでは有効になります。 無効にすると、複数のガーベジ・コレクション・サイクルを要求するかわりにJavaヒープを目標サイズまで即時減らします。 Javaヒープ・サイズを最小限にするには、このオプションを使用不可にします。 このオプションを無効にすると、パフォーマンスが低下する可能性があります。

埋込みアプリケーションの動的フットプリントを削減することによってJavaヒープを小さく保つためにMaxHeapFreeRatioオプションを使用する方法の詳細は、「パフォーマンス・チューニングの例」を参照してください。

-XX:StringDeduplicationAgeThreshold=threshold

複製解除の候補とみなされる、指定された年齢に達するStringオブジェクトを識別します。 オブジェクトの期間は、オブジェクトがガベージ・コレクションで存続した回数の測定値です。 これは、リングと呼ばれることもあります。

ノート: この期間に達する前に古いヒープ・リージョンにプロモートされたStringオブジェクトは、常に重複除去の候補とみなされます。 このオプションのデフォルト値は3です。 -XX:+UseStringDeduplicationオプションを参照してください。

-XX:SurvivorRatio=ratio

Eden領域サイズとSurvivor領域サイズの比率を設定します。 デフォルトでは、このオプションは8に設定されます。 次の例は、Eden/Survivor領域率を4に設定する方法を示しています。

-XX:SurvivorRatio=4

-XX:TargetSurvivorRatio=percent

Youngガベージ・コレクション後に使用されるSurvivor領域の目的のパーセンテージ(0から100)を設定します。 デフォルトで、このオプションは50%に設定されます。

次の例は、ターゲットのSurvivor領域率を30%に設定する方法を示しています。

-XX:TargetSurvivorRatio=30

-XX:TLABSize=size

スレッドローカル割当てバッファ(TLAB)の初期サイズ(バイト単位)を設定します。 文字kまたはKを追加してキロバイトを示し、mまたはMを追加してメガバイトを示し、gまたはGを追加してギガバイトを示します。 このオプションが0に設定されている場合、JVMは初期サイズを自動的に選択します。

次の例は、初期TLABサイズを512Kバイトに設定する方法を示しています。

-XX:TLABSize=512k

-XX:+UseAdaptiveSizePolicy
適応型世代サイズ変更の使用を有効にします。 このオプションはデフォルトでは有効になります。 適応生成のサイズ設定を無効にするには、-XX:-UseAdaptiveSizePolicyを指定し、メモリー割当てプールのサイズを明示的に設定します。 -XX:SurvivorRatioオプションを参照してください。
-XX:+UseG1GC
ガベージファースト(G1)・ガベージ・コレクタの使用を有効にします。 それは、大容量のRAMを搭載するマルチプロセッサ・マシンを対象とした、サーバースタイル・ガベージ・コレクタです。 このオプションは、GC一時停止時間目標を高い確率で満たしながら、優れたスループットを維持します。 大きなヒープ(およそ6GB以上のサイズ)を必要とし、GC待機時間の制限の要件(0.5秒未満の安定した予測可能な一時停止時間)のあるアプリケーションには、G1コレクタをお薦めします。 デフォルトでは、このオプションは有効になっており、G1がデフォルトのガーベジ・コレクタとして使用されます。
-XX:+UseGCOverheadLimit
OutOfMemoryError例外がスローされるまでに、GCへのJVMによって費やされる時間の割合を制限するポリシーを使用できます。 このオプションはデフォルトで有効になっており、合計時間の98%以上がガベージ・コレクションに費やされ、ヒープの2%未満がリカバリされた場合は、パラレルGCによってOutOfMemoryErrorがスローされます。 ヒープが小さい場合、この機能は、アプリケーションが長時間ほとんどまたはまったく進捗なしで実行することを防ぐために使用できます。 このオプションを無効にするには、オプション-XX:-UseGCOverheadLimitを指定します。
-XX:+UseNUMA
アプリケーションの待機時間の短いメモリーの使用を増やすことで、NUMA (Non-Uniform Memory Architecture)を使用したマシン上のアプリケーションのパフォーマンスの最適化を有効にします。 デフォルトでは、このオプションは無効になっており、NUMAの最適化は行われません。 このオプションは、パラレル・ガベージ・コレクタが(-XX:+UseParallelGC)を使用している場合にのみ使用できます。
-XX:+UseParallelGC

複数のプロセッサを利用することによってアプリケーションのパフォーマンスを向上させるために、Parallel Scavengeガベージ・コレクタ(スループット・コレクタとも呼ばれる)の使用を有効にします。

デフォルトでは、このオプションは無効になっており、デフォルトのコレクタが使用されます。

-XX:+UseSerialGC
シリアル・ガベージ・コレクタの使用を有効にします。 これは一般に、ガベージ・コレクションの特別な機能を必要としない小さく単純なアプリケーションには最適な選択です。 デフォルトでは、このオプションは無効になっており、デフォルトのコレクタが使用されます。
-XX:+UseStringDeduplication

文字列の重複除外を有効化します。 デフォルトでは、このオプションは無効になっています。 このオプションを使用するには、ガベージファースト(G1)・ガベージ・コレクタを有効にする必要があります。

多くのStringオブジェクトが同じであるということから、String deduplicationにより、Javaヒープ上のStringオブジェクトのメモリー・フットプリントが削減されます。 各Stringオブジェクトが独自の文字配列をポイントするのではなく、同一のStringオブジェクトは同じ文字配列をポイントし共有できます。

-XX:+UseTLAB
Young世代の領域で、スレッドローカル割当てブロック(TLAB)の使用を有効にします。 このオプションはデフォルトでは有効になります。 TLABの使用を無効にするには、オプション-XX:-UseTLABを指定します。
-XX:+UseZGC
Zガベージ・コレクタ(ZGC)の使用を有効にします。 これは低レイテンシのガベージ・コレクタで、スループット・コストで数ミリ秒の最大一時停止時間を提供します。 一時停止時間は、使用されているヒープ・サイズとは無関係です。 8MBから16TBまでのヒープ・サイズをサポートします。
-XX:ZAllocationSpikeTolerance=factor
ZGCの割当てスパイク・トレランスを設定します。 デフォルトでは、このオプションは2.0に設定されます。 この係数は、予想される割当てスパイクのレベルを示します。 たとえば、3.0のファクタを使用すると、現在の割当て率はいつでもトリプル化できることを意味します。
-XX:ZCollectionInterval=seconds
ZGCの使用時に、2つのGCサイクル間の最大間隔(秒単位)を設定します。 デフォルトでは、このオプションは0 (disabled)に設定されています。
-XX:ZFragmentationLimit=percent
ZGCの最大許容ヒープ断片化(パーセント単位)を設定します。 デフォルトでは、このオプションは25に設定されています。 低い値を使用すると、ヒープがより積極的に圧縮され、CPU時間の増加に伴ってより多くのメモリーが再利用されます。
-XX:+ZProactive
ZGCの使用時にプロアクティブGCサイクルを有効にします。 デフォルトでは、このオプションは有効です。 ZGCは、実行中のアプリケーションへの影響を最小限に抑えることが期待される場合、プロアクティブGCサイクルを開始します。 これは、アプリケーションがほとんどアイドル状態であるか、非常に少数のオブジェクトを割り当てているが、ヒープ・サイズを小さくして、ヒープに多くの空き領域がある場合でも参照処理を実行できるようにする場合に便利です。
-XX:+ZUncommit
ZGCの使用時に未使用ヒープ・メモリーの非コミットを有効にします。 デフォルトでは、このオプションは有効です。 未使用のヒープ・メモリーをコミット解除すると、JVMのメモリー・フットプリントが減少し、そのメモリーを他のプロセスで使用できるようになります。
-XX:ZUncommitDelay=seconds
(秒単位)でヒープ・メモリーが未使用である必要がある時間を設定します。この時間が経過すると、ヒープ・メモリーはコミットされません。 デフォルトでは、このオプションは300 (5分)に設定されています。 メモリーのコミットおよびコミット解除は、比較的コストのかかる操作です。 小さい値を使用すると、ヒープ・メモリーはすぐに再度コミットする必要があるというリスクで、以前にコミット解除されます。

非推奨のjavaオプション

これらのjavaオプションは非推奨であり、将来のJDKリリースで削除される可能性があります。 これらは引き続き使用可能で作用しますが、使用すると警告が発行されます。

-Xloggc:filename

ロギングのため、詳細GCイベント情報をリダイレクトするファイルを設定します。 両方が同じjavaコマンドで指定されている場合、-Xloggcオプションは-verbose:gcをオーバーライドします。-Xloggc: filenameは、-Xlog:gc: filenameに置き換えられています。 「JVM統合ロギングフレームワークを使用したロギングの有効化」を参照してください。

例:

-Xlog:gc:garbage-collection.log

-XX:+FlightRecorder
アプリケーション実行時のJava Flight Recorder (JFR)の使用を有効にします。 JDK 8u40以降、このオプションはJFRを使用するために必要ありません。

廃止されたjavaオプション

これらのjavaオプションは引き続き受け入れられますが無視され、使用時に警告が発行されます。

--illegal-access=parameter
JEP 261で定義されているように、「リラックスした強いカプセル化」を制御します。 このオプションは、JDK 16ではJEP 396によって非推奨となり、JDK 17ではJEP 403によって廃止されました。
-XX:RTMAbortRatio=abort_ratio
RTM中止率を、すべての実行済RTMトランザクションに対するパーセンテージ(%)として指定します。 中止されたトランザクション数がこの率を超えた場合、コンパイルされたコードが非最適化されます。 この率は、-XX:+UseRTMDeoptオプションが有効な場合に使用されます。 このオプションのデフォルト値は50です。 つまり、すべてのトランザクションの50%が中止された場合、コンパイルされたコードが非最適化されます。
-XX:RTMRetryCount=number_of_retries
中止またはビジー状態の場合、通常のロック・メカニズムに戻るまでにRTMロック・コードが再試行される回数を指定します。 このオプションのデフォルト値は5です。 -XX:UseRTMLockingオプションを有効化する必要があります。
-XX:+UseRTMDeopt
中止率に応じて、RTMロックを自動調整します。 この比率は、-XX:RTMAbortRatioオプションで指定します。 中止されたトランザクション数が中止率を超えた場合、ロックを含むメソッドがすべてのロックで標準のロックとして非最適化および再コンパイルされます。 このオプションはデフォルトでは無効です。 -XX:+UseRTMLockingオプションを有効にする必要があります。
-XX:+UseRTMLocking

フォールバック・ハンドラとして標準のロック・メカニズムを使用して、展開されたすべてのロックに対してRestricted Transactional Memory (RTM)ロック・コードを生成します。 このオプションはデフォルトでは無効です。 RTMに関連するオプションは、Transactional Synchronization Extensions (TSX)をサポートするx86 CPUでのみ使用できます。

RTMは、x86命令セット拡張でマルチスレッド・アプリケーションの作成を容易にするIntelのTSXの一部です。 RTMでは、新しい命令 XBEGIN、XABORT、XENDおよびXTESTが導入されています。 XBEGINおよびXEND命令は、トランザクションとして実行するための命令セットを囲みます。 トランザクションの実行時に競合が見つからない場合、メモリーとレジスタの変更はXEND命令で一緒にコミットされます。 XABORT命令を使用すると、トランザクションを明示的に中断でき、XTEST命令は一連の命令がトランザクションで実行されているかどうかをチェックします。

トランザクションのロックは、別のスレッドが同じトランザクションにアクセスしようとしたときに展開されます。したがって、そのトランザクションへのアクセスを当初リクエストしなかったスレッドはブロックされます。 RTMでは、トランザクションが中止または失敗した場合のために、フォールバックの操作セットを指定する必要があります。 RTMロックとは、TSXのシステムに委譲されているロックです。

RTMにより、重要なリージョンにおいて衝突が少なく競合度の高いロックのパフォーマンスが向上されます(これは、複数のスレッドによって同時にアクセスできないコードです)。 また、RTMにより、粗粒度ロックのパフォーマンスも向上されますが、一般的にマルチスレッド・アプリケーションでのパフォーマンスはよくありません。 (粗粒度ロックとは、ロックの取得および解放のオーバーヘッドを最小化するために長い期間ロックを保持する戦略であり、一方、細粒度ロックとは必要な場合のみロックし可能なかぎり早期にロック解除することで最大限の並行処理の達成を試みる戦略です。) さらに、異なるスレッドによって使用されている軽度な競合ロックの場合、RTMにより、誤ったキャッシュ・ライン共有(キャッシュ・ライン・ピンポンとも呼ばれる)を削減できます。 これは、異なるプロセッサからの複数のスレッドが異なるリソースにアクセスしている場合に発生しますが、リソースは同じキャッシュ・ラインを共有します。 結果として、プロセッサは他のプロセッサのキャッシュ・ラインを繰り返し無効にし、これにより、キャッシュではなくメイン・メモリーからの読取りが強制されます。

削除されたjavaオプション

これらのjavaオプションはJDK 24で削除され、それを使用すると次のエラーになります:

Unrecognized VM option option-name

-XX:InitialRAMFraction=ratio

JVMがJavaヒープに対して使用できる初期メモリー容量を設定します。これを超えると、人間工学に基づいたヒューリスティックが-XX:MaxRAMオプションで指定された最大量の比率として適用されます。 デフォルト値は「64」です。

かわりに、-XX:InitialRAMPercentageオプションを使用してください。

-XX:MaxRAMFraction=ratio

JVMがJavaヒープに使用できる最大メモリー容量を設定します。これを超えると、人間工学に基づくヒューリスティックが-XX:MaxRAMオプションの記述に従って決定される最大量の割合として適用されます。 デフォルト値は4です。

このオプションを指定すると、このオプションを組み合せた結果と、メモリーの最大量に影響するその他のオプションが、圧縮されたoopで圧縮可能なメモリー・アドレスの範囲よりも大きい場合に、圧縮されたoopsの自動使用が無効になります。 圧縮oopsの詳細は、-XX:UseCompressedOopsを参照してください。

かわりに、-XX:MaxRAMPercentageオプションを使用してください。

-XX:MinRAMFraction=ratio

JVMがJavaヒープに使用できる最大メモリー容量を設定します。これを超えると、小さなヒープの-XX:MaxRAMオプションの説明に従って、人間工学に基づいた最大量の割合として検証されます。 小さいヒープは、約125 MBのヒープです。 デフォルト値は2です。

かわりに、-XX:MinRAMPercentageオプションを使用してください。

-XX:+ScavengeBeforeFullGC
各フルGCの前にYoung世代のGCを有効にします。 このオプションはデフォルトでは有効になります。 完全なGCの前に若い生成をスカーニングすると、古い生成領域から到達可能なオブジェクトの数が自分の生成領域に削減されるため、無効にしないことをお薦めします。 完全GCの前に若い世代のGCを無効にするには、オプション-XX:-ScavengeBeforeFullGCを指定します。
-Xfuture

クラスファイル形式の仕様への厳密な準拠を適用するクラスファイル形式の厳密なチェックを有効にします。 開発者は、新しいコードを開発するときにこのフラグを使用する必要があります。 将来のリリースでは、より厳密なチェックがデフォルトになることがあります。

かわりに、-Xverify:allオプションを使用してください。

以前のリリースで削除されたオプションのリストおよび説明は、次の「削除されたJavaオプション」のセクションを参照してください:

javaコマンドライン引数ファイル

javaコマンドを短縮または簡略化するには、@引数ファイルを使用して、javaコマンドに渡されるオプションやクラス名などの引数を含む1つ以上のテキスト・ファイルを指定します。 これにより、任意のオペレーティング・システムで任意の長さのjavaコマンドを作成できます。

コマンド行で、アットマーク(@)プレフィクスを使用して、javaオプションおよびクラス名を含む引数ファイルを識別します。 javaコマンドで、アットマーク(@)から始まるファイルが検出されると、そのファイルの内容が、コマンドラインに指定されるとおりに引数リストに拡張されます。

javaランチャは、--disable-@filesオプションを見つけるまで引数ファイルの内容を展開します。 --disable-@filesオプションは、引数ファイルを含むコマンド行の任意の場所で使用して、@引数ファイルの展開を停止できます。

次のアイテムでは、java引数ファイルの構文について説明します:

引数ファイル内の引用符または引用符の例

引数ファイルでは、

-cp "lib/
cool/
app/
jars

これは、次のように解析されます。

-cp lib/cool/app/jars

引数ファイルでの別のバックスラッシュ文字でエスケープされたバックスラッシュ文字の例

次のように出力するには、

-cp c:\Program Files (x86)\Java\jre\lib\ext;c:\Program Files\Java\jre9\lib\ext

次のように引数ファイルでバックスラッシュ文字を指定する必要があります。

-cp "c:\\Program Files (x86)\\Java\\jre\\lib\\ext;c:\\Program Files\\Java\\jre9\\lib\\ext"

引数ファイル内の行の連結を強制するために使用されるEOLエスケープの例

引数ファイルでは、

-cp "/lib/cool app/jars:\
    /lib/another app/jars"

これは、次のように解析されます。

-cp /lib/cool app/jars:/lib/another app/jars

引数ファイル内の先行するスペースによる行継続の例

引数ファイルでは、

-cp "/lib/cool\
\app/jars"

これは、次のように解析されます。

-cp /lib/cool app/jars

単一引数ファイルの使用例

次の例のmyargumentfileなどの単一の引数ファイルを使用して、必要なすべてのjava引数を保持できます:

java @myargumentfile

パス付き引数ファイルの使用例

引数ファイルには相対パスを挿入できますが、これらは現在の作業ディレクトリに対して相対的であり、引数ファイル自体のパスに対してではありません。 次の例では、path1/optionsおよびpath2/optionsは、パスが異なる引数ファイルを表します。 含まれている相対パスは、現在の作業ディレクトリと相対的であり、引数ファイルではありません:

java @path1/options @path2/classes

コード・ヒープの状態の分析

概要

JVMコード・ヒープの現在の状態を把握することにより、次のような疑問に答える上で役立つ場合があります。

これを把握するため、コード・ヒープのオンザフライ分析を可能にするコード・ヒープの状態の分析機能が実装されました。 分析プロセスは2つのパートに分かれています。 最初のパートでは、コード・ヒープ全体を調べて、有用または重要と判断されたすべての情報が集約されます。 2番目のパートは複数の独立したステップで構成されており、収集された情報がデータの様々な側面に重点を置いて出力されます。 データの収集と出力は、「リクエスト」ベースで実行されます。

構文

リアルタイムのオンザフライ分析のリクエストは、次のコマンドを使用して発行できます。

jcmd pid Compiler.CodeHeap_Analytics [function] [granularity]

サンプル・ワークロードを実行した後にコード・ヒープがどのように表示されるかを確認するだけの場合は、次のコマンド行オプションを使用します。

-Xlog:codecache=Trace

「CodeCache full」状況が存在する場合のコード・ヒープの状態を確認するには、次のコマンド行オプションを使用してVMを起動します。

-Xlog:codecache=Debug

コード・ヒープの状態の分析機能、サポートされている関数および粒度オプションの詳細は、『CodeHeap State Analytics (OpenJDK)』を参照してください。

JVM統合ログ・フレームワークでのログを有効にします

-Xlogオプションを使用して、Java Virtual Machine (JVM)統合ロギング・フレームワークを使用してロギングを構成または有効化します。

シノプシス

-Xlog[:[what][:[output][:[decorators][:output-options[,...]]]]]

-Xlog:directive

what
タグとレベルの組合せを指定します(tag1 [+ tag2...] [*] [= level] [,...])。 ワイルドカード(*)が指定されないかぎり、指定したタグでタグ付けされたログ・メッセージのみが一致します。 「-Xlogのタグとレベル」を参照してください。
output
出力のタイプを設定します。 output型を省略すると、デフォルトでstdoutになります。 「-Xlogの出力」を参照してください。
decorators
カスタムのデコレータ・セットを使用するように出力を構成します。 decoratorsを省略すると、デフォルトでuptime、levelおよびtagsになります。 「装飾」を参照してください。
output-options
-Xlogロギング出力オプションを設定します。
ディレクティブ
グローバル・オプションまたはサブコマンド: help、disable、async

説明

Java Virtual Machine (JVM)統合ログ・フレームワークは、JVMのすべてのコンポーネントに共通のログ・システムを提供します。 JVMのGCロギングが新しいロギング・フレームワークを使用するように変更されました。 古いGCフラグの対応する新しいXlog構成へのマッピングは、「GCロギング・フラグをXlogに変換」で説明されています。 また、ランタイム・ロギングもJVM統合ロギング・フレームワークを使用するように変更されています。 レガシー・ランタイム・ロギング・フラグの対応する新しいXlog構成へのマッピングは、「ランタイム・ログ・フラグをXlogに変換」で説明されています。

次に、-Xlogコマンドおよびオプションの構文のクイック・リファレンスを示します:

-Xlog
infoレベルでJVMロギングを有効にします。
-Xlog:help
-Xlogの使用法構文、使用可能なタグ、レベル、およびデコレータを、説明付きのコマンド行例とともに出力します。
-Xlog:disable
すべてのロギングをオフにし、警告とエラーのデフォルト構成を含むロギング・フレームワークのすべての構成をクリアします。
-Xlog[:option]

コマンド行で表示される順で複数の引数を適用します。 同じ出力に対して複数の-Xlog引数を指定すると、指定された順序で相互にオーバーライドされます。

optionは次のように設定されます:

[tag-selection][:[output][:[decorators][:output-options]]]

tag-selectionのデフォルトをallのタグ・セットとinfoのレベルに設定しないでください。

tag[+...] all

allタグは、使用可能なすべてのタグ・セットで構成されるメタ・タグです。 タグ・セット定義のアスタリスク*は、ワイルドカード・タグの一致を示します。 ワイルドカードと照合すると、指定したタグが「少なくとも」を含むすべてのタグ・セットが選択されます。 ワイルドカードがないと、指定されたタグ・セットの完全一致のみが選択されます。

output-optionsは

filecount= file-count filesize= オプションのK、M、またはGのサフィクスを含むファイル・サイズ foldmultilines=<true|false>

foldmultilinesがtrueの場合、複数の行で構成されるログ・イベントは、改行文字を出力のシーケンス'\'および'n'に置き換えることで、1行に折り返されます。 既存の1つのバックスラッシュ文字も2つのバックスラッシュで置き換えられ、変換を元に戻すことができます。 このオプションは、UTF-8文字エンコーディングでは安全に使用できますが、ほかのエンコーディングが動作しない可能性があります。 たとえば、Shift JISおよびBIG5でマルチバイト・シーケンスを誤って変換する可能性があります。

デフォルトの構成

-Xlogオプションがコマンド行でほかに何も指定されていない場合は、デフォルトの構成が使用されます。 デフォルトの構成では、メッセージがどのタグに関連付けられているかに関係なく、警告またはエラーのいずれかに一致するレベルのすべてのメッセージが記録されます。 デフォルトの構成は、コマンド行で次を入力するのと同等です。

-Xlog:all=warning:stdout:uptime,level,tags

実行時のロギングの制御

ログは、診断コマンド (jcmdユーティリティを使用)を使用して実行時に制御することもできます。 コマンド行で指定できるすべてのものは、VM.logコマンドを使用して動的に指定することもできます。 診断コマンドはMBeanとして自動的に公開されるため、JMXを使用して実行時にロギング構成を変更できます。

-Xlogのタグとレベル

各ログ・メッセージにはレベルとタグ・セットが関連付けられています。 メッセージのレベルはその詳細に対応し、タグ・セットはメッセージの内容や(gc、jit、osなど)に関連するJVMコンポーネントに対応します。 GCフラグをXlog構成にマッピングする方法については、「GCロギング・フラグをXlogに変換」を参照してください。 レガシー・ランタイム・ロギング・フラグを対応するXlog構成にマップする方法については、「ランタイム・ログ・フラグをXlogに変換」を参照してください。

使用可能なログ・レベル:

使用可能なログ・タグ:

同様に、一連のログ・タグが右側の組合せにあり、ロギング出力の範囲を有効にします。 -Xlog:helpを使用すると、使用可能なログ・タグの完全なセットを表示できます。 タグの組合せのかわりにallを指定すると、すべてのタグの組合せに一致します。

-Xlogの出力

-Xlogオプションは、次のタイプの出力をサポートします:

file= filenameを使用する場合、%p、%tまたは%hn(あるいはその両方)をファイル名に指定すると、それぞれJVMのPID、起動タイムスタンプおよびホスト名に展開されます。 ファイル・サイズと回転するファイル数に基づいて、ファイルの回転を処理するようにテキスト・ファイルを構成することもできます。 たとえば、ログ・ファイルを10 MBごとにローテーションし、5ファイルをローテーションして保持するには、オプションfilesize=10M, filecount=5を指定します。 ファイルのターゲット・サイズは正確には保証されず、おおよその値となります。 別の方法で構成されていない限り、ファイルはデフォルトで回転され、ターゲット・サイズが20 MBの回転ファイルが最大5個あります。 filecount=0を指定すると、ログ・ファイルはローテーションされません。 既存のログ・ファイルが上書きされる可能性があります。

-Xlog出力モード

デフォルトでは、ロギング・メッセージは同期的に出力されます - 各ログ・メッセージは、ロギング呼び出しが行われると、指定された出力に書き込まれます。 ただし、かわりに次のものを指定して非同期ロギング・モードを使用できます:

-Xlog:async
すべてのロギングを非同期に書き込みます。

非同期ロギング・モードでは、ログ・サイトはすべてのロギング・メッセージを中間バッファにエンキューし、スタンドアロン・スレッドは対応する出力にフラッシュします。 中間バッファがバインドされ、エンキュー・メッセージは破棄されます。 ログ・エントリの書込み操作は、非ブロッキングが保証されます。

オプション-XX:AsyncLogBufferSize=Nは、中間バッファのメモリー予算をバイト単位で指定します。 ほとんどの場合、デフォルト値は収容できる大きさである必要があります。 ユーザーは、必要に応じて、メモリー・オーバーヘッドをトレードしてログ精度を高めるカスタム値を指定できます。

装飾

ログ・メッセージには、メッセージに関する情報が装飾されています。 独自のデコレータ・セットを使用するように各出力を構成できます。 出力の順序は、常に表にリストされているものと同じです。 実行時に使用されるようにデコレーションを構成できます。 装飾はログ・メッセージの前に付加されます。 たとえば: 

[6.567s][info][gc,old] Old collection complete

decoratorsを省略すると、デフォルトでuptime、levelおよびtagsになります。 noneデコレータは特殊で、すべてのデコレーションをオフにするために使用されます。

time (t)、utctime (utc)、uptime (u)、timemillis (tm)、uptimemillis (um)、timenanos (tn)、uptimenanos (un)、hostname (hn)、pid (p)、tid (ti)、level (l)、tags (tg)デコレータを装飾なしでnoneとして指定することもできます。

ロギング・メッセージの装飾
装飾 説明
timeまたはt ISO-8601形式の現在の日付と時間。
utctimeまたはutc ユニバーサル・タイム協定または協定世界時。
uptimeまたはu JVMの開始からの秒数とミリ秒単位の時間。 たとえば、6.567sです。
timemillisまたはtm System.currentTimeMillis()によって生成された値と同じ値
uptimemillisまたはum JVMが開始されてからのミリ秒。
timenanosまたはtn System.nanoTime()によって生成される値と同じ値。
uptimenanosまたはun JVMが開始されてからのナノ秒。
hostnameまたはhn ホスト名。
pidまたはp プロセス識別子
tidまたはti スレッド識別子。
levelまたはl ログ・メッセージに関連付けられたレベル。
tagsまたはtg ログ・メッセージに関連付けられたタグ・セット。

GCロギング・フラグをXlogに変換

Xlog構成マッピングへのレガシーGCロギング・フラグ
レガシー・ガベージ・コレクション(GC) Flag Xlogの構成 コメント
G1PrintHeapRegions -Xlog:gc+region=trace 該当なし
GCLogFileSize 構成なし ログのローテーションはフレームワークによって処理されます。
NumberOfGCLogFiles 該当なし ログのローテーションはフレームワークによって処理されます。
PrintAdaptiveSizePolicy -Xlog:gc+ergo*=level ほとんどの情報にはdebugのlevelを使用し、PrintAdaptiveSizePolicyのログに記録されたすべての情報にはtraceのlevelを使用します。
PrintGC -Xlog:gc 該当なし
PrintGCApplicationConcurrentTime -Xlog:safepoint PrintGCApplicationConcurrentTimeとPrintGCApplicationStoppedTimeは同じタグでログに記録され、新しいロギングでは分離されません。
PrintGCApplicationStoppedTime -Xlog:safepoint PrintGCApplicationConcurrentTimeとPrintGCApplicationStoppedTimeは同じタグでログに記録され、新しいロギングでは分離されません。
PrintGCCause 該当なし GCの原因が常にログに記録されるようになりました。
PrintGCDateStamps 該当なし 日付スタンプはフレームワークによって記録されます。
PrintGCDetails -Xlog:gc* 該当なし
PrintGCID 該当なし GC IDは常に記録されるようになりました。
PrintGCTaskTimeStamps -Xlog:gc+task*=debug 該当なし
PrintGCTimeStamps 該当なし タイムスタンプはフレームワークによって記録されます。
PrintHeapAtGC -Xlog:gc+heap=trace 該当なし
PrintReferenceGC -Xlog:gc+ref*=debug 古いロギングでは、PrintReferenceGCはPrintGCDetailsも有効になっている場合にのみ有効でした。
PrintStringDeduplicationStatistics `-Xlog:gc+stringdedup*=debug `適用不可
PrintTenuringDistribution -Xlog:gc+age*=level 最も関連性の高い情報にはlevelのdebugを使用し、PrintTenuringDistributionについてログに記録されたすべての情報にはtraceのlevelを使用します。
UseGCLogFileRotation 該当なし PrintTenuringDistributionのログに記録された内容。

ランタイム・ログ・フラグをXlogに変換

これらのレガシー・フラグは認識されなくなり、直接使用するとエラーが発生します。 かわりに、統合ロギングを使用します。

Xlog構成マッピングへのランタイム・ロギング・フラグ
レガシー・ランタイム・フラグ Xlogの構成 コメント
TraceExceptions -Xlog:exceptions=info 該当なし
TraceClassLoading -Xlog:class+load=level 通常の情報にはlevel = infoを、追加情報にはlevel = debugを使用します。 統合ロギング構文では、-verbose:classは-Xlog:class+load=info,class+unload=infoです。
TraceClassLoadingPreorder -Xlog:class+preorder=debug 該当なし
TraceClassUnloading -Xlog:class+unload=level 通常の情報にはlevel=infoを、追加情報にはlevel=traceを使用します。 統合ロギング構文では、-verbose:classは-Xlog:class+load=info,class+unload=infoです。
VerboseVerification -Xlog:verification=info 該当なし
TraceClassPaths -Xlog:class+path=info 該当なし
TraceClassResolution -Xlog:class+resolve=debug 該当なし
TraceClassInitialization -Xlog:class+init=info 該当なし
TraceLoaderConstraints -Xlog:class+loader+constraints=info 該当なし
TraceClassLoaderData -Xlog:class+loader+data=level 追加情報については、level=debugを使用します。追加情報については、level=traceを使用します。
TraceSafepointCleanupTime -Xlog:safepoint+cleanup=info 該当なし
TraceSafepoint -Xlog:safepoint=debug 該当なし
TraceMonitorInflation -Xlog:monitorinflation=debug 該当なし
TraceRedefineClasses -Xlog:redefine+class*=level level=info、debug、およびtraceによって増加する情報が提供されます。

-Xlog使用例

次に、-Xlogの例を示します。

-Xlog

infoレベルを使用して、uptime、levelsおよびtagsデコレーションを含むstdoutにすべてのメッセージをログに記録します。 これは以下を使用するのと同じです:

-Xlog:all=info:stdout:uptime,levels,tags

-Xlog:gc
infoレベルを使用してgcタグでタグ付けされたメッセージをstdoutに記録します。 レベルwarningの他のすべてのメッセージのデフォルト構成が有効です。
-Xlog:gc,safepoint
infoレベルを使用して、gcまたはsafepointタグのいずれかでタグ付けされたメッセージを、デフォルトの装飾を使用してstdoutに記録します。 gcとsafepointの両方がタグ付けされたメッセージはログに記録されません。
-Xlog:gc+ref=debug
gcとrefの両方のタグでタグ付けされたメッセージをログに記録し、debugレベルをstdoutに設定し、デフォルトの装飾を使用します。 この2つのタグのいずれかのみでタグ付けされたメッセージは記録されません。
-Xlog:gc=debug:file=gc.txt:none
debugレベルを使用してgcタグでタグ付けされたメッセージを、装飾なしでgc.txtというファイルにログに記録します。 レベルwarningの他のすべてのメッセージのデフォルト構成は、引き続き有効です。
-Xlog:gc=trace:file=gctrace.txt:uptimemillis,pid:filecount=5,filesize=1024

traceレベルを使用してgcタグでタグ付けされたメッセージを、ベース名gctrace.txtでサイズ1 MBの5つのファイルを含むローテーション・ファイル・セットに記録し、デコレーションuptimemillisおよびpidを使用します。

レベルwarningの他のすべてのメッセージのデフォルト構成は、引き続き有効です。

-Xlog:gc::uptime,tid
デフォルトの'info'レベルを使用してgcタグでタグ付けされたメッセージをログに記録し、出力stdoutをデフォルト設定し、デコレーションuptimeおよびtidを使用します。 レベルwarningの他のすべてのメッセージのデフォルト構成は、引き続き有効です。
-Xlog:gc*=info,safepoint*=off
infoレベルを使用して、少なくともgcでタグ付けされたメッセージをログに記録しますが、safepointでタグ付けされたメッセージのロギングは無効になります。 gcとsafepointの両方がタグ付けされたメッセージはログに記録されません。
-Xlog:disable -Xlog:safepoint=trace:safepointtrace.txt
警告やエラーを含むすべてのロギングを無効にし、traceレベルを使用してsafepointでタグ付けされたメッセージをファイルsafepointtrace.txtに対して有効にします。 コマンドラインが-Xlog:disableで開始されたため、デフォルトの構成は適用されません。

複合 -Xlog使用例

次に、-Xlogオプションを使用するいくつかの複雑な例を示します。

-Xlog:gc+class*=debug
debugレベルを使用して、少なくともgcおよびclassタグでタグ付けされたメッセージをstdoutに記録します。 レベルwarningの他のすべてのメッセージのデフォルト構成は引き続き有効です
-Xlog:gc+meta*=trace,class*=off:file=gcmetatrace.txt
traceレベルを使用して、少なくともgcおよびmetaタグでタグ付けされたメッセージをファイルmetatrace.txtに記録しますが、classでタグ付けされたすべてのメッセージは無効になります。 gc、metaおよびclassでタグ付けされたメッセージは、class*がoffに設定されているため、ログに記録されません。 レベルwarningの他のすべてのメッセージのデフォルト構成は、classを含むものを除き有効です。
-Xlog:gc+meta=trace
traceレベルを使用してgcおよびmetaタグでタグ付けされたメッセージをstdoutに記録します。 レベルwarningの他のすべてのメッセージのデフォルト構成は、引き続き有効です。
-Xlog:gc+class+heap*=debug,meta*=warning,threads*=off
traceレベルを使用して、少なくともgc、classおよびheapタグでタグ付けされたメッセージをstdoutに記録しますが、レベルがmetaのタグが付いたメッセージのみをログに記録します。 レベルwarningの他のすべてのメッセージのデフォルト構成は、threadsを含むものを除き有効です。

Java Virtual Machineのフラグ引数を検証

検証のためにすべてのJava Virtual Machine (JVM)コマンドライン・フラグに指定された値を使用し、入力値が無効または範囲外の場合は、適切なエラー・メッセージが表示されます。

人間工学的に設定するか、コマンドラインで設定するか、入力ツールを使用するか、API (たとえば、パッケージjava.lang.managementに含まれるクラスです)を使用して設定するかに関係なく、すべてのJava Virtual Machine (JVM)コマンドライン・フラグに指定された値が検証されます。 人間工学の詳細は、Java Platform, Standard Edition HotSpot仮想マシン・ガベージ・コレクション・チューニング・ガイドを参照してください。

範囲と制約は、JVMの初期化中にすべてのフラグの値が設定されているか、ランタイム中にフラグの値が変更されたときに検証されます。(例: jcmdツールの使用)。 値が範囲または制約チェックに違反した場合、JVMは終了し、該当するエラー・メッセージがエラー・ストリームに出力されます。

たとえば、フラグが範囲または制約チェックに違反すると、JVMはエラーで終了します。

java -XX:AllocatePrefetchStyle=5 -version
intx AllocatePrefetchStyle=5 is outside the allowed range [ 0 ... 3 ]
Improperly specified VM option 'AllocatePrefetchStyle=5'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

-XX:+PrintFlagsRangesフラグは、すべてのフラグの範囲を出力します。 このフラグは、範囲によって提供される値によるフラグの自動テストを可能にします。 範囲が指定されたフラグの場合、型、名前、および実際の範囲が出力に出力されます。

たとえば、

intx   ThreadStackSize [ 0 ... 9007199254740987 ] {pd product}

範囲が指定されていないフラグの場合は、値が出力に表示されません。 たとえば: 

size_t NewSize         [   ...                  ] {product}

これは、実装が必要なフラグを識別するのに役立ちます。 自動テスト・フレームワークでは、値がなく実装されないフラグをスキップできます。

ラージ・ページ

巨大ページとも呼ばれる大きなページは、標準メモリー・ページ・サイズ(プロセッサとオペレーティング・システムによって異なります)よりもかなり大きなメモリー・ページとして使用します。 ラージ・ページは、プロセッサのTranslation-Lookaside Bufferを最適化します。

Translation-Lookaside Buffer (TLB)は、最近使用された仮想から物理へのアドレス変換を保持するページ変換キャッシュです。 TLBは、少ないシステム・リソースです。 プロセッサが複数のメモリー・アクセスが必要な場合のある階層ページ表から読み取る必要があるため、TLBミスは負荷がかかる可能性があります。 大きいメモリー・ページ・サイズを使用して、単一のTLBエントリで大きいメモリー範囲を表すことができます。 これにより、TLB不足が少なくなり、メモリー集約型のアプリケーションのパフォーマンスが向上する可能性があります。

ただし、大きいページを使用すると、システムのパフォーマンスに悪影響を及ぼす場合があります。 たとえば、アプリケーションで大量のメモリーが確保されると、通常のメモリーが不足し、他のアプリケーションで過剰なページングが発生し、システム全体が遅くなる可能性があります。 また、長時間稼働しているシステムは、過剰な断片化が発生する可能性があります。これにより、十分な大きさのページ・メモリーを予約できない可能性があります。 これが発生した場合、OSまたはJVMのいずれかが通常のページの使用に戻ります。

LinuxおよびWindowsでは、ラージ・ページがサポートされます。

Linux用の大規模ページ・サポート

Linuxでは、バージョン2.6以降の大きなページがサポートされています。 環境が大きなページをサポートしているかどうかを確認するには、次を試します: 

# cat /proc/meminfo | grep Huge
HugePages_Total: 0
HugePages_Free: 0
...
Hugepagesize: 2048 kB

出力に"Huge"というプレフィクスが付いたアイテムが含まれている場合、システムは大きなページをサポートしています。 値は環境によって異なります。 Hugepagesizeフィールドには環境内のデフォルトの大きなページ・サイズが表示され、他のフィールドにはこのサイズの大きいページの詳細が表示されます。 より新しいカーネルは、複数の大きなページ・サイズをサポートしています。 サポートされているページ・サイズをリストするには、次を実行します: 

# ls /sys/kernel/mm/hugepages/
hugepages-1048576kB  hugepages-2048kB

前述の環境は2 MBおよび1 GBの大きいページをサポートしていますが、JVMで使用できるように構成する必要があります。 ラージ・ページを使用し、透過的ヒュージ・ページ(オプション-XX:+UseTransparentHugePages)を有効にしない場合、ラージ・ページ数は事前に割り当てる必要があります。 たとえば、8 GBのメモリーを2 MBの大きいページでバックアップできるようにするには、rootとしてログインし、次を実行します:

# echo 4096 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

リクエスト後に、カーネルが要求した数の大きいページを割り当てることができることを確認するために、常にnr_hugepagesの値を確認することをお薦めします。

ノート: システムの再起動後に/procおよび/sysに含まれる値がリセットされるため、初期化スクリプト(たとえば、rc.localやsysctl.confなどです。)で設定できます。

大規模なページを使用できるようにOSカーネル・パラメータを構成する場合、Javaプロセスでは、次のようなJavaヒープおよびその他の内部領域に対して大きなページが割り当てられます:

そのため、nr_hugepagesパラメータをJavaヒープのサイズに構成しても、コード・キャッシュなどの他の領域ですでに構成済のラージ・ページがすでに使用されているため、JVMはラージ・ページを使用してヒープの割当てに失敗する可能性があります。

Windowsのラージ・ページのサポート

Windowsで大規模ページのサポートを使用するには、管理者はまず、アプリケーションを実行しているユーザーに追加の権限を割り当てる必要があります:

  1. 「コントロール・パネル」、「管理ツール」、「ローカル・セキュリティ・ポリシー」の順に選択します。
  2. 「ローカル・ポリシー」、「ユーザー権利の割り当て」の順に選択します。
  3. 「メモリー内のページをロック」をダブルクリックし、ユーザーまたはグループ(あるいはその両方)を追加します。
  4. システムを再起動します。

デフォルトでは、管理者はメモリー内のページをロックする権限がないため、アプリケーションを実行する管理者でもこれらのステップが必要であることに注意してください。

アプリケーション・クラス・データ共有

アプリケーション・クラス・データ共有(AppCDS)は、アプリケーションによって使用されるクラスをアーカイブ・ファイルに格納します。 これらのクラスは(JARファイルに格納されたクラスと比較)を簡単にロードできる形式で格納されるため、AppCDSはアプリケーションの起動時間を短縮できます。 また、AppCDSは、これらのクラスの一部を複数のプロセス間で共有することで、ランタイム・メモリー・フットプリントを削減できます。

CDSアーカイブ内のクラスは、JARファイルまたはJDKランタイム・イメージに格納されているクラスより約2から5倍大きい最適化された形式で格納されます。 したがって、アプリケーションによって実際に使用されるクラスのみをアーカイブすることをお薦めします。 これらは通常、使用可能なすべてのクラスの一部にすぎません。 たとえば、アプリケーションでは、大規模なライブラリによって提供される少数のAPIのみを使用できます。

CDSアーカイブの使用

デフォルトでは、ほとんどのJDKディストリビューションで、-Xshare:offが指定されていないかぎり、JVMはデフォルトのCDSアーカイブから開始されます。これは通常、JAVA_HOME/lib/server/classes.jsa (またはWindows上のJAVA_HOME\bin\server\classes.jsa)にあります。 このアーカイブには、ほとんどのアプリケーションで使用される約1300のコア・ライブラリ・クラスが含まれています。

アプリケーションで使用されるクラスの正確なセットに対してCDSを使用するには、一般的な形式の-XX:SharedArchiveFileオプションを使用できます:

-XX:SharedArchiveFile=<static_archive>:<dynamic_archive>

("static"および"動的"の名前は、履歴上の理由で使用されます。 唯一の意味は、"static"アーカイブが最初にロードされ、"動的"アーカイブが2番目にロードされることです。

JVMでは最大2つのアーカイブを使用できます。 単一の<static_archive>のみを使用するには、<dynamic_archive>部分を省略できます:

-XX:SharedArchiveFile=<static_archive>

便宜上、<dynamic_archive>は<static_archive>のロケーションを記録します。 したがって、<static_archive>を省略できるのは次の場合のみです:

-XX:SharedArchiveFile=<dynamic_archive>

CDSアーカイブの手動作成

CDSアーカイブは、いくつかのメソッドを使用して手動で作成できます:

これらのメソッドすべてに共通する操作の1つに"試行"があり、この操作ではアプリケーションを1回実行して、アーカイブに格納されるクラスを決定します。

-Xshare:dumpを使用した静的CDSアーカイブ・ファイルの作成

次のステップでは、test.Helloアプリケーションで使用されるすべてのクラスを含む静的CDSアーカイブ・ファイルを作成します。

  1. test.Helloアプリケーションで使用されるすべてのクラスのリストを作成します。 次のコマンドは、このアプリケーションで使用されるすべてのクラスのリストを含むhello.classlistという名前のファイルを作成します:

    java -Xshare:off -XX:DumpLoadedClassList=hello.classlist -cp hello.jar test.Hello

    -cpパラメータで指定されたクラスパスには、JARファイルのみを含める必要があります。

  2. hello.classlist内のすべてのクラスを含む、hello.jsaという名前の静的アーカイブを作成します:

    java -Xshare:dump -XX:SharedArchiveFile=hello.jsa -XX:SharedClassListFile=hello.classlist -cp hello.jar

  3. アーカイブhello.jsaを指定してアプリケーションtest.Helloを実行します:

    java -XX:SharedArchiveFile=hello.jsa -cp hello.jar test.Hello

  4. 「オプション」 test.Helloアプリケーションがhello.jsa共有アーカイブに含まれるクラスを使用していることを確認します:

    java -XX:SharedArchiveFile=hello.jsa -cp hello.jar -Xlog:class+load test.Hello

    このコマンドの出力は、次のテキストを含んでいる必要があります。

    [info][class,load] test.Hello source: shared objects file

デフォルトでは、-Xshare:dumpオプションを使用すると、JVMはインタプリタ専用モード(-Xintオプションが指定されているかのように)で実行されます。 これは、共有アーカイブ・ファイルで確定的出力を生成するために必要です。 つまり、ダンプするたびに、まったく同じアーカイブがビットごとに生成されます。 ただし、決定的な出力が不要で、クラス・リストが大きい場合は、コマンドラインに-Xmixedを明示的に追加して、JITコンパイラを有効にできます。 これにより、アーカイブの作成が高速化されます。

-XX:ArchiveClassesAtExitを使用した動的CDSアーカイブ・ファイルの作成

動的CDSアーカイブの利点は次のとおりです:

次のステップでは、test.Helloアプリケーションで使用されているクラスを含む動的CDSアーカイブ・ファイルを作成します。ただし、デフォルトのCDSアーカイブにすでに存在するものは除きます。

  1. アプリケーションtest.Helloによってロードされるhello.jar内のすべてのクラスを含むhello.jsaという名前の動的CDSアーカイブを作成します:

    java -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello

  2. 共有アーカイブhello.jsaを使用してアプリケーションtest.Helloを実行します:

    java -XX:SharedArchiveFile=hello.jsa -cp hello.jar test.Hello

  3. Optionalで前の項のステップ4を繰り返して、test.Helloアプリケーションがhello.jsa共有アーカイブに含まれるクラスを使用していることを確認します。

デフォルト以外の静的CDSアーカイブを使用して動的CDSアーカイブを作成することもできます。 次に例を示します。

java -XX:SharedArchiveFile=base.jsa -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello

この動的CDSアーカイブを使用してアプリケーションを実行するには、次の手順に従います:

java -XX:SharedArchiveFile=base.jsa:hello.jsa -cp hello.jar Hello

(Windowsでは、前述のパス・デリミタ:を;に置き換える必要があります)

前述のように、静的アーカイブの名前はスキップできます:

java -XX:SharedArchiveFile=hello.jsa -cp hello.jar Hello

jcmdを使用したCDSアーカイブ・ファイルの作成

前の2つのセクションでは、CDSアーカイブを作成するためにアプリケーションの起動スクリプトを変更する必要があります。 たとえば、複雑なルーチンによってアプリケーション・クラス・パスが設定されている場合など、このようなことが困難な場合があります。

jcmd VM.cdsコマンドは、実行中のJVMプロセスに接続することで、CDSアーカイブを作成するためのより侵入的な方法を提供します。 静的を作成できます:

jcmd <pid> VM.cds static_dump my_static_archive.jsa

または動的アーカイブ:

jcmd <pid> VM.cds dynamic_dump my_dynamic_archive.jsa

アプリケーションの起動スクリプトを変更せずに、アプリケーションの後続の実行で結果のアーカイブ・ファイルを使用するには、次の方法を使用できます:

env JAVA_TOOL_OPTIONS=-XX:SharedArchiveFile=my_static_archive.jsa bash app_start.sh

ノート : jcmd <pid> VM.cds dynamic_dumpを使用するには、<pid>で識別されるJVMプロセスを-XX:+RecordDynamicDumpInfoで起動する必要があります。これは、同じ方法でアプリケーション起動スクリプトに渡すこともできます:

env JAVA_TOOL_OPTIONS=-XX:+RecordDynamicDumpInfo bash app_start.sh

-XX:+AutoCreateSharedArchiveを使用した動的CDSアーカイブ・ファイルの作成

-XX:+AutoCreateSharedArchiveは、CDSアーカイブを作成/使用するためのより便利な方法です。 前のセクションで説明したCDSアーカイブを手動で作成するメソッド(-XX:+AutoCreateSharedArchiveを使用)とは異なり、別の試行を実行する必要はありません。 代わりに、常に同じコマンド行でアプリケーションを実行し、CDSの利点を自動的に享受できます。

java -XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=hello.jsa -cp hello.jar Hello

指定されたアーカイブ・ファイルが存在し、同じバージョンのJDKによって作成された場合、動的アーカイブとしてロードされます。それ以外の場合は、VMの起動時に無視されます。

VMの終了時に、指定されたアーカイブ・ファイルが存在しない場合は作成されます。 存在するが、別の(JDK 19以降)バージョンのJDKで作成された場合は、置き換えられます。 どちらの場合も、JVMが同じコマンドラインで次回起動されたときにアーカイブをロードする準備が整います。

指定したアーカイブ・ファイルは存在するが、JDK 19より前のJDKバージョンで作成された場合、そのファイルは無視されます: 起動時にロードされることも、終了時に置換されることもありません。

開発者は、CDSアーカイブ・ファイルの内容がJDKの各ビルドに固有であることに留意してください。 したがって、別のJDKビルドに切り替えると、-XX:+AutoCreateSharedArchiveはJDKと一致するようにアーカイブを自動的に再作成します。 既存のアーカイブでこの機能を使用する場合は、少なくともバージョン19のJDKでアーカイブが作成されていることを確認する必要があります。

クラスパスとモジュール・パスの制限

CDSでは、次のモジュール関連オプションがサポートされています: --module-path, --module, --add-modulesおよび--enable-native-access。

これらのオプション (指定されている場合)の値は、CDSアーカイブを作成および使用するときに同一である必要があります。 それ以外の場合、これらのオプションのいずれかに不一致があると、CDSアーカイブが一部または完全に無効になる可能性があり、パフォーマンスが低下します。

前述のオプションの問題を診断するために、-Xlog:cdsをアプリケーションのVM引数に追加できます。 たとえば、アーカイブの作成時に--add-modules jdk.jconcoleが指定され、実行時に--add-modules jdk.incubator.vectorが指定されている場合、次のメッセージが記録されます:

Mismatched values for property jdk.module.addmods

runtime jdk.incubator.vector dump time jdk.jconsole

subgraph jdk.internal.module.ArchivedBootLayer cannot be used because full module graph is disabled

VMオプション--upgrade-module-path、--patch-module、または--limit-modulesが指定されている場合、CDSは無効になります。 つまり、JVMはCDSアーカイブをロードせずに実行されます。 また、これらの3つのオプションのいずれかを指定してCDSアーカイブを作成しようとすると、JVMによってエラーがレポートされます。

事前キャッシュ

JDKでは、アプリケーションの実行前に実行できる(AOT)の事前最適化がサポートされています。 1つの例は、前述のようにクラス・データ共有(CDS)で、事前にクラスを解析します。 AOTの最適化により、Javaアプリケーションの起動およびウォーム・アップのパフォーマンスが向上します。

Ahead-of-Time Cache (AOTキャッシュ)は、AOT最適化によって生成されたアーティファクトを格納するためにJDK 24で導入されたコンテナです。 AOTキャッシュには現在、Javaクラスおよびヒープ・オブジェクトが含まれています。 今後のJDKリリースでは、AOTキャッシュには、実行プロファイルやコンパイル済メソッドなどの追加のアーティファクトが含まれる場合があります。

AOTキャッシュは、次の組合せに固有です:

前述のいずれかが変更された場合は、AOTキャッシュを再作成する必要があります。

AOTキャッシュのデプロイメントは、次の3つのフェーズに分かれています:

AOTキャッシュは、次のコマンドライン・オプションで使用できます:

-XX:AOTCache:= 「キャッシュ」
AOTキャッシュのロケーションを指定します。 「キャッシュ」の標準拡張は.aotです。 -XX:AOTCacheが指定されているが、-XX:AOTModeが指定されていない場合、AOTModeにはautoの値が指定されます。
-XX:AOTConfiguration:= 「構成ファイル」
JVMの書込み先または読取り元のAOT構成ファイルを指定します。 このオプションは、-XX:AOTMode=recordおよび-XX:AOTMode=createでのみ使用できます。 「構成ファイル」の標準拡張は.aotconfigです。
-XX:+AOTMode:=mode
modeは次のいずれかである必要があります: off, record, create, autoまたはon。
-XX:+AOTClassLinking

このオプションが有効な場合、JVMはAOTキャッシュの作成時に、より高度な最適化(起動型命令の事前の解決など)を実行します。 その結果、起動およびウォーム・アップのパフォーマンスがさらに向上します。 ただし、このオプションで作成されたAOTキャッシュは、本番フェーズで特定のコマンドライン・パラメータが指定されている場合には使用できません。 -XX:+AOTClassLinkingとその制限の詳細は、JEP 483を参照してください。

コマンドラインで-XX:AOTMode 「使用」を指定すると、AOTClassLinkingが自動的に有効になります。 これを無効にするには、-XX:-AOTClassLinkingオプションを明示的に渡す必要があります。

コマンド行で-XX:AOTMode 「使用されていません」を指定すると、AOTClassLinkingはデフォルトで無効になっており、`-Xshare:dump'などの従来のCDSオプションとの完全な互換性を提供します。

パフォーマンス・チューニングの例

Javaアドバンスト・ランタイム・オプションを使用して、アプリケーションのパフォーマンスを最適化することができます。

スループットを向上するためのチューニング

アプリケーションのスループット・パフォーマンスを向上させるには、次のコマンドおよび詳細オプションを使用します:

java -server -XX:+UseParallelGC -XX:+UseLargePages -Xmn10g -Xms26g -Xmx26g

レスポンス時間を速くするためのチューニング

次のコマンドおよび詳細オプションを使用して、アプリケーションのレスポンス時間を短くします:

java -XX:+UseG1GC -XX:MaxGCPauseMillis=100

Javaヒープを小さく保ち、組み込みアプリケーションの動的フットプリントを削減

Javaヒープを小さく保ち、組み込みアプリケーションの動的フットプリントを削減するには、次の高度な実行時オプションを使用します:

-XX:MaxHeapFreeRatio=10 -XX:MinHeapFreeRatio=5

ノート: これら2つのオプションのデフォルトはそれぞれ70%と40%です。 これらの小さな設定を使用するとパフォーマンスが低下する可能性があるため、許容範囲外のパフォーマンス低下を招くことなく、これらの設定を可能な限り減らして、フットプリントを小さくするよう最適化する必要があります。

終了ステータス

一般にランチャから次の終了値が返されるのは、通常、ランチャが不正な引数、深刻なエラー、またはJVMによってスローされた例外によって呼び出された場合です。 ただし、JavaアプリケーションはAPI呼出しSystem.exit(exitValue)を使用して任意の値を返すことができます。 値は次のとおりです。