java

javaコマンドは、Javaアプリケーションを起動する場合に使用できます。

形式

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

クラス・ファイルを起動する場合:

java [options] mainclass [args...] 

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

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

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

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

または

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で指定され、この指定がない場合はmoduleの値が使用されます。つまり、mainclassは、モジュールでメイン・クラスが指定されていない場合に使用され、また指定されている場合はその値をオーバーライドします。

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

source-file

単一のソース・ファイル・プログラムを起動する場合にのみ使用します。ソース・ファイル・モードを使用する場合に、メイン・クラスが含まれているソース・ファイルを指定します。「ソース・ファイル・モードで単一ファイルのソース・コードのプログラムを起動する方法」を参照してください

[args...]

オプション: mainclasssource-file-jar jarfile、および-mまたは--module module/mainclassの後の引数は、メイン・クラスに引数として渡されます。

説明

javaコマンドはJavaアプリケーションを起動します。これは、Java Runtime Environment (JRE)を起動し、指定されたクラスをロードし、そのクラスの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()メソッドに渡されます。

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

ソース・ファイル内に宣言されているクラスを起動するには、ソース・ファイル・モードでjavaランチャを実行します。ソース・ファイル・モードの開始は、javaコマンド行の2つの項目によって判断されます。
  • コマンド行の最初の項目(オプションやオプションの構成要素以外)。つまり、メイン・クラス名になりうるコマンド行の項目です。

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

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

注意:

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

ファイルに.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: Preview Language and VM Features』を参照)。

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

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

ソース・ファイル・モードでのコンパイルの手順:

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

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

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

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

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

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

  • コンパイラでは、JLS §7.6の最後に定義されているオプションの制約(つまり、名前付きパッケージ内の型は、その型名の後に.java拡張子が付いた名前のファイル内に存在する必要があるという制約)は強制されません。

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

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

  • 実行されるクラスは、ソース・ファイル内で最初に検出された最上位クラスです。それには、標準の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環境変数の内容は、コマンド行に指定した場合と同じ方法で処理されます。

一重引用符(')または二重引用符(")を使用して、空白文字が含まれる引数を囲むことができます。開始引用符と対応する最初の終了引用符の間の内容すべてが引用符のペアを除いて保存されます。対応する引用符が見つからなかった場合、ランチャはエラー・メッセージを発行して停止します。@-filesは、コマンド行に指定するとサポートされます。ただし、@-files内と同様、ワイルドカードの使用はサポートされません。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から始まります。

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

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

次の各項では、廃止、非推奨および削除されたオプションについて説明します。

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つの呼出しの違いを認識できません。たとえば、ディレクトリmydira.jarb.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...または-p modulepath

ディレクトリのセミコロン(;)区切りリスト(各ディレクトリはモジュールのディレクトリです)。

--upgrade-module-path modulepath...

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

--add-modules module[,module...]

初期モジュールに加えて解決するルート・モジュールを指定します。また、moduleは、ALL-DEFAULTALL-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プログラミング言語エージェントをロードします。

--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オプションにより、シェル拡張の後かつ引数処理の前にランチャで引数ファイルの内容を展開できるようになることで、コマンド行の長さに関する制限を克服できます。引数ファイルの内容が展開されるのは、そうしないと、-Xdisable-@filesオプションが検出されるまでコマンド行に指定されるためです。

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

java @argfile

@argfileの使用方法の説明および例は、「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

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

-Xfuture

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

-Xint

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

-Xinternalversion

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

-Xloggc:option

JVM統合ロギング・フレームワークを有効にします。GCステータスをタイムスタンプとともにファイルに記録します。

-Xlog:option

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

-Xmixed

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

-Xmn size

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

-Xmn256m
-Xmn262144k
-Xmn268435456

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

-Xms size

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

-Xms6291456
-Xms6144k
-Xms6m

このオプションを設定しない場合、初期サイズは、Old世代とYoung世代に割り当てられたサイズの合計として設定されます。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は、SIGHUPSIGINT、およびSIGTERMを使用して、シャットダウン・フックの実行を開始します。

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

  • Windows:

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

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

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

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

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

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

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

-Xshare:mode

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

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

auto

可能な場合は、CDSを使用します。これはJava HotSpot 32-Bit Client VMのデフォルト値です。

on

CDSの使用が必須です。このオプションは、クラス・データ共有を使用できない場合、エラー・メッセージを出力して終了します。

注意:

-Xshare:onはテスト目的にのみ使用されますが、オペレーティング・システムでアドレス空間配置のランダム化が使用されることにより、断続的なエラーが発生する可能性があります。このオプションは、本番環境では使用しないでください。

off

CDSを使用しないように指示します。

-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/x64 (64ビット): 1024KB

  • Windows: デフォルト値は、仮想メモリーによって異なります。

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

-Xss1m
-Xss1024k
-Xss1048576

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

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

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

--add-exports module/package=target-module(,target-module)*

モジュール宣言に関係なく、packagetarget-moduleにエクスポートするようにmoduleを更新します。target-moduleをALL-UNNAMEDにすると、名前のないモジュールをすべてエクスポートできます。

--add-opens module/package=target-module(,target-module)*

モジュール宣言に関係なく、packagetarget-moduleに対してオープンするように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ファイルまたはディレクトリ内のクラスおよびリソースでモジュールをオーバーライドまたは拡張します。

--disable-@files

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

--source version

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

macOSの追加オプション

次の追加オプションは、macO専用です。

-XstartOnFirstThread

最初の(AppKit)スレッドでmain()メソッドを実行します。

-Xdock:name=application_name

ドックに表示されるデフォルトのアプリケーション名をオーバーライドします。

-Xdock:icon=path_to_icon_file

ドックに表示されるデフォルトのアイコンをオーバーライドします。

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

これらのjavaオプションはJava HotSpot VMのランタイム動作を制御します。

-XX:ActiveProcessorCount=x

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

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

-XteHeX:AllocaapAt=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:CompilerDirectivesFile=file

プログラムの起動時にディレクティブをファイルからディレクティブのスタックに追加します。コンパイラ・ディレクティブおよびコマンド行に関する項を参照してください。

-XX:CompilerDirectivesPrint

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

-XX:ConcGCThreads=n

パラレル・マーキング・スレッド数を設定します。nをパラレル・ガベージ・コレクション・スレッド(ParallelGCThreads)の数の約1/4に設定します。

-XX:+DisableAttachMechanism

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

注意:

JDKに同梱されているjcmdjinfojmapjstackなどのツールは、あるJDKバージョンのツールを使用して別のJDKバージョンをトラブルシューティングした場合にはサポートされません。

-XX:ErrorFile=filename

回復不能なエラーが発生した場合に、エラー・データが書き込まれるパスとファイル名を指定します。デフォルトで、このファイルは現在の作業ディレクトリに作成され、hs_err_pidpid.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:+FailOverToOldVerifier

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

-XX:+FlightRecorder

アプリケーション実行時のJava Flight Recorder (JFR)の使用を有効にします。

注意:

-XX:+FlightRecorderオプションは、JFRを使用するのに不要になりました。この変更は、JDK 8u40で行われました。
-XX:FlightRecorderOptions=parameter=value

JFRの動作を制御するパラメータを設定します。

使用可能なJFR parameter=valueエントリは次のとおりです。

allow_threadbuffers_to_disk={true|false}

バッファ・スレッドがブロックされた場合にスレッド・バッファをディスクに直接書き込むかどうかを指定します。デフォルトでは、このパラメータは無効になっています。

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 KBに設定されます。このパラメータをオーバーライドするとパフォーマンスが低下する可能性があるため、お薦めしません。

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

-XX:InitiatingHeapOccupancyPercent=n

マーキング・サイクルを開始するJavaヒープ占有率のしきい値を設定します。デフォルトの占有率はJavaヒープ全体の45%です。

-XX:LargePageSizeInBytes=size

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

次の例では、ラージ・ページ・サイズを4MBに設定する方法を示します。

-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:MaxGCPauseMillis=ms

望ましい最大一時停止時間の目標値を設定します。デフォルト値は200ミリ秒です。指定された値はヒープ・サイズには適応されません。

-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は現在のプロセスを指定します)。

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

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

OutOfMemoryError例外が最初にスローされた場合に実行するカスタム・コマンドまたは一連のセミコロン区切りのコマンドを設定します。文字列にスペースを含む場合は、二重引用符で囲む必要があります。コマンド文字列の例については、-XX:OnErrorオプションの説明を参照してください。

-XX:ParallelGCThreads=n

STWワーカー・スレッドの値を設定します。nの値は論理プロセッサ数に設定します。nの値は論理プロセッサ数と同じです(最大値は8)。論理プロセッサが9個以上ある場合は、nの値を論理プロセッサ数の約5/8に設定します。これはほとんどのケースで機能しますが、nの値が論理プロセッサ数の約5/16になるような大規模なSPARCは例外です。

-XX:+PerfDataSaveToFile

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

jstat -class file:///path/hsperfdata_pid
jstat -gc file:///path/hsperfdata_pid
-XX:+PrintCommandLineFlags

コマンド行に表示されるエルゴノミクスに従って選択されたJVMフラグの出力を有効にします。これは、ヒープ領域サイズや選択されたガベージ・コレクタなどのJVMによって設定されたエルゴノミクス値を知るために役立つ可能性があります。デフォルトでは、このオプションは無効になっており、フラグは出力されません。

-XX:+PreserveFramePointer 

汎用レジスタとしてRBPレジスタを使用するか(-XX:-PreserveFramePointer)、RBPレジスタを使用して現在実行されているメソッドのフレーム・ポインタを保持するか(-XX:+PreserveFramePointer)を選択します。フレーム・ポインタが使用可能な場合は、外部プロファイリング・ツール(Linux perfなど)でより正確なスタック・トレースを構成できます。

-XX:+PrintNMTStatistics

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

-XX:+RelaxAccessControlCheck

ベリファイアのアクセス制御チェックの量を減らします。デフォルトでは、このオプションは無効になっており、最近のバイトコード・バージョンを使用したクラスでは、無視されます(つまり、無効として処理されます)。古いバージョンのバイトコードのクラスに対してそれを有効にできます。

-XX:SharedArchiveFile=path

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

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

-XX:SharedArchiveConfigFile=shared_config_file

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

-XX:SharedClassListFile=file_name

クラス・データ共有(CDS)アーカイブに格納するクラスの名前を含むテキスト・ファイルを指定します。このファイルには、クラスのフル・ネームを1行に1つ含めます。ただしドット(.)はスラッシュ(/)で置き換えます。たとえば、クラスjava.lang.Objecthello.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スレッド・スタック・サイズ(KB単位)を設定します。kなどのスケール接尾辞を使用すると、-XX:ThreadStackSize=1kがJavaスレッド・スタック・サイズを1024*1024バイトまたは1MBに設定するように、KB値のスケールとなります。デフォルト値はプラットフォームによって異なります。

  • Linux: 1024KB

  • macOS: 1024KB

  • Oracle Solaris: 1024KB

  • Windows: デフォルト値は、仮想メモリーによって異なります。

次の例では、様々な単位でスレッド・スタック・サイズを1MBに設定する方法を示しています。

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

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

-XX:-UseBiasedLocking

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

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

-XX:-UseCompressedOops

圧縮されたポインタの使用を無効にします。デフォルトではこのオプションが有効であり、Javaヒープ・サイズが32GBより小さい場合に圧縮ポインタが使用されます。このオプションが有効にされている場合、オブジェクト参照は64ビット・ポインタのかわりに32ビットのオフセットで表され、アプリケーションを32GB未満のJavaヒープ・サイズで実行している場合に、一般にパフォーマンスが向上します。このオプションは64ビットJVMの場合にのみ機能します。

Javaヒープ・サイズが32GBより大きい場合にも圧縮ポインタを使用できます。-XX:ObjectAlignmentInBytesオプションを参照してください。

-XX:-UseContainerSupport

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

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

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

XX:+UseGCLogRotation

大きなログ・ファイルを処理します。このオプションは、-Xloggc:filenameと一緒に使用する必要があります。

-XX:NumberOfGClogFiles=number_of_files

大きなログ・ファイルを処理します。number_of_filesは、1以上にする必要があります。デフォルトは1です。

-XX:GCLogFileSize=number

大きなログ・ファイルを処理します。numberの形式は、numberMまたはnumberKのいずれかです。デフォルトは512Kに設定されています。

-XX:+UseHugeTLBFS

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

「ラージ・ページ」を参照してください。

-XX:+UseLargePages

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

「ラージ・ページ」を参照してください。

-XX:+UseMembar

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

-XX:+UsePerfData

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

-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: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:+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:RTMRetryCount=number_of_retries

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

-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命令が使用できるハードウェア(Intel、SPARC、ARM64など)に対してハードウェアベースのFMA組込みを有効にします。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では、新しい命令 XBEGINXABORTXENDおよびXTESTが導入されています。XBEGINおよびXEND命令は、トランザクションとして実行するための命令セットを囲みます。トランザクションの実行時に競合が見つからなかった場合、メモリーとレジスタの変更が、XEND命令で同時にコミットされます。XABORT命令ではトランザクションを明示的に中止でき、XEND命令では命令セットがトランザクション内で実行中かどうかを確認できます。

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

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

-XX:+UseSHA

SPARCハードウェアのSHA暗号化ハッシュ関数のハードウェアベースの組込みを有効にします。UseSHAオプションは、UseSHA1IntrinsicsUseSHA256Intrinsicsおよび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:+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仮想マシンのフラグ引数の検証」を参照してください。

-XX:+UnlockDiagnosticVMOptions

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

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

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

-XX:+AggressiveHeap

Javaヒープ最適化を有効にします。これにより、コンピュータの構成(RAMおよびCPU)に基づいて、メモリーが集中的に割り当てられる長時間実行ジョブに最適になるように、各種パラメータを設定します。デフォルトでは、このオプションは無効になっており、ヒープは最適化されません。

-XX:+AlwaysPreTouch

JVM初期化時にJavaヒープ上のすべてのページのアクセスを有効にします。これにより、main()メソッドに入る前に、すべてのページがメモリーに入れられます。このオプションは、すべての仮想メモリーを物理メモリーにマッピングして、長時間実行システムをシミュレートするテストで使用できます。デフォルトでは、このオプションは無効になっており、JVMヒープ領域がいっぱいになると、すべてのページがコミットされます。

-XX:+CMSClassUnloadingEnabled

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

-XX:CMSExpAvgFactor=percent

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

-XX:CMSExpAvgFactor=15
-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:+ExplicitGCInvokesConcurrentAndUnloadsClasses

System.gc()要求を使用して、並行GCの呼出しと並行GCサイクル時のクラスのアンロードを有効にします。このオプションはデフォルトで無効にされており、非推奨の-XX:+UseConcMarkSweepGCオプションでのみ有効にできます。

-XX:G1HeapRegionSize=size

ガベージファースト(G1)コレクタを使用した場合に、Javaヒープが再分割される領域のサイズを設定します。この値は2の累乗で、1MBから32MBの範囲で指定できます。最小Javaヒープ・サイズを基に、リージョンが約2048個になるようにします。デフォルトの領域サイズは、ヒープ・サイズに基づいて、エルゴノミクスに従って決定されます。

次の例では、再分割のサイズを16MBに設定します。

-XX:G1HeapRegionSize=16m
-XX:G1HeapWastePercent=percent

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

-XX:G1MaxNewSizePercent=percent

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

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

この設定はJava HotSpot VMビルド23以前では使用できません。

-XX:G1MixedGCCountTarget=number

マーキング・サイクル後に古いリージョンのライブ・データ(最大でG1MixedGCLIveThresholdPercent%)を収集する混合ガベージ・コレクションの目標回数を設定します。デフォルトは、8回の混合ガベージ・コレクションです。混合コレクションの実行を、この目標回数以内に抑えます。

この設定はJava HotSpot VMビルド23以前では使用できません。

-XX:G1MixedGCLiveThresholdPercent=percent

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

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

この設定はJava HotSpot VMビルド23以前では使用できません。

-XX:G1NewSizePercent=percent

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

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

この設定はJava HotSpot VMビルド23以前では使用できません。

-XX:G1OldCSetRegionThresholdPercent=percent

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

この設定はJava HotSpot VMビルド23以前では使用できません。

-XX:G1ReservePercent=percent

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

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

-XX:G1ReservePercent=20
-XX:InitialHeapOccupancyPercent=percent

マーキング・サイクルを開始するJavaヒープ占有率のしきい値を設定します。デフォルトの占有率はJavaヒープ全体の45%です。

-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:InitialSurvivorRatio=ratio

スループット・ガベージ・コレクタ(これは-XX:+UseParallelGCおよび-XX:+UseParallelOldGCオプションによって有効にする)によって使用される初期Survivor領域率を設定します。適応型のサイズ変更は、-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

並行GCサイクルを開始するヒープ占有率(0から100)を設定します。これはいずれかの世代(G1ガベージ・コレクタなど)だけでなく、ヒープ全体の占有率に基づいて並行GCサイクルをトリガーするガベージ・コレクタによって使用されます。

デフォルトでは、開始値は45%に設定されます。0の値は無停止のGCサイクルを示します。次の例は、開始ヒープ占有率を75%に設定する方法を示しています。

-XX:InitiatingHeapOccupancyPercent=75
-XX:MaxGCPauseMillis=time

GCの最大一時停止時間(ミリ秒単位)の目標を設定します。これはソフト・ゴールのため、JVMはその実現のために最善の努力をします。指定された値はヒープ・サイズには適応されません。デフォルトでは、最大一時停止時間値はありません。

次の例は、最大目標一時停止時間を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

Oracle Solaris 7およびOracle Solaris 8 SPARCプラットフォームの場合の上限は、およそ4,000Mバイトからオーバーヘッドの量を引いたものです。Oracle Solaris 2.6およびx86プラットフォームの場合の上限は、およそ2,000Mバイトからオーバーヘッドの量を引いたものです。Linuxプラットフォームの場合の上限は、およそ2,000Mバイトからオーバーヘッドの量を引いたものです。

-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: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:NewRatio=ratio

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

-XX:NewRatio=1
-XX:NewSize=size

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

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

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

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

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

-XX:ParallelGCThreads=threads

stop-the-world (STW)ワーカー・スレッドの値を設定します。このオプションは、threadsの値を論理プロセッサの数に設定します。threadsの値は論理プロセッサ数と同じです(最大値は8)。

論理プロセッサが9個以上ある場合は、threadsの値を論理プロセッサ数の約5/8に設定します。これはほとんどのケースで機能しますが、threadsの値が論理プロセッサ数の約5/16になるような大規模なSPARCシステムは例外です。

デフォルト値は、JVMに使用可能なCPUの数によって異なります。

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

-XX:ParallelGCThreads=2
-XX:+ParallelRefProcEnabled

パラレル参照処理を有効にします。デフォルトでは、このオプションは無効になっています。

-XX:+PrintAdaptiveSizePolicy

適応型世代サイズ変更に関する情報の出力を有効にします。デフォルトでは、このオプションは無効になっています。

-XX:+ScavengeBeforeFullGC

各フルGCの前にYoung世代のGCを有効にします。このオプションはデフォルトで有効化されています。フルGCの前にYoung世代を清掃することによって、Old世代の領域からYoung世代の領域に到達可能なオブジェクト数を削減できるため、これを無効にしないことをお薦めします。各フルGCの前にYoung世代のGCを無効にするには、オプション-XX:-ScavengeBeforeFullGCを指定します。

-XX:-ShrinkHeapInSteps

オプション–XX:MaxHeapFreeRatioで指定した目標サイズまでJavaヒープを徐々に減らします。このオプションはデフォルトで有効化されています。無効にすると、複数のガーベジ・コレクション・サイクルを要求するかわりにJavaヒープを目標サイズまで即時減らします。Javaヒープ・サイズを最小化する場合は、このオプションを無効にします。このオプションを無効にすると、パフォーマンス低下が発生する可能性があります。

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

–XX:StringDeduplicationAgeThreshold=threshold

重複除外の候補とみなされる、指定した期間に到達しつつあるStringオブジェクトを指定します。オブジェクトの期間は、オブジェクトがガベージ・コレクションで存続した回数の測定値です。これは、殿堂入りと呼ばれることもあります。非推奨の-XX:+PrintTenuringDistributionオプションを参照してください。

注意:

この期間に到達する前に古いヒープ・リージョンに昇格された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ガベージ・コレクタ(スループット・コレクタとも呼ばれる)の使用を有効にします。

デフォルトで、このオプションは無効にされており、マシンの構成とJVMのタイプに基づいて、コレクタが自動的に選択されます。これを有効にすると、-XX:+UseParallelOldGCオプションも明示的に無効にしないかぎりは自動的に有効になります。

-XX:+UseParallelOldGC

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

-XX:+UseSerialGC

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

-XX:+UseSHM

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

ラージ・ページの設定は、「ラージ・ページ」を参照してください。

-XX:+UseStringDeduplication

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

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

-XX:+UseTLAB

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

非推奨のjavaオプション

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

-Xloggc:filename

ロギングのため、詳細GCイベント情報をリダイレクトするファイルを設定します。このファイルに書き込まれる情報は、ロギングされた各イベントの前の最初のGCイベントから経過した時間での-verbose:gcの出力と似ています。同じjavaコマンドで両方が指定された場合に、-Xloggcオプションは、-verbose:gcをオーバーライドします。

例:

-Xlog:gc:garbage-collection.log
-XX:CMSInitiatingOccupancyFraction=percent

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

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

-XX:CMSInitiatingOccupancyFraction=20
-XX:CMSInitiatingPermOccupancyFraction=percent

GCを起動するPermanent世代の占有率(0から100)を設定します。このオプションは置換えなくJDK 8で非推奨になりました。

-XX:+PrintStringDeduplicationStatistics

詳細な重複除外統計を出力しました。デフォルトでは、このオプションは無効になっています。-XX:+UseStringDeduplicationオプションを参照してください。

-XX:+PrintTenuringDistribution

殿堂入りの年齢情報の出力を有効にします。次に、出力の例を示します。

Desired survivor size 48286924 bytes, new threshold 10 (max 10)
- age 1: 28992024 bytes, 28992024 total
- age 2: 1366864 bytes, 30358888 total
- age 3: 1425912 bytes, 31784800 total
...

年齢1のオブジェクトはもっとも若いSurvivorです(それらは前回の清掃後に作成されたもの、最後の清掃で残ったもの、EdenからSurvivor領域に移動されたものです)。年齢2のオブジェクトは2回の清掃で残ったものです(2回目の清掃で、それらはあるSurvivor領域から次の領域にコピーされました)。このパターンは、出力のすべてのオブジェクトについて繰り返されます。

前の例で、28,992,024バイトが1回の清掃で残り、EdenからSurvivor領域にコピーされ、1,366,864バイトが年齢2のオブジェクトで占有されているというようになります。各行の3番目の値は年齢n以下のオブジェクトの累積サイズです。

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

-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:+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ガベージ・コレクタは、非推奨になりました。

-XX:+UseParNewGC

Young世代のコレクションにパラレル・スレッドの使用を有効にします。デフォルトでは、このオプションは無効になっています。-XX:+UseConcMarkSweepGCオプションを設定すると、自動的に有効になります。-XX:+UseConcMarkSweepGCオプションを使用せずに-XX:+UseParNewGCオプションを使用することは、JDK 8で非推奨になりました。-XX:+UseParNewGCオプションの使用はすべて非推奨になりました。-XX:+UseConcMarkSweepGCを指定しないでオプションを使用することはできません。

-XX:+UseSplitVerifier

検証プロセスの分割を有効にします。デフォルトで、このオプションは前のリリースで有効にされており、検証は型参照(コンパイラによって実行)と型チェック(JVMランタイムによって実行)の2つのフェーズに分割されていました。検証はデフォルトで分割されるようになり、無効にする方法はありません。

廃止されたjavaオプション

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

-XX:+AggressiveOpts

将来のリリースでデフォルトになることが予想される積極的なパフォーマンス最適化機能の使用を有効にします。デフォルトでは、このオプションは無効になっており、試験的パフォーマンス機能は使用されません。

-XX:+CheckEndorsedAndExtDirs

次のディレクトリのいずれかが存在し、空でない場合に、javaコマンドがJavaアプリケーションを実行できないようにするオプションを有効にしました。

  • lib/endorsed

  • lib/ext

  • プラットフォーム固有のシステム全体の拡張ディレクトリ

推奨規格優先メカニズムおよび拡張メカニズムはサポートされなくなりました。

-XX:MaxPermSize=size

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

-XX:PermSize=size

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

-XX:+UseAppCDS

アプリケーション・クラスまたはプラットフォーム・クラスがクラス・リストに存在し、共有アーカイブが-Xshare:dump/auto/onを使用して生成されている場合、非システム・クラスのアーカイブと共有のサポートが自動的に有効化されるようになりました。次のカスタマイズされた警告メッセージが発行されます(これは、廃止フラグ用の標準の警告とは若干異なります)。

Java HotSpot(TM) 64-Bit Server VM warning: Ignoring obsolete option UseAppCDS; AppCDS is automatically enabled

削除されたjavaオプション

これらのjavaオプションはJDK 11で削除されており、使用すると次のエラーになります。
Unrecognized VM option option-name
-XX:+ResourceManagement

サポートされなくなりました。アプリケーションの実行中にリソース管理の使用を有効にしました。

-XX:ResourceManagementSampleInterval=value_in_milliseconds

サポートされなくなりました。ミリ秒単位でリソース管理測定のサンプリング間隔を制御するパラメータを設定しました。

リソース管理が有効な場合のみ(つまり、-XX:+ResourceManagementオプションが指定されている場合)、このオプションが使用されました。

javaのコマンド行引数ファイル

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

コマンド行で、アット記号(@)接頭辞を使用してjavaオプションとクラス名が含まれる引数ファイルを指定します。javaコマンドは、アット記号(@)で始まるファイルを見つけると、コマンド行で指定されるようにそのファイルの内容を展開して引数リストに挿入します。

javaランチャは、-Xdisable-@filesオプションを見つけるまで引数ファイルの内容を展開します。-Xdisable-@filesオプションは、引数ファイル内を含めコマンド行の任意の場所で使用して、@argument_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行が連結されます。先頭の空白が切り捨てられないようにするには、継続文字(\)を1列目に入れます。

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

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

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

  • このようなリストでは、ワイルドカード(*)は使用できません(たとえば、*.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を省略すると、デフォルトでuptimelevelおよびtagsになります。「デコレーション」を参照してください。

output-options

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

説明

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

-Xlogコマンドとオプションの構文についてのクイック・リファレンスを次に示します。

-Xlog

infoレベルでのJVMロギングを有効にします。

-Xlog:help

-Xlog使用構文と使用可能なタグ、レベルおよびデコレータの他、説明付きのコマンド行の例を出力します。

-Xlog:disable

すべてのロギングをオフにし、警告およびエラーに関するデフォルト構成を含め、ロギング・フレームワークのすべての構成をクリアします。

-Xlog[:option]

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

optionは、次のように設定します。
[tag selection][:[output][:[decorators][:output-options]]]

tag selectionを省略すると、デフォルトでallタグ・セットとinfoレベルになります。

tag[+...] all

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

output_optionsは次のとおりです
filecount=file-count filesize=file size with optional K, M or G suffix

デフォルトの構成

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

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

実行時のロギングの制御

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

-Xlogのタグおよびレベル

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

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

  • trace

  • debug

  • info

  • warning

  • error

使用可能なログ・タグ:
使用可能なログ・タグは、次のとおりです。タグの組合せのかわりにallを指定すると、すべてのタグの組合せと一致します。
  • add

  • age

  • alloc

  • annotation

  • aot

  • arguments

  • attach

  • barrier

  • biasedlocking

  • blocks

  • bot

  • breakpoint

  • bytecode

  • census

  • class

  • classhisto

  • cleanup

  • compaction

  • comparator

  • constraints

  • constantpool

  • coops

  • cpu

  • cset

  • data

  • defaultmethods

  • dump

  • ergo

  • event

  • exceptions

  • exit

  • fingerprint

  • freelist

  • gc

  • hashtables

  • heap

  • humongous

  • ihop

  • iklass

  • init

  • itables

  • jfr

  • jni

  • jvmti

  • liveness

  • load

  • loader

  • logging

  • mark

  • marking

  • metadata

  • metaspace

  • method

  • mmu

  • modules

  • monitorinflation

  • monitormismatch

  • nmethod

  • normalize

  • objecttagging

  • obsolete

  • oopmap

  • os

  • pagesize

  • parser

  • patch

  • path

  • phases

  • plab

  • preorder

  • promotion

  • protectiondomain

  • purge

  • redefine

  • ref

  • refine

  • region

  • remset

  • resolve

  • safepoint

  • scavenge

  • scrub

  • setting

  • stackmap

  • stacktrace

  • stackwalk

  • start

  • startuptime

  • state

  • stats

  • stringdedup

  • stringtable

  • subclass

  • survivor

  • sweep

  • system

  • task

  • thread

  • time

  • timer

  • tlab

  • unload

  • update

  • verification

  • verify

  • vmoperation

  • vtables

  • workgang

次の表に、使用可能なタグの組合せのリストをログ・レベルとともに示します。

ログ・タグ 説明
-Xlog:gc gc情報をガベージ・コレクションが発生した時間とともに出力します。
-Xlog:gc*

少なくともgcタグを含むログ・メッセージを出力します。これに関連するその他のタグが含まれることもあります。ただし、phaseレベルの情報は提供されません。

-Xlog:gc*=trace 最下位レベルのgcログ情報を出力します。出力にはすべてのgc関連のタグと詳細なログ情報が表示されます。
-Xlog:gc+phases=debug

様々なphaseレベルの情報を出力します。これにより、debugレベルでログに記録された詳細レベルの情報が提供されます。

-Xlog:gc+heap=debug

gcの前後のheap使用状況の詳細を出力します。これは、gcおよびheapでタグ付けされたメッセージをdebugレベルでログに記録します。

-Xlog:safepoint

同じレベルでアプリケーションの同時実行時間とアプリケーションの停止時間の詳細を出力します。

-Xlog:gc+ergo*=trace

gcおよびergoメッセージの両方の組合せをtraceレベルで出力します。この情報には、ヒープのサイズ設定とコレクション・セットの構成に関するすべての詳細が含まれます。

-Xlog:gc+age=trace

traceレベルでサバイバ領域の残存オブジェクトのサバイバのサイズおよびageの分布を出力します。

-Xlog:gc*:file=<file>::filecount=<count>,filesize=<filesize in kb> 出力をファイルにリダイレクトし、使用するファイルの数とサイズをkb単位で示します。

-Xlogの出力

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

  • stdout — 出力をstdoutに送信します

  • stderr — 出力をstderrに送信します

  • file=filename — 出力をテキスト・ファイルに送信します。

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

デコレーション

ロギング・メッセージは、メッセージに関する情報でデコレーションされます。デコレータのカスタム・セットを使用するように各出力を構成できます。出力の順序は常に、表に示される順序と同じです。実行時に使用されるようにデコレーションを構成できます。デコレーションは、ログ・メッセージの先頭に付けられます。例:
[6.567s][info][gc,old] Old collection complete

decoratorsを省略すると、デフォルトでuptimelevelおよび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のように指定することができます。

表2-1 可能なロギング・メッセージのデコレーション

デコレーション 説明
timeまたはt

ISO-8601形式の現在の日付と時刻。

utctimeまたはutc

協定世界時。

uptimeまたはu

JVMが起動してからの時間(秒およびミリ秒)。例: 6.567s。

timemillisまたはtm

System.currentTimeMillis()によって生成されるのと同じ値。

uptimemillisまたはum

JVMが起動してからのミリ秒数。

timenanosまたはtn

System.nanoTime()によって生成されるのと同じ値。

uptimenanosまたはun

JVMが起動してからのナノ秒数。

hostnameまたはhn

ホスト名。

pidまたはp

プロセス識別子。

tidまたはti

スレッド識別子。

levelまたはl

ログ・メッセージに関連付けられたレベル。

tagsまたはtg

ログ・メッセージに関連付けられたタグ・セット。

XlogへのGCロギング・フラグの変換

表2-2 従来のガベージ・コレクションのロギング・フラグとXlog構成とのマッピング

従来のガーベジ・コレクション(GC)のフラグ Xlog構成 説明
G1PrintHeapRegions

-Xlog:gc+region=trace

なし

GCLogFileSize

使用可能な構成はありません

ログ・ローテーションはフレームワークによって処理されます。
NumberOfGCLogFiles

なし

ログ・ローテーションはフレームワークによって処理されます。
PrintAdaptiveSizePolicy

-Xlog:gc+ergo*=level

ほとんどの情報にdebuglevelを使用するか、PrintAdaptiveSizePolicyについて記録されたすべての情報にtracelevelを使用します。

PrintGC

-Xlog:gc

なし

PrintGCApplicationConcurrentTime

-Xlog:safepoint

PrintGCApplicationConcurrentTimeおよびPrintGCApplicationStoppedTimeは、同じタグで記録されるため、新しいロギングでは分けられません。

PrintGCApplicationStoppedTime

-Xlog:safepoint

PrintGCApplicationConcurrentTimeおよびPrintGCApplicationStoppedTimeは、同じタグで記録されるため、新しいロギングでは分けられません。

PrintGCCause

なし

GCの原因は常に記録されるようになりました。
PrintGCDateStamps

なし

データ・スタンプはフレームワークによって記録されます。

PrintGCDetails

-Xlog:gc*

なし

PrintGCID

なし

GC IDは常に記録されるようになりました。

PrintGCTaskTimeStamps

-Xlog:gc+task*=debug

なし

PrintGCTimeStamps

なし

タイム・スタンプはフレームワークによって記録されます。

PrintHeapAtGC

-Xlog:gc+heap=trace

なし

PrintReferenceGC

-Xlog:gc+ref*=debug

古いロギングでは、PrintReferenceGCが有効なのはPrintGCDetailsも有効になっている場合のみでした。

PrintStringDeduplicationStatistics

-Xlog:gc+stringdedup*=debug

なし

PrintTenuringDistribution

-Xlog:gc+age*=level

ほとんどの関連情報にdebuglevelを使用するか、PrintTenuringDistributionについて記録されたすべての情報にtracelevelを使用します。

UseGCLogFileRotation

なし

PrintTenuringDistributionについて記録された情報。

Xlogへのランタイム・ロギング・フラグの変換

表2-3 ランタイム・ロギング・フラグとXlog構成とのマッピング

従来のランタイム・フラグ Xlog構成 説明
TraceExceptions

-Xlog:exceptions=info

なし

TraceClassLoading

-Xlog:class+load=level

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

TraceClassLoadingPreorder

-Xlog:class+preorder=debug

なし

TraceClassUnloading

-Xlog:class+unload=level

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

VerboseVerification

-Xlog:verification=info

なし

TraceClassPaths

-Xlog:class+path=info

なし

TraceClassResolution

-Xlog:class+resolve=debug

なし

TraceClassInitialization

-Xlog:class+init=info

なし

TraceLoaderConstraints

-Xlog:class+loader+constraints=info

なし

TraceClassLoaderData

-Xlog:class+loader+data=level

通常の情報にlevel=debugを使用するか、追加の情報にlevel=traceを使用します。

TraceSafepointCleanupTime

-Xlog:safepoint+cleanup=info

なし

TraceSafepoint

-Xlog:safepoint=debug

なし

TraceMonitorInflation

-Xlog:monitorinflation=debug

なし

TraceBiasedLocking

-Xlog:biasedlocking=level

通常の情報にlevel=infoを使用するか、追加の情報にlevel=traceを使用します。

TraceRedefineClasses

-Xlog:redefine+class*=level

level=infolevel=debugおよびlevel=traceを使用して、情報の増加量を示します。

-Xlogの使用例

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

-Xlog

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

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

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

-Xlog:gc,safepoint

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

-Xlog:gc+ref=debug

gcrefの両方のタグでタグ付けされたメッセージを、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でタグ付けされたメッセージのロギングをオフにします。gcsafepointの両方でタグ付けされたメッセージは記録されません。

-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でタグ付けされたメッセージはすべてオフにします。gcmetaおよび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仮想マシンのフラグ引数の検証

検証対象のすべてのJava仮想マシン(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 Server 2003では、ラージ・ページをサポートします。

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

Oracle Solaris 9以降には、Multiple Page Size Support (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.localsysctl.confなど)で設定することをお薦めします。

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

    • Javaヒープ

    • コード・キャッシュ

    • パラレルGCのマーキング・ビットマップ・データ構造

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

Windows Server 2003でのラージ・ページのサポート

Windows Server 2003のみ、ラージ・ページをサポートします。この機能を使用するには、管理者は最初に追加の権限をアプリケーションを実行するユーザーに割り当てる必要があります。

  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が製品フラグになりました。すべての構成で、SharedArchiveFile+UnlockDiagnosticVMOptionsを指定する必要はなくなりました。

クラス・データ共有(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オプションと組み合せて使用する方法について説明しています。

オプション -Xshare:dump -Xshare:{on,auto}
--module-path1 mp 使用可能 使用可能2
--module 使用可能 使用可能
--add-module 使用可能 使用可能
--upgrade-module-path3 使用不可(指定した場合は終了します) 使用可能(CDSを無効化します)
--patch-module4 使用不可(指定した場合は終了します) 使用可能(CDSを無効化します)
--limit-modules5 使用不可(指定した場合は終了します) 使用可能(CDSを無効化します)

1--module-pathでモジュールを指定する方法は2通り(モジュラJARまたは展開したモジュール)ありますが、モジュラJARのみがサポートされています。

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

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

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

5--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のアーカイブ済のクラスは実行時に使用されません。

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

次のステップで、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

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

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

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

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の内部シンボル表および内部文字列表に追加されることがあります。実行時に、アーカイブ・ファイルからマップされたシンボルまたは文字列オブジェクトを、複数のJVMプロセスをまたいで共有できることで、結果として、全体的なメモリー使用量が削減されます。さらに、文字列をアーカイブすることで、起動時と実行時の両方において、パフォーマンス上の利点がもたらされます。

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

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

次に、jcmdでシンボルをダンプするコマンドの例を示します。 

jcmd pid VM.symboltable -verbose

注意:

このjcmd出力の1行目(プロセス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 -Xms26g Xmx26g -XX:MaxGCPauseMillis=500 -XX:+PrintGCTimeStamp

小さいJavaヒープの維持と埋込みアプリケーションの動的フットプリントの削減

次の拡張ランタイム・オプションを使用して、小さいJavaヒープを維持し、埋込みアプリケーションの動的フットプリントを削減します。

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

注意:

この2つのオプションのデフォルトは、それぞれ70%と40%です。これらの小さい設定を使用した場合にパフォーマンスが犠牲になる可能性があるため、許容できないパフォーマンス低下を招かないように可能なかぎりこれらの設定を減らすことで、小さいフットプリントのために最適化する必要があります。

終了ステータス

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

  • 0: 正常終了

  • >0: エラー発生