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の後のコマンド行エントリは、メイン・メソッド用の引数です。

-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 ...

Optional: さらに、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コマンドは、javawにコンソール・ウィンドウが関連付けられていないこと以外は、javaコマンドと同じです。 javawは、コマンド・プロンプト・ウィンドウを表示する必要がないときに使用します。 ただし、javawランチャは、起動に失敗すると、エラー情報を示すダイアログ・ボックスを表示します。

ソース・ファイル・モードで単一ファイルのソース・コードのプログラムを起動する方法

ソース・ファイル内に宣言されているクラスを起動するには、ソース・ファイル・モードでjavaランチャを実行します。 ソース・ファイル・モードの開始は、javaコマンド行の2つの項目によって判断されます。

• コマンド行の最初の項目(オプションやオプションの構成要素以外)。 つまり、メイン・クラス名になりうるコマンド行の項目です。

• --source versionオプション(存在する場合)。

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

ノート: リリースごとにNの有効な値が変更され、新しい値が追加され、古い値が削除されます。 サポートされなくなったN値を使用すると、エラー・メッセージが表示されます。 このリリースでサポートされているNの値は、7、8、9、10、11、12、および13です。

ファイルに.java拡張子が付いていない場合は、--sourceオプションを使用して、ソース・ファイル・モードを使用するようにjavaコマンドに指示する必要があります。 --sourceオプションは、ソース・ファイルが実行対象の「スクリプト」であり、ソース・ファイル名がJavaソース・ファイルの通常の命名規則に準拠していない場合に使用します。

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

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

java HelloWorld.java

この例は、クラスは名前付きパッケージに配置でき、名前のないパッケージに配置する必要がないことを示しています。 このようなソース・ファイル・モードの使用は、次の2つのコマンドを使用する方法と非公式には同じです(ここでは、hello.Worldがパッケージ内のクラスの名前です)。

javac -d <memory> HelloWorld.java
java -cp <memory> hello.World

ソース・ファイル・モードでの、その他のコマンド行オプションの処理手順:

• ランチャがソース・ファイルの前に指定されているオプションをスキャンして、ソース・ファイルをコンパイルするための関連オプションを探します。

  対象: --class-path、--module-path、--add-exports、--add-modules、--limit-modules、--patch-module、--upgrade-module-path、およびこれらのオプションの様々な形式。 これには、新しい--enable-previewオプションも含まれます(JEP 12を参照)。

• 追加オプション(-processorや-Werrorなど)をコンパイラに渡すためのプロビジョニングは行われません。

• コマンド行引数ファイル(@-files)は標準的な方法で使用できます。 ファイル名の先頭に@文字を付けると、コマンド行で指定されたファイルに、呼び出されるVMまたはプログラムに対する引数の長いリストを配置することができます。

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

• コンパイル環境に関連するすべてのコマンド行オプションが考慮されます。

• 他のソース・ファイルは、ソース・パスが空の値に設定された場合と同様に、検出もコンパイルもされません。

• -proc:noneが有効な場合と同様に、注釈処理は無効化されます。

• --sourceオプションでバージョンが指定されている場合、その値は暗黙的な--releaseオプションの引数としてコンパイルで使用されます。 これにより、コンパイラによって受け入れられるソース・バージョンと、ソース・ファイル内のコードで使用されるシステムAPIの両方が設定されます。

• ソース・ファイルは、名前のないモジュールのコンテキストでコンパイルされます。

• ソース・ファイルには最上位クラスが1つ以上含まれている必要があり、そのうちの最初のクラスが実行対象として扱われます。

• コンパイラは、名前付きパッケージに含まれる型がタイプ名から構成され、.java拡張子が付いたファイルに存在する必要がある、JLS 7.6の最後に定義されたオプションの制限を強制しません。

• ソース・ファイルにエラーがあると、適切なエラー・メッセージが標準エラー・ストリームに書き出された後、ランチャは非ゼロの終了コードで終了します。

ソース・ファイル・モードでの実行の手順:

• 実行されるクラスは、ソース・ファイル内で最初に検出された最上位クラスです。 それには、標準のpublic static void main(String[])メソッドの宣言が含まれている必要があります。

• コンパイル済クラスはカスタム・クラス・ローダーでロードされ、アプリケーション・クラス・ローダーに委譲します。 これは、アプリケーション・クラス・パスに表示されているクラスはソース・ファイルに宣言されているどのクラスも参照できないことを意味します。

• コンパイル済クラスは、--add-modules=ALL-DEFAULTが有効な場合と同様に、名前のないモジュールのコンテキストで実行されます。 これは、コマンド行で指定されていた他の--add-moduleオプションに追加されるものです。

• コマンド行でファイル名の後に引数が指定されている場合、それらの引数は標準のmainメソッドに明示的に渡されます。

• 実行されるクラスと同じ名前のクラスがアプリケーション・クラス・パスにある場合はエラーになります。

詳細は、『JEP 330: Launch Single-File Source-Code Programs』を参照してください。

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

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

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

例:

$ 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の標準オプション: Java仮想マシン(JVM)のすべての実装でサポートされることが保証されているオプション。 これらは、JREのバージョンの確認、クラス・パスの設定、詳細出力の有効化などの一般的なアクションに使用します。

• javaの追加オプション: Java HotSpot仮想マシンに固有の汎用オプション。 これらは、すべてのJVM実装でサポートされている保証はなく、変更されることがあります。 これらのオプションは-Xから始まります。

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

• javaの拡張ランタイム・オプション: Java HotSpot VMのランタイム動作を制御します。

• Java用の高度なJITコンパイラ・オプション: Java HotSpot VMによって実行される動的ジャスト・イン・タイムの(JIT)コンパイルを制御します。

• javaの拡張保守性オプション: システム情報の収集および詳細デバッグの実行を有効にします。

• javaの拡張ガベージ・コレクション・オプション: Java HotSpotによってガベージ・コレクション(GC)がどのように実行されるかを制御します

ブール・オプションは、デフォルトで無効にされている機能を有効にするか、デフォルトで有効にされている機能を無効にするために使用します。 このようなオプションはパラメータを必要としません。 ブール-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オプション: 承認および操作 ---警告が使用されると、警告が発行されます。

• 廃止Javaオプション: 承認されたが無視された --- 使用すると、警告が発行されます。

• 削除されたJavaオプション: 削除済 --- 使用するとエラーになります。

javaの標準オプション

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

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

-agentlib:libname[=options]

指定したネイティブ・エージェント・ライブラリをロードします。 ライブラリ名の後に、ライブラリに固有のオプションのカンマ区切りのリストを使用できます。

• Oracle Solaris、LinuxおよびmacOS: オプション-agentlib:fooが指定された場合、JVMはlibfoo.soという名前のライブラリを、LD_LIBRARY_PATHシステム変数(macOSではこの変数はDYLD_LIBRARY_PATH)で指定された場所にロードしようとします。

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

  次の例では、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アーカイブのセミコロン(;)で区切られたリスト。

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

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

--disable-@files

引数ファイル内を含めコマンド行の任意の場所で使用して、@filenameがそれ以上展開されないようにすることができます。 このオプションでは、オプションのあとで@-argfilesの展開を停止します。

--enable-preview

クラスがリリースの「プレビュー機能」に依存できるようにします。

--module-path modulepath... or -p modulepath

各ディレクトリがモジュールのディレクトリである、セミコロン(;)で区切られたディレクトリのリスト。

--upgrade-module-path modulepath...

セミコロン(;)で区切られたディレクトリのリスト。各ディレクトリは、ランタイム・イメージ内のアップグレード可能なモジュールを交換するモジュールのディレクトリです。

--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アーカイブのリストを指定します。

Oracle Solaris、LinuxおよびmacOS: コロン(:)でこのリストのエントリを区切ります。

Windows: セミコロン(:)でこのリストのエントリを区切ります。

-Xcheck:jni

Java Native Interface (JNI)機能に対して追加チェックを行います。 具体的には、それはJNI要求を処理する前に、JNI関数に渡されるパラメータと、実行時環境データを検証します。 また、JNI呼び出し間の保留中の例外もチェックします。 無効なデータが見つかった場合は、ネイティブ・コードに問題があることを示しており、その場合JVMでは回復不能なエラーが発生して終了します。 このオプションを使用すると、パフォーマンス低下が予想されます。

-Xcomp

最初の呼出しで、メソッドのコンパイルを強制的に実行します。 デフォルトで、クライアントVM (-client)は1,000回の解析対象メソッドの呼出しを実行し、サーバーVM (-server)は10,000回の解析対象メソッドの呼出しを実行して、効率的なコンパイルのための情報を収集します。 -Xcompオプションを指定すると、解析対象メソッドの呼出しを無効にするため、効率性と引き換えにコンパイルのパフォーマンスが向上します。 -XX:CompileThresholdオプションを使用して、コンパイル前の解析対象メソッドの呼出し数を変更することもできます。

-Xdebug

何も行いません。 下位互換性を維持するために提供されています。

-Xdiag

追加の診断メッセージを表示します。

-Xint

インタプリタ専用モードでアプリケーションを実行します。 ネイティブ・コードへのコンパイルは無効になり、すべてのバイト・コードがインタプリタによって実行されます。 Just-In-Time (JIT)コンパイラが提供するパフォーマンス上の利点は、このモードでは実現されません。

-Xinternalversion

-versionオプションよりも詳しいJVMバージョン情報を表示して、終了します。

-Xlog:option

Java仮想マシン(JVM)統合ロギング・フレームワークを使用したロギングを構成または有効にします。 「JVM統合ログ・フレームワークでのログを有効にします」を参照してください。

-Xmixed

ネイティブ・コードにコンパイルされるホット・メソッドを除くすべてのバイトコードをインタプリタによって実行します。

-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の倍数で1MBより大きくなければなりません。 キロバイトを指定するには文字kまたはK、メガバイトを指定するには文字mまたはM、ギガバイトを指定するには文字gまたはGを付けます。 次の例では、様々な単位を使用して、割り当てられたメモリーのサイズを6Mバイトに設定する方法を示します。

-Xms6291456
-Xms6144k
-Xms6m

ヒープの最小サイズおよび初期サイズを設定するための-Xmsオプションのかわりに、-XX:MinHeapSizeを使用して最小サイズを設定し、-XX:InitialHeapSizeを使用して初期サイズを設定できます。

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

-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アプリケーションの正常なシャットダウンができるようになりました。

• Oracle Solaris、LinuxおよびmacOS:

  • 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サーバー用のサーブレット・エンジンなど)として実行されている場合、CTRL_LOGOFF_EVENTを受け取ることはできますが、オペレーティング・システムが実際にはプロセスを終了しないため、シャットダウンを開始しないでください。 このような干渉の可能性を避けるため、-Xrsオプションを使用できます。 -Xrsオプションを使用すると、JVMは、コンソール制御ハンドラをインストールしないため、CTRL_C_EVENT、CTRL_CLOSE_EVENT、CTRL_LOGOFF_EVENTまたはCTRL_SHUTDOWN_EVENTの監視や処理を行わないことを意味します。

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

• Oracle Solaris、LinuxおよびmacOS: SIGQUITによるスレッド・ダンプは使用できません。

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

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

-Xshare:mode

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

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

auto

可能な場合は共有クラス・データを使用します(デフォルト)

on

共有クラス・データの使用が必須で、使用しないと失敗します。

ノート: -Xshare:onオプションはテストの目的でのみ使用され、操作システムによるアドレス領域レイアウトのランダム化によって断続的な障害が発生することがあります。 このオプションは、本番環境では使用しないでください。

off

共有クラス・データを使用しないようにします。

-XshowSettings

すべての設定を表示してから、続行します。

-XshowSettings:category

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

all

設定のすべてのカテゴリを表示します。 これはデフォルト値です。

locale

ロケールに関連する設定を表示します。

properties

システム・プロパティに関連する設定を表示します。

vm

JVMの設定を表示します。

system

Linux: ホスト・システムまたはコンテナ構成を表示して続行します。

-Xss size

スレッド・スタック・サイズ(バイト単位)を設定します。 KBを指定するには文字kまたはK、MBを指定するには文字mまたはM、GBを指定するには文字gまたはGを付けます。 デフォルト値はプラットフォームによって異なります。

• Linux/x64 (64ビット): 1024KB

• macOS (64ビット): 1024KB

• Oracle Solaris (64-bit): 1024 KB

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

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

-Xss1m
-Xss1024k
-Xss1048576

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

--add-reads module=target-module(,target-module)*

moduleを更新して、モジュール宣言に関係なくtarget-moduleを読み取ります。target-moduleは名前のないすべてのモジュールを読み取ることができます。

--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を開きます。

--illegal-access=parameter

実行時に指定する場合、--illegal-access=は操作モードを指定するキーワードparameterを取ります。

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

• permit: このモードでは、ランタイム・イメージの各モジュール内の各パッケージを、名前のないすべてのモジュールのコード(クラス・パスにあるコードなど)に対してオープンします(そのパッケージがJDK 8に入っていた場合)。 これにより、プラットフォームの各種リフレクションAPIを介して、両方の静的アクセス(たとえば、コンパイル済のバイトコードによるアクセスとディープ・リフレクション・アクセス)が使用可能になります。 このようなパッケージに対して初めてリフレクション・アクセス操作を行うと、警告が発行されます。 しかし、次の操作から警告は発行されません。 この1回の警告に、以降の警告を有効にする方法が記載されています。 このモードは、現在のJDKのデフォルトですが、将来のリリースでは変更される予定です。

• warn: このモードは、permitと同じですが、不正なリフレクション・アクセス操作ごとに警告メッセージが発行されます。

• debug: このモードは、warnと同じですが、不正なリフレクション・アクセス操作ごとに警告メッセージとスタック・トレースの両方が発行されます。

• deny: このモードは、不正アクセス操作をすべて無効にしますが、 --add-opensなどの他のコマンド行オプションによって有効にされている操作は除きます。 このモードは、将来のリリースでデフォルトとなる予定です。

デフォルト・モード--illegal-access=permitは、JDK内部APIに少なくとも1回はリフレクション・アクセスを実行するクラス・パス上のコードをユーザーに認識させることを目的としています。 このようなアクセスをすべて認識するには、warnモードまたはdebugモードを使用できます。 不正アクセスを必要とするクラス・パス上のライブラリまたはフレームワークそれぞれに対して、2つの選択肢があります。

• コンポーネントのメンテナンス管理者がJDK内部APIを使用しなくなった修正済バージョンをすでにリリースしている場合は、そのバージョンへのアップグレードを検討できます。

• 引き続きコンポーネントの修正が必要な場合は、メンテナンス管理者に連絡して、JDK内部APIの使用部分をエクスポートされた正式のAPIで置換するように依頼できます。

不正アクセスを必要とするコンポーネントを引き続き使用する必要がある場合は、1つ以上の--add-opensオプションを使用してアクセスする必要がある内部パッケージのみをオープンすることで、警告メッセージが発行されないようにできます。

アプリケーションが将来のバージョンのJDKに対応できるかどうかを確認するには、必要な--add-opensオプションとともに--illegal-access=denyを指定して実行します。 残りの不正アクセス・エラーは、コンパイル済のコードからJDK内部APIへの静的リファレンスによる可能性が最も高いです。 --jdk-internalsオプションを指定してjdepsツールを実行すると、それらを特定できます。 パフォーマンス上の理由から、現在のJDKでは、不正な静的アクセス操作に関しての警告を発行しません。

--limit-modules module[,module...]

観測可能なモジュールのユニバースの制限を指定します。

--patch-module module=file(;file)*

JARファイルまたはディレクトリ内のクラスおよびリソースでモジュールをオーバーライドまたは拡張します。

--source version

ソース・ファイル・モードのソースのバージョンを設定します。

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

• Oracle Solaris、LinuxおよびmacOS: 次の例は、エラー・ログを/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

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

• Oracle Solaris、LinuxおよびmacOS: 一時ディレクトリは/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に設定されます。

repository=path

一時ディスク・ストレージのリポジトリ(ディレクトリ)を指定します。 デフォルトでは、システムの一時ディレクトリが使用されます。

retransform={true|false}

JVMTIを使用してイベント・クラスを再変換するかどうかを指定します。 falseの場合、イベント・クラスのロード時にインストゥルメンテーションが追加されます。 デフォルトで、このパラメータは有効です。

samplethreads={true|false}

スレッド・サンプリングを有効にするかどうかを指定します。 スレッド・サンプリングは、このパラメータとともにサンプリング・イベントが有効にされている場合にのみ行われます。 デフォルトで、このパラメータは有効です。

stackdepth=depth

スタック・トレースのスタックの深さ。 デフォルトでは、この深さは64回のメソッド呼出しに設定されます。 最大数は2048です。 64よりも大きい値を指定すると、大量のオーバーヘッドが発生し、パフォーマンスが低下する可能性があります。

threadbuffersize=size

スレッドごとのローカル・バッファ・サイズ(バイト単位)を指定します。 デフォルトでは、ローカル・バッファ・サイズは8キロバイトに設定され、最小値は4キロバイトです。 このパラメータをオーバーライドするとパフォーマンスが低下する可能性があるため、お薦めしません。

複数のパラメータの値を指定するには、それらをコロンで区切ります。

-XX:LargePageSizeInBytes=size

Javaヒープに使用されるラージ・ページの最大サイズ(バイト単位)を設定します。 size引数は2の累乗(2、4、8、16...)にする必要があります。 キロバイトを指定するには文字kまたはK、メガバイトを指定するには文字mまたはM、ギガバイトを指定するには文字gまたはGを付けます。 デフォルトでサイズは0に設定され、JVMがラージ・ページのサイズを自動的に選択することを意味します。 「大きなページ」を参照してください。

次の例では、大きなページ・サイズを4メガバイトの(MB)に設定する方法を説明します:

-XX:LargePageSizeInBytes=4m

-XX:MaxDirectMemorySize=size

java.nioパッケージのダイレクトバッファ割当ての最大合計サイズ(バイト単位)を設定します。 キロバイトを指定するには文字kまたはK、メガバイトを指定するには文字mまたはM、ギガバイトを指定するには文字gまたはGを付けます。 デフォルトでサイズは0に設定され、JVMがNIOダイレクトバッファ割当てのサイズを自動的に選択することを意味します。

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

-XX:MaxDirectMemorySize=1m
-XX:MaxDirectMemorySize=1024k
-XX:MaxDirectMemorySize=1048576

-XX:-MaxFDLimit

オープン・ファイル・ディスクリプタ数のソフト制限をハード制限に設定する試みを無効にします。 デフォルトでは、このオプションはすべてのプラットフォームで有効になっていますが、Windowsでは無視されます。 Mac OSでこのオプションを無効にする必要があるのは、実際のシステムの最大値を下回る最大値10240が課せられる場合のみです。

-XX:NativeMemoryTracking=mode

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

off

JVMネイティブ・メモリーの使用状況を追跡しないように指示します。 これは-XX:NativeMemoryTrackingオプションを指定しない場合のデフォルトの動作です。

summary

Javaヒープ、クラス、コード、スレッドなどのJVMサブシステムによるメモリー使用状況のみを追跡します。

detail

JVMサブシステムによるメモリー使用状況の追跡に加えて、各CallSite、各仮想メモリー領域およびそのコミット済領域によるメモリー使用状況を追跡します。

-XX:ObjectAlignmentInBytes=alignment

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

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

4GB * ObjectAlignmentInBytes

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

-XX:OnError=string

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

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

  -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)を選択します。 フレーム・ポインタが使用可能な場合は、外部プロファイリングtools??(for example, Linux perf)によってより正確なスタック・トレースを構築できます。

-XX:+PrintNMTStatistics

メモリー追跡が有効にされている場合(-XX:NativeMemoryTrackingを参照)、JVMで収集されたネイティブ・メモリー追跡データの出力を有効にします。 デフォルトでは、このオプションは無効になっており、ネイティブ・メモリー追跡データは出力されません。

-XX:SharedArchiveFile=path

クラス・データ共有(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:+ShowMessageBoxOnError

JVMで回復不能なエラーが発生した場合に、ダイアログ・ボックスの表示を有効にします。 これにより、JVMの終了を回避し、プロセスをアクティブに維持するため、これにデバッガを接続して、エラーの原因を調査できます。 デフォルトでは、このオプションは無効になっています。

-XX:StartFlightRecording=parameter=value

JavaアプリケーションのJFR記録を開始します。 このオプションは、実行時に記録を開始するJFR.start診断コマンドと同等です。 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

name=identifier

記録の名前と識別子の両方を取ります。

maxage=time

記録用保持するディスク・データの最大保持期間を指定します。 このパラメータは、diskパラメータがtrueに設定されている場合にのみ有効です。 時間を秒で指定するためにはs、分の場合はm、時間の場合はhまたは日の場合dを追加します(たとえば、30sの指定は、30秒を意味します)。 デフォルトでは、最大期間は制限されず、このパラメータは0sに設定されます。

maxsize=size

記録用に保持するディスク・データの最大サイズ(バイト単位)を指定します。 このパラメータは、diskパラメータがtrueに設定されている場合にのみ有効です。 値は、-XX:FlightRecorderOptionsで設定したmaxchunksizeパラメータの値以上にする必要があります。 mまたはMを追加してサイズをMB単位で指定するか、gまたはGを追加してサイズをGB単位で指定します。 デフォルトでは、ディスク・データの最大サイズは制限されず、このパラメータは0に設定されます。

path-to-gc-roots={true|false}

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

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

settings=path

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

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

複数のパラメータの値を指定するには、それらをコロンで区切ります。

-XX:ThreadStackSize=size

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

• Linux/x64 (64ビット): 1024KB

• macOS (64ビット): 1024KB

• Oracle Solaris (64-bit): 1024 KB

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

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

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

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

-XX:-UseBiasedLocking

バイアス・ロックの使用を無効にします。 大量の非競合同期を行うアプリケーションでは、このフラグを有効にすることで大幅な高速化が実現されることがありますが、特定のパターンのロックを行うアプリケーションでは速度が低下することがあります。

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

-XX:-UseCompressedOops

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

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

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

-XX:-UseContainerSupport

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

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

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

-XX:+UseHugeTLBFS

Linuxのみ: このオプションは、-XX:+UseLargePagesを指定するのと同じです。 このオプションはデフォルトでは無効です。 このオプションは、メモリーの予約時にすべてのラージ・ページを事前に割り当てます。そのため、JVMはラージ・ページ・メモリー領域を動的に拡張または縮小できません。この動作を行う場合は、-XX:UseTransparentHugePagesを参照してください。

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

-XX:+UseLargePages

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

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

-XX:+UseTransparentHugePages

Linuxのみ: 動的に拡張または縮小できるラージ・ページの使用を有効にします。 このオプションはデフォルトでは無効です。 OSが他のページを移動してヒュージ・ページを作成するため、透過的ヒュージ・ページでパフォーマンスの問題が検出される場合があります。このオプションは試験的に使用できます。

-XX:+AllowUserSignalHandlers

アプリケーションがシグナル・ハンドラをインストールできるようにします。 デフォルトでは、このオプションは無効になっており、アプリケーションはシグナル・ハンドラをインストールできません。

-XX:VMOptionsFile=filename

ユーザーがVMオプションをファイルに指定できるようにします。例: java -XX:VMOptionsFile=/var/my_vm_options HelloWorld。

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

これらのjavaオプションはJava HotSpot VMによって実行されるJust-in-Time (JIT)動的コンパイルを制御します。

-XX:AllocateInstancePrefetchLines=lines

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

-XX:AllocateInstancePrefetchLines=1

Java HotSpot Server VMのみが、このオプションをサポートしています。

-XX:AllocatePrefetchDistance=size

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

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

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

-XX:AllocatePrefetchDistance=1024

Java HotSpot Server VMのみが、このオプションをサポートしています。

-XX:AllocatePrefetchInstr=instruction

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

-XX:AllocatePrefetchInstr=0

Java HotSpot Server VMのみが、このオプションをサポートしています。

-XX:AllocatePrefetchLines=lines

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

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

-XX:AllocatePrefetchLines=5

Java HotSpot Server VMのみが、このオプションをサポートしています。

-XX:AllocatePrefetchStepSize=size

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

-XX:AllocatePrefetchStepSize=16

Java HotSpot Server VMのみが、このオプションをサポートしています。

-XX:AllocatePrefetchStyle=style

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

0

プリフェッチ命令を生成しません。

1

各割当て後にプリフェッチ命令を実行します。 これはデフォルトのパラメータです。

2

スレッドローカル割当てブロック(TLAB)ウォーターマーク・ポインタを使用して、プリフェッチ命令を実行するタイミングを決定します。

3

SPARCで割当てプリフェッチにはBIS命令を使用します。

Java HotSpot Server VMのみが、このオプションをサポートしています。

-XX:+BackgroundCompilation

バックグラウンド・コンパイルを有効にします。 このオプションはデフォルトで有効化されています。 バックグラウンド・コンパイルを無効にするには、-XX:-BackgroundCompilationを指定します(これは-Xbatchを指定するのと同等です)。

-XX:CICompilerCount=threads

コンパイルに使用するコンパイラ・スレッド数を設定します。 デフォルトで、スレッド数はサーバーJVMの場合に2に設定され、クライアントJVMの場合に1に設定され、階層型コンパイルが使用される場合はコア数まで拡大されます。 次の例は、スレッド数を2に設定する方法を示しています。

-XX:CICompilerCount=2

-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

コンパイルを制限すべきメソッドのリスト(カンマ区切り)を設定します。 指定されたメソッドのみをコンパイルします。 パッケージとサブパッケージを含む完全クラス名で各メソッドを指定します。 たとえば、Stringクラスのlength()メソッドとListクラスのsize()メソッドのみをコンパイルするには、次を使用します。

-XX:CompileOnly=java/lang/String.length,java/util/List.size

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

-XX:CompileOnly=java.lang.String::length,java.util.List::size

ワイルドカードはサポートされていませんが、クラスまたはパッケージ名のみを指定して、そのクラスまたはパッケージ内のすべてのメソッドをコンパイルすることも、メソッドのみを指定していずれかのクラス内のこの名前を持つメソッドをコンパイルすることもできます。

-XX:CompileOnly=java/lang/String
-XX:CompileOnly=java/lang
-XX:CompileOnly=.length

-XX:CompileThreshold=invocations

コンパイル前に解析対象メソッドの呼出しの数を設定します。 デフォルトで、サーバーJVMでは、JITコンパイラは10,000回の解析対象メソッドの呼出しを実行して、効率的なコンパイルのための情報を収集します。 クライアントJVMの場合、デフォルトの設定は1,500回の呼出しです。 層コンパイルが有効な場合、このオプションは無視されます。オプション-XX:-TieredCompilationを参照してください。 次の例は、解析対象メソッドの呼出し数を5,000に設定する方法を示しています。

-XX:CompileThreshold=5000

-Xcompオプションを指定して、コンパイル前にJavaメソッドの解析を完全に無効にできます。

-XX:CompileThresholdScaling=scale

最初のコンパイルの統一された制御を提供します。 このオプションは、操作の層モードと無層モードの両方のためにメソッドを初めてコンパイルする時期を制御します。 CompileThresholdScalingオプションは0から正の無限大までの整数値を指定し、操作の現行モード(層および無層)に応じてしきい値のスケールを変更します。 CompileThresholdScalingを1.0より小さい値に設定するとコンパイルが早まるのに対し、1.0より大きい値はコンパイルを遅らせます。 CompileThresholdScalingを0に設定することは、コンパイルを無効にすることと同等です。

-XX:+DoEscapeAnalysis

エスケープ解析の使用を有効にします。 このオプションはデフォルトで有効化されています。 エスケープ解析の使用を無効にするには-XX:-DoEscapeAnalysisを指定します。 Java HotSpot Server VMのみが、このオプションをサポートしています。

-XX:InitialCodeCacheSize=size

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

-XX:InitialCodeCacheSize=32k

-XX:+Inline

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

-XX:InlineSmallCode=size

インライン化すべきコンパイル済メソッドの最大コード・サイズ(バイト単位)を設定します。 キロバイトを指定するには文字kまたはK、メガバイトを指定するには文字mまたはM、ギガバイトを指定するには文字gまたはGを付けます。 指定されたサイズより小さいサイズのコンパイル済メソッドのみがインライン化されます。 デフォルトでは、最大コード・サイズは1000バイトに設定されます。

-XX:InlineSmallCode=1000

-XX:+LogCompilation

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

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

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

-XX:MaxInlineSize=size

インラインするメソッドの最大バイトコード・サイズ(バイト単位)を設定します。 キロバイトを指定するには文字kまたはK、メガバイトを指定するには文字mまたはM、ギガバイトを指定するには文字gまたはGを付けます。 デフォルトでは、最大バイトコード・サイズは35バイトに設定されます。

-XX:MaxInlineSize=35

-XX:MaxNodeLimit=nodes

単一のメソッドのコンパイル時に使用されるノードの最大数を設定します。 デフォルトでは、ノードの最大数は65,000に設定されます。

-XX:MaxNodeLimit=65000

-XX:NonNMethodCodeHeapSize=size

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

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

-XX:NonProfiledCodeHeapSize=size

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

-XX:MaxTrivialSize=size

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

-XX:MaxTrivialSize=6

-XX:+OptimizeStringConcat

String連結操作の最適化を有効にします。 このオプションはデフォルトで有効化されています。 String連結操作の最適化を有効にするには、-XX:-OptimizeStringConcatを指定します。 Java HotSpot Server VMのみが、このオプションをサポートしています。

-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を付けます。 デフォルトの最大コード・キャッシュ・サイズは240MBです。オプション-XX:-TieredCompilationを使用して階層化コンパイルを無効にした場合、デフォルトのサイズは48MBです。 このオプションは2GBの制限があります。そうでない場合は、エラーが生成されます。 最大コード・キャッシュ・サイズを初期コード・キャッシュ・サイズより小さくしないでください。-XX:InitialCodeCacheSizeオプションを参照してください。

-XX:RTMAbortRatio=abort_ratio

RTM中止率を、すべての実行済RTMトランザクションに対するパーセンテージ(%)として指定します。 中止されたトランザクション数がこの率を超えた場合、コンパイルされたコードが非最適化されます。 この率は、-XX:+UseRTMDeoptオプションが有効な場合に使用されます。 このオプションのデフォルト値は50です。 つまり、すべてのトランザクションの50%が中止された場合、コンパイルされたコードが非最適化されます。

-XX:RTMRetryCount=number_of_retries

中止またはビジー状態の場合、通常のロック・メカニズムに戻るまでにRTMロック・コードが再試行される回数を指定します。 このオプションのデフォルト値は5です。 -XX:UseRTMLockingオプションを有効化する必要があります。

-XX:+SegmentedCodeCache

コード・キャッシュのセグメント化を有効にします。 -XX:+SegmentedCodeCacheを指定しない場合、コード・キャッシュは1つの大きなセグメントから構成されます。 -XX:+SegmentedCodeCacheでは、メソッド以外、プロファイリングされたメソッドおよび非キャッシュ・メソッドに対して別々のセグメントがあります。 これらのセグメントは、実行時にサイズ変更されません。 この機能は、層コンパイルが有効になっていて(-XX:+TieredCompilation)、-XX:ReservedCodeCacheSizeが240MB以上の場合、デフォルトでは有効になっています。 メモリー・フットプリントが制御しやすくなり、コードの断片化が減り、改善された局所性によってiTLB/iCache動作が向上するといった利点があります。iTLB/iCacheは、インストラクション・トランスレーション・ルックアサイド・バッファ(ITLB)を意味するCPU固有の用語です。 ICacheは、そのCPU内の命令キャッシュです。 コード・キャッシュの実装はファイル内にあります: /share/vm/code/codeCache.cpp。

-XX:StartAggressiveSweepingAt=percent

指定されたパーセンテージのコード・キャッシュのみが空いている場合、積極的に未使用のコードを削除するようにアクティブ・メソッドのスタック・スキャンを強制します。 デフォルト値は10%です。

-XX:-TieredCompilation

階層化コンパイルの使用を無効にします。 デフォルトでは、このオプションが有効になっています。 Java HotSpot Server VMのみが、このオプションをサポートしています。

-XX:+UseAES

Intel、AMDおよびSPARCハードウェアに対して、ハードウェアベースのAES組込みを有効化します。 Intel Westmere (2010以降)、AMD Bulldozer (2011以降)およびSPARC (T4以降)が、サポートされているハードウェアです。 -XX:+UseAESは、UseAESIntrinsicsとともに使用します。 組込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。

-XX:+UseAESIntrinsics

-XX:+UseAESおよび-XX:+UseAESIntrinsicsフラグ(Java HotSpot Server VMに対してのみサポート)をデフォルトで有効にします。 ハードウェアベースのAES組込みを無効化するには、-XX:-UseAES -XX:-UseAESIntrinsicsを指定します。 たとえば、ハードウェアAESを有効化するには、次のフラグを使用します。

-XX:+UseAES -XX:+UseAESIntrinsics

組込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptionsが必要になりました。 UseAESおよびUseAESIntrinsicsフラグをサポートするには、-serverオプションを使用してJava HotSpot Server VMを選択します。 これらのフラグは、クライアントVMではサポートされていません。

-XX:+UseCMoveUnconditionally

収益性分析に関係なく、CMove (スカラーおよびベクター)命令を生成します。

-XX:+UseCodeCacheFlushing

コンパイラのシャットダウン前に、コード・キャッシュのフラッシュを有効にします。 このオプションはデフォルトで有効化されています。 コンパイラのシャットダウン前に、コード・キャッシュのフラッシュを無効にするには、-XX:-UseCodeCacheFlushingを指定します。

-XX:+UseCondCardMark

カード表を更新する前にカードが既にマークされているかどうかをチェックすることができます。 このオプションはデフォルトでは無効です。 複数のソケットを持つマシンでのみ使用してください。これにより、同時操作に依存するJavaアプリケーションのパフォーマンスが向上します。 Java HotSpot Server VMのみが、このオプションをサポートしています。

-XX:+UseCountedLoopSafepoints

セーフ・ポイントをカウントされたループに保持します。 デフォルト値はfalseです。

-XX:+UseFMA

FMA命令が使用可能なハードウェアにハードウェア・ベースのFMA組み込み関数を有効にします。(Intel、SPARC、およびARM64などの)。 FMAの侵入者は、( a * b + c )式の値を計算するjava.lang.Math.fma( a , b , c )メソッドに生成されます。

-XX:+UseRTMDeopt

中止率に応じて、RTMロックを自動調整します。 この率は、-XX:RTMAbortRatioオプションによって指定されます。 中止されたトランザクション数が中止率を超えた場合、ロックを含むメソッドがすべてのロックで標準のロックとして非最適化および再コンパイルされます。 このオプションはデフォルトでは無効です。 -XX:+UseRTMLockingオプションを有効化する必要があります。

-XX:+UseRTMLocking

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

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

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

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

-XX:+UseSHA

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

UseSHAおよびUseSHA*Intrinsicsフラグはデフォルトで有効であり、SPARC T4以上のJava HotSpot Server VM 64ビットでのみサポートされます。

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:+UseSuperWord

スカラー操作のスーパーワード操作への変換を有効にします。 スーパー・ワードはベクトル化の最適化です。 このオプションはデフォルトで有効化されています。 スカラー操作のスーパーワード操作への変換を無効にするには、-XX:-UseSuperWordを指定します。 Java HotSpot Server VMのみが、このオプションをサポートしています。

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

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

-XX:+DisableAttachMechanism

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

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

-XX:+ExtendedDTraceProbes

Oracle Solaris、LinuxおよびmacOS: パフォーマンスに影響するdtraceツールの追加のプローブを有効にします。 デフォルトでは、このオプションは無効になっており、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

• Oracle Solaris、LinuxおよびmacOS: 次の例は、ヒープ・ダンプ・ファイルを/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という名前が付けられます。

• Oracle Solaris、LinuxおよびmacOS: 次の例は、ログ・ファイルを/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

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

• Oracle Solaris、LinuxおよびmacOS: Ctrl+Break

• Windows: [Ctrl]+[C] (SIGTERM)

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

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

-XX:+PrintConcurrentLocks

次のイベントのいずれかの後のjava.util.concurrentロックの出力を有効にします。

• Oracle Solaris、LinuxおよびmacOS: Ctrl+Break

• Windows: [Ctrl]+[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:+CMSClassUnloadingEnabled

コンカレント・マーク・スイープ(CMS)ガベージ・コレクタを使用した場合に、クラスのアンロードを有効にします。 このオプションはデフォルトで有効化されています。 CMSガベージ・コレクタのクラスのアンロードを無効にするには、-XX:-CMSClassUnloadingEnabledを指定します。

-XX:CMSExpAvgFactor=percent

並行処理コレクションの統計のための指数平均の計算時に、現在のサンプルの重み付けに使用される時間のパーセンテージ(0から100)を設定します。 デフォルトで、指数平均係数は25%に設定されます。 次の例は、係数を15%に設定する方法を示しています。

-XX:CMSExpAvgFactor=15

-XX:CMSInitiatingOccupancyFraction=percent

CMSコレクション・サイクルを開始するOld世代の占有率(0から100)を設定します。 デフォルト値は-1に設定されます。 マイナスの値(デフォルトを含む)はオプション-XX:CMSTriggerRatioを使用して、開始の占有割合の値を定義することを意味します。

次の例は、係数を20%に設定する方法を示しています。

-XX:CMSInitiatingOccupancyFraction=20

-XX:CMSIncrementalDutySafetyFactor=percent

デューティ・サイクルの計算時に、保守性を追加するために使用されるパーセンテージ(0から100)を設定します。 デフォルト値は10です。

-XX:+CMSScavengeBeforeRemark

CMS remarkステップの前に清掃の試みを有効にします。 デフォルトでは、このオプションは無効になっています。

-XX:CMSTriggerRatio=percent

CMSコレクション・サイクルの開始前に割り当てられるオプション-XX:MinHeapFreeRatioによって指定された値のパーセンテージ(0から100)を設定します。 デフォルト値は80%に設定されます。

次の例は、占有の割合を75%に設定する方法を示しています。

-XX:CMSTriggerRatio=75

-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:+UseConcMarkSweepGCオプションおよび-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オプションを使用して、設定できます。

-XX:InitialRAMPercentage=percent

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

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

-XX:InitialRAMPercentage=5

-XX:InitialSurvivorRatio=ratio

スループット・ガベージ・コレクタ(どちらが有効になるのかは、-XX:+UseParallelGCまたは-XX:+UseParallelOldGCオプション(あるいはその両方)です。)によって使用される初期生存スペースの比率を設定します。 適応型のサイズ変更は、-XX:+UseParallelGCおよび-XX:+UseParallelOldGCオプションを使用して、スループット・ガベージ・コレクタによってデフォルトで有効にされ、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%に設定されます。

Javaヒープ・サイズを最小化するには、コマンド行オプション-XX:MaxHeapFreeRatioおよび-XX:MinHeapFreeRatioを使用して、パラメータ-XX:MaxHeapFreeRatio (デフォルト値は70%)および-XX:MinHeapFreeRatio (デフォルト値は40%)の値を小さくします。 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です。 デフォルト値はパラレル(スループット)コレクタの場合15で、CMSコレクタの場合6です。

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

-XX:MaxTenuringThreshold=10

-XX:MetaspaceSize=size

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

-XX:MinHeapFreeRatio=percent

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

Javaヒープ・サイズを最小化するには、コマンド行オプション-XX:MaxHeapFreeRatioおよび-XX:MinHeapFreeRatioを使用して、パラメータ-XX:MaxHeapFreeRatio (デフォルト値は70%)および-XX:MinHeapFreeRatio (デフォルト値は40%)の値を小さくします。 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:+ScavengeBeforeFullGC

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

-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ヒープ・サイズを最小限にするには、このオプションを使用不可にします。 このオプションを無効にすると、パフォーマンスが低下する可能性があります。

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

-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:+UseCMSInitiatingOccupancyOnly

CMSコレクタの開始の唯一の基準として、占有率値の使用を有効にします。 デフォルトでは、このオプションは無効になっており、その他の基準を使用できます。

-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:+UseParallelOldGCオプションも明示的に無効にしないかぎりは自動的に有効になります。

-XX:+UseParallelOldGC

フルGCのパラレル・ガベージ・コレクタの使用を有効にします。 デフォルトでは、このオプションは無効になっています。 それを自動的に有効にすると、-XX:+UseParallelGCオプションが有効になります。

-XX:+UseSerialGC

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

-XX:+UseSHM

Linuxのみ: JVMで共有メモリーを使用してラージ・ページを設定できるようにします。

大きなページの設定については、「大きなページ」を参照してください。

-XX:+UseStringDeduplication

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

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

-XX:+UseTLAB

Young世代の領域で、スレッドローカル割当てブロック(TLAB)の使用を有効にします。 このオプションはデフォルトで有効化されています。 TLABの使用を無効にするには、オプション-XX:-UseTLABを指定します。

-XX:+UseZGC

Zガベージ・コレクタを使用できるようにします。 このガベージ・コレクタは、Javaヒープの待機時間が多少のスループット・コストで最小になるようにするのに最適です。 これは試験的ガベージ・コレクタで、コマンドラインで-XX:+UseZGCの前に-XX:+UnlockExperimentalVMOptionsを指定する必要があります。

例:

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC

非推奨のjavaオプション

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

-Xfuture

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

-Xloggc:filename

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

例:

-Xlog:gc:garbage-collection.log

-XX:+FailOverToOldVerifier

新しい型チェッカーが失敗した場合に、古いベリファイアへの自動フェールオーバーを有効にします。 デフォルトでは、このオプションは無効になっており、最近のバイトコード・バージョンを使用したクラスでは、無視されます(つまり、無効として処理されます)。 有効にできるのは、古いバージョンのバイトコードのクラスに対してのみです。

-XX:+FlightRecorder

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

-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:+TraceClassLoading

クラスがロードされたときに、それらの追跡を有効にします。 デフォルトでは、このオプションは無効になっており、クラスは追跡されません。

交換用の統合ロギング構文は、-Xlog:class+load= levelです。 「JVM統合ログ・フレームワークでのログを有効にします」を参照

通常の情報にlevel=infoを使用するか、追加の情報にlevel=debugを使用します。 統合ロギングの構文では、-verbose:classは-Xlog:class+load=info,class+unload=infoと等価です。

-XX:+TraceClassLoadingPreorder

ロードされたすべてのクラスの追跡をそれらが参照される順番で有効にします。 デフォルトでは、このオプションは無効になっており、クラスは追跡されません。

置換統合ロギングの構文は、-Xlog:class+preorder=debugです。 「JVM統合ログ・フレームワークでのログを有効にします」を参照してください。

-XX:+TraceClassResolution

定数プールの解決の追跡を有効にします。 デフォルトでは、このオプションは無効になっており、定数プールの解決は追跡されません。

置換統合ロギングの構文は、-Xlog:class+resolve=debugです。 「JVM統合ログ・フレームワークでのログを有効にします」を参照してください。

-XX:+TraceLoaderConstraints

ローダーの制約の記録の追跡を有効にします。 デフォルトでは、このオプションは無効になっており、ローダー制約の記録は追跡されません。

置換統合ロギングの構文は、-Xlog:class+loader+constraints=infoです。 「JVM統合ログ・フレームワークでのログを有効にします」を参照してください。

-XX:+UseConcMarkSweepGC

Old世代のCMSガベージ・コレクタの使用を有効にします。 CMSは、デフォルトのガーベジ・コレクタ(G1)にかわるものであり、アプリケーションの待機時間要件を満たすことに重点を置いています。 デフォルトで、このオプションは無効になっており、マシンの構成とJVMのタイプに基づいて、コレクタが自動的に選択されます。 CMSガベージ・コレクタは、非推奨になりました。

廃止されたjavaオプション

これらのjavaオプションは、引き続き使用可能ですが無視され、使用すると警告が発行されます。

-XX:+UseMembar

スレッド状態の遷移時にメンバーの発行を有効にしていました。 このオプションは、ARMサーバーを除くすべてのプラットフォーム上で、デフォルトでは無効になっていました(ARMサーバーでは有効)。

-XX:MaxPermSize=size

Permanent世代領域の最大サイズ(バイト単位)を設定します。 このオプションはJDK 8で非推奨になり、-XX:MaxMetaspaceSizeオプションによって置き換えられました。

-XX:PermSize=size

超えた場合にガベージ・コレクションがトリガーされる、Permanent世代に割り当てられる領域(バイト単位)を設定します。 このオプションはJDK 8で非推奨になり、-XX:MetaspaceSizeオプションによって置き換えられました。

削除されたjavaオプション

これらのjavaオプションはJDK 13で削除されており、使用すると次のエラーになります。

Unrecognized VM option option-name

-XX:+AggressiveOpts

積極的なパフォーマンス最適化機能の使用を有効にしていました。 デフォルトでは、このオプションは無効になっていて、試験的パフォーマンス機能は使用されていませんでした。

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

• Java Platform, Standard Editionツール・リファレンス, リリース12

• Java Platform, Standard Editionツール・リファレンス, リリース11

• Java Platform, Standard Editionツール・リファレンス, リリース10

• Java Platform, Standard Editionツール・リファレンス, リリース9

• Java Platform, Standard Editionツール・リファレンス, リリース8 for Oracle JDK on Windows

• Solaris、LinuxおよびmacOSのJava Platform, Standard Editionツール・リファレンス、Oracle JDKリリース8

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

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

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

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

次の各項目では、java引数ファイルの構文について説明します。

• 引数ファイルでは、ASCII文字またはASCIIと親和性の高いUTF-8などのシステムのデフォルト・エンコーディングの文字のみを使用する必要があります。

• 引数ファイルのサイズは、MAXINT (2, 147, 483, 647)バイトを超えてはなりません。

• ランチャは、引数ファイル内に存在するワイルドカードを展開しません。

• 空白または改行文字を使用して、ファイルに含まれる引数を区切ります。

• 空白には、空白文字\t、\n、\rおよび\fがあります。

  たとえば、"c:\\Program Files"と指定できるc:\Program Filesなど、空白を含むパスを設定したり、エスケープc:\Program" "Filesを回避できます。

• パス・コンポーネントなどの空白が含まれるオプションは、引用符文字('"')を使用して全体を引用符で囲む必要があります。

• 引用符で囲む文字列には、文字\n、\r、\tおよび\fを含めることができます。 これらは、それぞれのASCIIコードに変換されます。

• ファイル名に空白が含まれている場合は、そのファイル名全体を二重引用符で囲みます。

• 引数ファイル内のファイル名は、現在のディレクトリから相対的で、引数ファイルの場所に対してではありません。

• 番号記号#を引数ファイルで使用して、コメントを指定します。 #の後の文字はすべて、行末まで無視されます。

• アット記号@が先頭に付いているオプションに@をさらに付けると、エスケープとして機能します(最初の@は削除され、残りの引数がランチャにリテラルとして渡されます)。

• 行は、行末で継続文字(\)を使用すると継続できます。 先頭の空白が切り捨てられて2行が連結されます。 先行空白をトリミングしないようにするために、継続文字(\)を最初の列に置くことができます。

• バックスラッシュ(\)はエスケープ文字であるため、バックスラッシュ文字は別のバックスラッシュ文字でエスケープする必要があります。

• 部分引用は可能で、ファイルの終わりで閉じられます。

• \が最後の文字でないかぎり、オープン状態の引用は行末で終了するため、先頭の空白文字をすべて削除して次の行に連結されます。

• このようなリストでは、ワイルドカード(*)は使用できません(たとえば、*.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コード・ヒープの現在の状態を把握することにより、次のような疑問に答える上で役立つ場合があります。

• JITがオン/オフを何度も繰り返したのはなぜか。

• すべてのコード・ヒープ領域はどこに行ってしまったのか。

• メソッド・スイーパが効果的に機能しないのはなぜか。

これを把握するため、コード・ヒープのオンザフライ分析を可能にするコード・ヒープの状態の分析機能が実装されました。 分析プロセスは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仮想マシン(JVM)統合ロギング・フレームワークを使用したロギングを構成または有効にします。

シノプシス

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

what

タグとレベルの組合せを指定します(tag1 [+ tag2...] [*] [= level] [,...])。 ワイルドカード(*)が指定されている場合を除き、指定されたとおりのタグでタグ付けされたログ・メッセージのみが照合されます。 「-Xlogのタグとレベル」を参照してください。

output

出力のタイプを設定します。 outputを省略すると、タイプはデフォルトでstdoutになります。 「-Xlogの出力」を参照してください。

decorators

カスタムのデコレータ・セットを使用するように出力を構成します。 decoratorsを省略すると、デフォルトでuptime、levelおよびtagsになります。 「装飾」を参照してください。

output-options

-Xlogロギング出力オプションを設定します。

説明

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 is

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

デフォルトの構成

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

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

実行時のロギングの制御

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

-Xlogのタグとレベル

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

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

• off
• trace
• debug
• info
• warning
• error

使用可能なログ・タグ:

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

-Xlogの出力

-Xlogオプションでは、次のタイプの出力がサポートされます。

• stdout --- 出力を標準出力に送信
• stderr --- 出力をstderrに送信
• file= filename ---出力をテキスト・ファイルに送信します。

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

装飾

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

[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のように指定することができます。

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

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

-Xlog使用例

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

-Xlog

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

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

-Xlog:gc

gcタグでタグ付けされたメッセージを、infoレベルを使用してstdoutに記録します。 レベルwarningの他のすべてのメッセージに対するデフォルトの構成は有効です。

-Xlog:gc,safepoint

gcタグまたはsafepointタグのいずれかでタグ付けされたメッセージを、どちらもinfoレベルを使用してデフォルトのデコレーションでstdoutに記録します。 gcとsafepointの両方でタグ付けされたメッセージは記録されません。

-Xlog:gc+ref=debug

gcとrefの両方のタグでタグ付けされたメッセージを、debugレベルを使用してデフォルトのデコレーションでstdoutに記録します。 この2つのタグのいずれかのみでタグ付けされたメッセージは記録されません。

-Xlog:gc=debug:file=gc.txt:none

gcタグでタグ付けされたメッセージを、debugレベルを使用してデコレーションなしでgc.txtと呼ばれるファイルに記録します。 レベルwarningの他のすべてのメッセージに対するデフォルトの構成は引き続き有効です。

-Xlog:gc=trace:file=gctrace.txt:uptimemillis,pids:filecount=5,filesize=1024

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

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

-Xlog:gc::uptime,tid

gcタグでタグ付けされたメッセージをデフォルト・レベル'info'を使用してデフォルト出力 stdoutに記録し、デコレーションuptimeおよびtid使用します。 レベルwarningの他のすべてのメッセージに対するデフォルトの構成は引き続き有効です。

-Xlog:gc*=info,safepoint*=off

infoレベルを使用して少なくともgcでタグ付けされたメッセージを記録しますが、safepointでタグ付けされたメッセージのロギングをオフにします。 gcとsafepointの両方でタグ付けされたメッセージは記録されません。

-Xlog:disable -Xlog:safepoint=trace:safepointtrace.txt

警告およびエラーを含めてすべてのロギングをオフにした後、safepointでタグ付けされたメッセージを、traceレベルを使用してファイルsafepointtrace.txtに対して有効にします。 コマンド行が-Xlog:disableで開始されているため、デフォルトの構成は適用されません。

複合 -Xlog使用例

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

-Xlog:gc+class*=debug

少なくともgcタグとclassタグでタグ付けされたメッセージを、debugレベルを使用してstdoutに記録します。 レベルwarningの他のすべてのメッセージに対するデフォルトの構成は引き続き有効です

-Xlog:gc+meta*=trace,class*=off:file=gcmetatrace.txt

少なくともgcタグおよびmetaタグでタグ付けされたメッセージを、 traceレベルを使用してファイルmetatrace.txtに記録しますが、classでタグ付けされたメッセージはすべてオフにします。 gc、metaおよび classでタグ付けされたメッセージは、 class*がoffに設定されているため、記録されません。 レベルwarningの他のすべてのメッセージに対するデフォルトの構成は、classが含まれるメッセージを除いて有効です。

-Xlog:gc+meta=trace

gcおよびmetaに完全一致するタグでタグ付けされたメッセージを、traceレベルを使用してstdoutに記録します。 レベルwarningの他のすべてのメッセージに対するデフォルトの構成は引き続き有効です。

-Xlog:gc+class+heap*=debug,meta*=warning,threads*=off

少なくともgcタグ、classタグおよびheapタグでタグ付けされたメッセージを、traceレベルを使用してstdoutに記録しますが、metaでタグ付けされたメッセージのみwarningレベルを使用します。 レベルwarningの他のすべてのメッセージに対するデフォルトの構成は、threadsが含まれるメッセージを除いて有効です。

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

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

コマンド行、入力ツール、API (パッケージjava.lang.managementに含まれるクラスなど)のいずれを使用して人間工学に基づいて設定されていようと、すべてのJava仮想マシン(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のいずれかが通常のページの使用に戻ります。

Oracle Solaris、LinuxおよびWindowsは、大規模なページをサポートしています。

Oracle Solarisのラージ・ページ・サポート

Oracle Solarisには、複数のページ・サイズ・サポート(MPSS)が含まれます。 追加の構成は必要ありません。

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

2.6カーネルは、ラージ・ページをサポートします。 一部のベンダーは、2.4ベースのリリースのコードをバックポートしています。 システムがラージ・ページ・メモリーをサポートしているかどうかを確認するには、次を試行してください:

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

出力に3つの"Huge"変数が示されている場合、システムはラージ・ページ・メモリーをサポートしていますが、構成する必要があります。 コマンドが何も出力しない場合、システムはラージ・ページをサポートしていません。 ラージ・ページ・メモリーを使用するシステムを構成するには、rootとしてログインして、次のステップを実行してください:

1. オプション-XX:+UseSHM (-XX:+UseHugeTLBFSのかわり)を使用する場合、SHMMAX値を増やします Javaヒープ・サイズより大きくする必要があります。 4GB以下の物理RAMを搭載するシステムでは、次によりすべてのメモリーが共有可能になります。

   # echo 4294967295 > /proc/sys/kernel/shmmax

2. オプション-XX:+UseSHMまたは-XX:+UseHugeTLBFSを使用する場合、ラージ・ページの数を指定します。 次の例では、4GBシステムの3GBがラージ・ページに予約されます(2048KBのラージ・ページ・サイズを仮定する場合、3GB = 3 * 1024MB = 3072MB = 3072 * 1024KB = 3145728KB and 3145728KB / 2048KB = 1536):

   # echo 1536 > /proc/sys/vm/nr_hugepages

   ノート: システムを再起動した後に/procに含まれる値がリセットされるため、初期化スクリプト(たとえば、rc.localやsysctl.confなどです。)でその値を設定する必要がある場合があります。

• OSカーネル・パラメータ/proc/sys/kernel/shmmaxまたは/proc/sys/vm/nr_hugepagesを構成(またはサイズ変更)する場合、JavaプロセスがJavaヒープ以外の領域に対してラージ・ページを割り当てることがあります。 これらのステップを使用して、次の領域に対してラージ・ページを割り当てることができます:

  • Javaヒープ
  • コード・キャッシュ
  • パラレルGCのマーキング・ビットマップ・データ構造

  その結果、Javaヒープのサイズにnr_hugepagesパラメータを構成すると、領域のサイズが非常に大きいためにJVMがラージ・ページのコード・キャッシュ領域の割当てに失敗する場合があります。

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

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

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

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

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

アプリケーション・クラス・データ共有(AppCDS)は、クラス・データ共有(CDS)を拡張して、アプリケーション・クラスを共有アーカイブに配置できるようにします。

コア・ライブラリ・クラスに加えて、AppCDSでは、次の場所からのクラス・データ共有がサポートされています。

• ランタイム・イメージのプラットフォーム・クラス
• ランタイム・イメージのアプリケーション・クラス
• クラス・パスのアプリケーション・クラス
• モジュール・パスのアプリケーション・クラス

アプリケーション・クラスをアーカイブすると、実行時の起動時間が向上します。 また、複数のJVMプロセスが実行される場合、AppCDSは読取り専用メタデータのメモリー共有を使用して、ランタイム・フットプリントを削減します。

CDS/AppCDSはJARファイルのクラスのアーカイブのみをサポートします。

JDK 11より前は、空でないディレクトリは次の条件に基づいて致命的エラーとして報告されました。

• 基底CDSの場合、空でないディレクトリは-Xbootclasspath/aパスに存在できません

• -XX:+UseAppCDSを使用した場合、空でないディレクトリは-Xbootclasspath/aパス、クラス・パスおよびモジュール・パスに存在できませんでした。

JDK 11以降では、-XX:+UseAppCDSが廃止され、空でないディレクトリの動作はクラス・リストのクラス型に基づくようになりました。 空でないディレクトリは次の条件に基づいて致命的エラーとして報告されます。

• アプリケーション・クラスまたはプラットフォーム・クラスがロードされていない場合、空でないディレクトリが-Xbootclasspath/aパスに存在する場合にのみ、ダンプ時にエラーが報告されます

• アプリケーション・クラスまたはプラットフォーム・クラスがロードされている場合、空でないディレクトリが-Xbootclasspath/aパス、クラス・パスまたはモジュール・パスに存在すると、ダンプ時にエラーが報告されます

JDK 11以降で、-XX:DumpLoadedClassList= class_list_fileを使用すると、すべてのクラス(システム・ライブラリ・クラスとアプリケーション・クラスの両方)を含むクラス・リストが生成されます。 完全なクラス・リストを作成するために、-XX:+UseAppCDSを-XX:DumpLoadedClassListとともに指定する必要はなくなりました。

JDK 11以降では、UseAppCDSが廃止されたため、デフォルトでSharedArchiveFileが製品フラグになりました。 +UnlockDiagnosticVMOptionsをSharedArchiveFileに指定すると、どの構成でも不要になります。

クラス・データ共有(CDS)/AppCDSはクラス・リスト内の配列クラスのアーカイブをサポートしていません。 クラス・リスト内で配列が検出されると、CDSダンプ時に明示的なエラー・メッセージが表示されます。

Preload Warning: Cannot find array_name

クラス・リスト内では配列が許可されていませんが、一部の配列クラスは引き続きCDS/AppCDSダンプ時に作成される可能性があります。 これらの配列は、Javaクラス・ローダー(PlatformClassLoaderおよびシステム・クラス・ローダー)がダンプ時にクラスをロードするために使用するJavaコードの実行中に作成されます。 作成された配列は、ロードされたクラスの残りとともにアーカイブされます。

モジュール・パスをサポートするためのクラス・データ共有の拡張

JDK 11では、クラス・データ共有(CDS)がモジュール・パスのクラスのアーカイブをサポートするように改良されています。

• --module-path VMオプションを使用してCDSアーカイブを作成するには、次のコマンド行構文を使用します。

  java -Xshare:dump -XX:SharedClassListFile=class_list_file -XX:SharedArchiveFile=shared_archive_file --module-path=path_to_modular_jar -m module_name

• --module-path VMオプションを使用してCDSアーカイブを実行するには、次のコマンド行構文を使用します。

  java -XX:SharedArchiveFile=shared_archive_file --module-path=path_to_modular_jar -m module_name

次の表は、モジュール・パスに関連するVMオプションを-Xshareオプションと組み合せて使用する方法について説明しています。

¹ --module-pathでモジュールを指定する方法は2つありますが、モジュール式JARまたは展開型モジュールの場合はモジュールJARのみがサポートされています。

²ダンプ時間とランタイムの対比で、異なるmpを指定できます。 たとえば、アーカイブ済のクラスKをダンプ時にmp1.jarからロードしたが、mpを変更して実行時に別のmp2.jarからこのクラスを使用できるようにすると、アーカイブ・バージョンのKは実行時に無視されます。Kは動的にロードされます。

³現在、アップグレード可能な(java.compilerおよびjdk.internal.vm.compiler)のシステム・モジュールは2つだけです。 ただし、これらのモジュールは製品ソフトウェアでほとんどアップグレードされません。

⁴ JEP 261で説明されているように、--patch-moduleを本番で使用することは推奨されていません。

⁵ --limit-modulesはテスト用です。 本番ソフトウェアではほとんど使用されません。

ダンプ時に--upgrade-module-path、--patch-moduleまたは--limit-modulesが指定されると、エラーが出力されJVMは終了します。 たとえば、ダンプ時に--limit-modulesオプションが指定されると、次のエラーが表示されます。

Error occurred during initialization of VM
Cannot use the following option when dumping the shared archive: --limit-modules

実行時に--upgrade-module-path、--patch-moduleまたは--limit-modulesが指定されると、CDSが無効であることを示す警告メッセージが出力されます。 たとえば、実行時に--limit-modulesオプションが指定されると、次の警告が表示されます。

Java HotSpot(TM) 64-Bit Server VM warning: CDS is disabled when the --limit-modules option is specified.

その他の注意点:

• -cpと--module-pathのすべての有効な組合せがサポートされています。

• モジュール・パス内に空のディレクトリがあると致命的エラーが発生します。 次のエラー・メッセージが表示されます。

  Error: non-empty directory <directory> Hint: enable -Xlog:class+path=info to diagnose the failure Error occurred during initialization of VM Cannot have non-empty directory in paths

• クラス・パスとは異なり、ダンプ時のモジュール・パスが実行時のモジュール・パスと同一であるか、その接頭辞であることを必要とする制約はありません。

• モジュール・パス内の既存のJARがアーカイブの生成後に更新されると、アーカイブは無効になります。

• モジュール・パスからJARを削除しても共有アーカイブは無効になりません。 削除されたJARのアーカイブ済のクラスは実行時に使用されません。

動的CDSアーカイブ

動的CDSアーカイブは、Javaアプリケーションの終了時にクラスのアーカイブを可能にするためにAppCDSを拡張します。 これにより、各アプリケーションのクラス・リストを作成する際の試行実行ステップを除去することで、AppCDSの操作性が向上します。 アーカイブされたクラスには、JDKに含まれているデフォルトCDSアーカイブに存在しないロードされたすべてのアプリケーション・クラスとライブラリ・クラスが含まれます。

動的アーカイブを作成する場合は、ベース・アーカイブが必要です。 ベース・アーカイブが指定されていない場合、デフォルトCDSアーカイブがベース・アーカイブとして使用されます。

デフォルトCDSアーカイブをベース・アーカイブとして使用して動的CDSアーカイブを作成するには、Javaアプリケーションを実行するためのコマンドラインに-XX:ArchiveClassesAtExit=<dynamic archive>オプションを追加します。

デフォルトCDSアーカイブが存在しない場合、VMは次のエラーで終了します:

ArchiveClassesAtExit not supported when base CDS archive is not loaded

動的CDSアーカイブを使用してJavaアプリケーションを実行するには、Javaアプリケーションを実行するためのコマンドラインに-XX:SharedArchiveFile=<dynamic archive>オプションを追加します。

コマンド行でベース・アーカイブを指定する必要はありません。 ベース・アーカイブ情報(名前およびフルパスを含む)は、動的アーカイブ・ヘッダーから取得されます。 ユーザーは、通常のAppCDSアーカイブを指定するために-XX:SharedArchiveFileオプションを使用することもできます。 したがって、-XX:SharedArchiveFileオプションで指定したアーカイブは、通常アーカイブでも動的アーカイブでもかまいません。 VMの起動中に、指定されたアーカイブ・ヘッダーが読み取られます。 -XX:SharedArchiveFileが通常のアーカイブを参照する場合、動作は変更されません。 -XX:SharedArchiveFileが動的アーカイブを参照する場合、VMは動的アーカイブからベース・アーカイブのロケーションを取得します。 動的アーカイブがデフォルトCDSアーカイブで作成された場合は、現在のデフォルトCDSアーカイブが使用され、現在のランタイム環境との相対位置で検出されます。

動的CDSアーカイブのダンプ時間および実行時におけるエラー・チェックの詳細は、JDK-8221706を参照してください。

共有アーカイブ・ファイルの作成と、それを使用したアプリケーションの実行

AppCDSアーカイブ

次のステップで、test.Helloアプリケーションで使用されるすべてのクラスを含む共有アーカイブ・ファイルを作成します。 最後のステップで、共有アーカイブ・ファイルを持つアプリケーションを実行します。

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 -verbose:class test.Hello

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

   Loaded test.Hello from shared objects file by sun/misc/Launcher$AppClassLoader

動的CDSアーカイブ

次のステップでは、test.Helloアプリケーションで使用されるクラスを含む動的CDSアーカイブ・ファイルを作成しますが、デフォルトCDSアーカイブには含まれません。 2番目のステップでは、動的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共有アーカイブに含まれるクラスを使用していることを確認します。

前述のステップ1と2を自動化するには、次のようなスクリプトを記述します:

    ARCHIVE=hello.jsa
    if test -f $ARCHIVE; then
        FLAG="-XX:SharedArchiveFile=$ARCHIVE"
    else
        FLAG="-XX:ArchiveClassesAtExit=$ARCHIVE"
    fi
    $JAVA_HOME/bin/java -cp hello.jar $FLAG test.Hello

AppCDSアーカイブと同様に、Javaバージョンが変更された場合はアーカイブを再生成する必要があります。 前述のスクリプトは、Javaバージョンを考慮して次のように調整できます:

    ARCHIVE=hello.jsa
    VERSION=foo.version
    if test -f $ARCHIVE -a -f $VERSION && cmp -s $VERSION $JAVA_HOME/release; then
        FLAG="-XX:SharedArchiveFile=$ARCHIVE"
    else
        FLAG="-XX:ArchiveClassesAtExit=$ARCHIVE"
        cp -f $JAVA_HOME/release $VERSION
    fi
    $JAVA_HOME/bin/java -cp hello.jar $FLAG test.Hello

現在、同じCDSアーカイブへの同時ダンプ操作はサポートしていません。 同じCDSアーカイブへの複数の書き込みを避けるように注意する必要があります。

ユーザーは、特定のベース・アーカイブを使用して、動的CDSアーカイブを作成することもできます。たとえば、base.jsaは次のように指定します:

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

動的CDSアーカイブhello.jsaおよび特定のベースCDSアーカイブbase.jsaを使用してアプリケーションを実行するには:

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

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

ベース・アーカイブを指定するための前述のコマンドは、動的アーカイブの作成に使用されたベース・アーカイブが移動された場合に有効です。 通常、ベース・アーカイブ情報は動的アーカイブ・ヘッダーから取得できるので、動的アーカイブを指定するだけで十分です。

複数アプリケーション・プロセス全体での共有アーカイブの共有

複数アプリケーション・プロセス間で同じアーカイブ・ファイルを共有できます。 アーカイブはプロセスのアドレス空間にメモリー・マップされるため、これによりメモリー使用量が低下します。 オペレーティング・システムは、これらのプロセス全体で読取り専用ページを自動的に共有します。

次のステップに、様々なアプリケーションで共有可能な共通アーカイブを作成する方法を示します。 common.jar、hello.jarおよびhi.jarからのクラスは、(ステップ3)のアーカイブ・ステップですべてクラス・パスにあるため、common.jsaでアーカイブされます。

hello.jarおよびhi.jarのクラスを含めるには、 -cpパラメータで指定するクラス・パスに.jarファイルを追加する必要があります。

1. Helloアプリケーションで使用されるすべてのクラスのリストと、Hiアプリケーションに関する別のリストを作成します。

   java -XX:DumpLoadedClassList=hello.classlist -cp common.jar:hello.jar Hello

   java -XX:DumpLoadedClassList=hi.classlist -cp common.jar:hi.jar Hi

2. 共有アーカイブ・ファイルを共有するすべてのアプリケーションで使用されるクラスの単一のリストを作成します。

   Oracle Solaris、LinuxおよびmacOS 次のコマンドは、ファイルhello.classlistおよびhi.classlistを、1つのファイルcommon.classlistに結合します。

   cat hello.classlist hi.classlist > common.classlist

   Windows 次のコマンドは、ファイルhello.classlistおよびhi.classlistを、1つのファイルcommon.classlistに結合します。

   type hello.classlist hi.classlist > common.classlist

3. common.classlist内のすべてのクラスを含む、common.jsaという名前の共有アーカイブを作成します。

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

   使用するクラス・パス・パラメータは、HelloおよびHiアプリケーションで共有される共通のクラス・パス接頭辞です。

4. 同一の共有アーカイブを持つHelloおよびHiアプリケーションを実行します。

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

   java -XX:SharedArchiveFile=common.jsa -cp common.jar:hello.jar:hi.jar Hi

アーカイブ・ファイルに追加されるその他の共有データの指定

SharedArchiveConfigFileオプションを使用して、アーカイブ・ファイルに追加するその他の共有データを指定します。

-XX:SharedArchiveConfigFile=shared_config_file

JDK 9以降では、同じホストで複数のJVMプロセスが実行されている場合、メモリー共有のために記号と文字列オブジェクトの両方をアーカイブへの追加をサポートします。 この例では、Java EEクラスの同じセットを使用する複数のJVMプロセスがあります。 これらの共通クラスをロードして使用すると、新しいシンボルおよび文字列を作成し、JVMの内部"symbol"および"string"表に追加できます。実行時に、アーカイブ・ファイルからマップされたシンボルまたは文字列オブジェクトを複数のJVMプロセスにわたって共有できるため、全体的なメモリー使用率が減少します。また、アーカイブ文字列では、起動時間と実行時の両方にパフォーマンス上の利点が追加されます。

JDK 10以降では、アーカイブされたクラスのCONSTANT_Stringエントリは、ダンプ時に、インターン化された文字列オブジェクトに解決され、すべてのインターン化された文字列オブジェクトがアーカイブされます。 ただし、アーカイブ済のすべてのクラスのCONSTANT_Stringリテラルがすべて解決されても、クラス・ファイルに文字列リテラルでない追加の文字列を追加することは有益ですが、実行時にアプリケーションによって使用される可能性があります。

シンボル・データは、実行中のJVMプロセスに接続しているjcmdツールで生成する必要があります。 jcmdに関する項を参照してください。

次は、jcmdのシンボルdumpingコマンドの例です:

jcmd pid VM.symboltable -verbose

ノート: このjcmd出力の最初の行(プロセスID)と2行目の(@VERSION ...)は、構成ファイルから除外してください。

構成ファイルの例

構成ファイルの例を次に示します。

VERSION: 1.0
@SECTION: Symbol
10 -1: linkMethod

この構成ファイルの例では、@SECTION: Symbolエントリは次の形式を使用します。

length refcount: symbol

共有シンボルのrefcountは常に-1です。

@SECTIONは、次に続くセクションのタイプを指定します。 セクション内のデータはすべて同じタイプである必要があり、そのタイプは@SECTIONで指定します。 異なるタイプのデータを混ぜることはできません。 異なる@SECTIONで指定された同じタイプの複数の区切られたデータ・セクションを1つのshared_config_file内に入れることができます。

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

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)を使用して任意の値を返すことができます。 値は次のとおりです。

• 0: 正常終了

• >0: エラー発生