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...]
-
オプション:
mainclass
、source-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の値は、6
、7
、8
、9
、10
および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
から始まります。
-
javaの拡張ランタイム・オプション: Java HotSpot VMのランタイム動作を制御します。
-
javaの拡張JITコンパイラ・オプション: Java HotSpot VMによって実行されるJust-in-Time (JIT)動的コンパイルを制御します。
-
javaの拡張保守性オプション: システム情報の収集および詳細デバッグの実行を有効にします。
-
javaの拡張ガベージ・コレクション・オプション: Java HotSpotによってガベージ・コレクション(GC)がどのように実行されるかを制御します
ブール・オプションは、デフォルトで無効にされている機能を有効にするか、デフォルトで有効にされている機能を無効にするために使用します。このようなオプションはパラメータを必要としません。ブール-XX
オプションは、プラス記号を使用して有効にし(-XX:+OptionName
)、マイナス記号を使用して無効にします(-XX:-OptionName
)。
引数を必要とするオプションの場合、引数とオプション名はスペース、コロン(:)または等号(=)で区切るか、またはオプションの後に直接引数を続けることもできます(正確な構文はオプションごとに異なります)。バイト単位のサイズを指定する必要がある場合は、接尾辞を使用しないか、またはキロバイト(KB)の場合には接尾辞k
またはK
、メガバイト(MB)の場合にはm
またはM
、ギガバイト(GB)の場合にはg
またはG
を使用できます。たとえば、サイズを8Gバイトに設定するには、引数として、8g
、8192m
、8388608k
または8589934592
と指定できます。パーセンテージを指定する必要がある場合は、0から1までの数値を使用します。たとえば、25%の場合は0.25
と指定します。
次の各項では、廃止、非推奨および削除されたオプションについて説明します。
-
非推奨のjavaオプション: 使用でき、処理されます - 使用すると警告が発行されます。
-
廃止されたjavaオプション: 使用できますが、無視されます - 使用すると警告が発行されます。
-
削除されたjavaオプション: 削除されました - 使用するとエラーになります。
javaの標準オプション
これらは、JVMのすべての実装でサポートされる最も一般的に使用されるオプションです。
ノート:
長形式のオプションの引数を指定するには、--name=value
または--name value
を使用できます。
-
-agentlib:libname[=options]
-
指定したネイティブ・エージェント・ライブラリをロードします。ライブラリ名の後に、ライブラリに固有のオプションのカンマ区切りのリストを使用できます。
-
Oracle Solaris、LinuxおよびmacOS: オプション
-agentlib:foo
が指定された場合、JVMはlibfoo.so
という名前のライブラリを、LD_LIBRARY_PATH
システム変数(macOSではこの変数はDYLD_LIBRARY_PATH
)で指定された場所にロードしようとします。 -
Windows: オプション
-agentlib:foo
が指定された場合、JVMはfoo.dll
という名前のライブラリを、PATH
システム変数で指定された場所にロードしようとします。次の例では、ava Debug Wire Protocol (JDWP)ライブラリをロードし、ポート8000でソケット接続をリスニングし、メイン・クラスのロード前にJVMを一時停止する方法を示しています。
-agentlib:jdwp=transport=dt_socket,server=y,address=8000
-
-
-agentpath:pathname[=options]
-
絶対パス名で指定されたネイティブ・エージェント・ライブラリをロードします。このオプションは
-agentlib
と同等ですが、ライブラリのフル・パスとファイル名を使用します。 -
--class-path classpath
、-classpath classpath
または-cp classpath
-
クラス・ファイルを検索するディレクトリ、JARアーカイブおよびZIPアーカイブのセミコロン(
;
)で区切られたリスト。classpath
を指定すると、CLASSPATH
環境変数の設定がオーバーライドされます。classpathオプションを使用せず、classpath
を設定していない場合、ユーザー・クラス・パスは現在のディレクトリ(.)になります。便宜上、アスタリスク(*)のベース名を含むクラス・パス要素は、ディレクトリ内の拡張子
.jar
または.JAR
を持つすべてのファイルのリストを指定するのと同じと見なされます。Javaプログラムはこの2つの呼出しの違いを認識できません。たとえば、ディレクトリmydir
にa.jar
とb.JAR
が含まれている場合、クラス・パス要素mydir/*
はA.jar:b.JAR
に展開されますが、JARファイルの順番は決まっていません。このリストには、隠しファイルも含め、指定されたディレクトリ内のすべての.jar
ファイルが含まれます。アスタリスク(*)からなるクラス・パス・エントリは、現在のディレクトリ内のすべてのjarファイルのリストに展開されます。CLASSPATH
環境変数(定義されているとき)も同様に展開されます。クラス・パスのワイルドカード展開は、Java VMの起動前に実行されます。System.getenv("CLASSPATH")
の呼出しなどによって環境を照会しないかぎり、Javaプログラムが展開されていないワイルドカードを認識することはありません。 -
--disable-@files
-
引数ファイル内を含めコマンド行の任意の場所で使用して、
@filename
がそれ以上展開されないようにすることができます。このオプションは、オプションの後にある@
-argfilesを展開できないようにします。 -
--enable-preview
-
クラスがリリースのプレビュー機能に依存できるようにします。
-
--module-path modulepath...
または-p modulepath
-
ディレクトリのセミコロン(
;
)区切りリスト(各ディレクトリはモジュールのディレクトリです)。 -
--upgrade-module-path modulepath...
-
ディレクトリのセミコロン(
;
)区切りリスト(各ディレクトリは、ランタイム・イメージのアップグレード可能モジュールを置換するモジュールのディレクトリです)。 -
--add-modules module[,module...]
-
初期モジュールに加えて解決するルート・モジュールを指定します。また、
module
は、ALL-DEFAULT
、ALL-SYSTEM
およびALL-MODULE-PATH
のいずれかにすることもできます。 -
--list-modules
-
参照可能なモジュールをリストして終了します。
-
-d module name
または--describe-module module_name
-
指定されたモジュールの説明を表示して終了します。
-
--dry-run
-
VMを作成しますが、メイン・メソッドは実行しません。この
--dry-run
オプションは、モジュール・システム構成などのコマンド行オプションの検証に使用すると便利なことがあります。 -
--validate-modules
-
すべてのモジュールを検証して終了します。このオプションは、モジュール・パス上のモジュールで競合などのエラーを検出する場合に役立ちます。
-
-Dproperty=value
-
システム・プロパティの値を設定します。
property
変数はプロパティの名前を表す空白なしの文字列です。value
変数はプロパティの値を表す文字列です。value
が空白のある文字列の場合、それを引用符で囲みます(-Dfoo="foo bar"
など)。 -
-disableassertions[:[packagename]...|:classname]
または-da[:[packagename]...|:classname]
-
アサーションを無効にします。デフォルトでは、すべてのパッケージとクラスでアサーションは無効になっています。引数なしで、
-disableassertions
(-da
)は、すべてのパッケージとクラスでアサーションを無効にします。...
で終わるpackagename
引数を指定すると、スイッチは指定されたパッケージとサブパッケージ内でアサーションを無効にします。引数が...
のみの場合、スイッチは現在の作業ディレクトリにある名前のないパッケージ内でアサーションを無効にします。classname
引数を指定すると、スイッチは指定されたクラス内でアサーションを無効にします。-disableassertions
(-da
)オプションは、すべてのクラス・ローダーおよびシステム・クラス(クラス・ローダーを持たない)に適用されます。このルールには1つの例外があります。引数なしでオプションが指定された場合、システム・クラスには適用されません。これにより、システム・クラスを除くすべてのクラスでアサーションを簡単に無効にできます。-disablesystemassertions
オプションは、すべてのシステム・クラスでアサーションを無効にできます。特定のパッケージまたはクラスでアサーションを明示的に有効にするには、-enableassertions
(-ea
)オプションを使用します。両方のオプションを同時に使用することはできません。たとえば、com.wombat.fruitbat
パッケージ(およびすべてのサブパッケージ)内でアサーションを有効にし、com.wombat.fruitbat.Brickbat
クラス内では無効にして、MyClass
アプリケーションを実行するには、次のコマンドを使用します。java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat MyClass
-
-disablesystemassertions
または-dsa
-
すべてのシステム・クラス内でアサーションを無効にします。
-
-enableassertions[:[packagename]...|:classname]
または-ea[:[packagename]...|:classname]
-
アサーションを有効にします。デフォルトでは、すべてのパッケージとクラスでアサーションは無効になっています。引数なしで、
-enableassertions
(-ea
)は、すべてのパッケージとクラスでアサーションを有効にします。...
で終わるpackagename
引数を指定すると、スイッチは指定されたパッケージとすべてのサブパッケージ内でアサーションを有効にします。引数が...
のみの場合、スイッチは現在の作業ディレクトリにある名前のないパッケージ内でアサーションを有効にします。classname
引数を指定すると、スイッチは指定されたクラス内でアサーションを有効にします。-enableassertions
(-ea
)オプションは、すべてのクラス・ローダーおよびシステム・クラス(クラス・ローダーを持たない)に適用されます。このルールには1つの例外があります。引数なしでオプションが指定された場合、システム・クラスには適用されません。これにより、システム・クラスを除くすべてのクラスでアサーションを簡単に有効にできます。-enablesystemassertions
オプションは、すべてのシステム・クラスでアサーションを有効にするために個別のスイッチを提供します。特定のパッケージまたはクラスでアサーションを明示的に無効にするには、-disableassertions
(-da
)オプションを使用します。単一のコマンドにこれらのスイッチのインスタンスを複数指定した場合は、指定したスイッチが順番に処理されてからクラスがロードされます。たとえば、com.wombat.fruitbat
パッケージ(およびすべてのサブパッケージ)内でのみアサーションを有効にし、com.wombat.fruitbat.Brickbat
クラス内では無効にして、MyClass
アプリケーションを実行するには、次のコマンドを使用します。java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat MyClass
-
-enablesystemassertions
または-esa
-
すべてのシステム・クラス内でアサーションを有効にします。
-
-help
、-h
または-?
-
ヘルプ・メッセージをエラー・ストリームに出力します。
-
--help
-
ヘルプ・メッセージを出力ストリームに出力します。
-
-javaagent:jarpath[=options]
-
指定したJavaプログラミング言語エージェントをロードします。
-
--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の倍数で、1Mバイトより大きくなければなりません。キロバイトを指定するには文字
k
またはK
、メガバイトを指定するには文字m
またはM
、ギガバイトを指定するには文字g
またはG
を付けます。次の例では、様々な単位を使用して、割り当てられたメモリーのサイズを6MBに設定する方法を示します。-Xms6291456 -Xms6144k -Xms6m
このオプションを設定しない場合、初期サイズは、Old世代とYoung世代に割り当てられたサイズの合計として設定されます。Young世代のヒープの初期サイズは、-Xmn
オプションまたは-XX:NewSize
オプションを使用して設定できます。ノート:
-XX:InitalHeapSize
オプションを使用して、初期ヒープ・サイズを設定することもできます。コマンドラインで-Xms
の後に指定されている場合、初期ヒープ・サイズは-XX:InitalHeapSize
で指定された値に設定されます。 -
-Xmx size
-
メモリー割当てプールの最大サイズ(バイト単位)を指定します。この値は、1024の倍数で、2Mバイトより大きくなければなりません。キロバイトを指定するには文字
k
またはK
、メガバイトを指定するには文字m
またはM
、ギガバイトを指定するには文字g
またはG
を付けます。デフォルト値は、実行時にシステムの設定に基づいて選択されます。サーバー配備の場合、-Xms
と-Xmx
が同一の値に設定されていることがよくあります。次の例では、様々な単位を使用して、割り当てられたメモリーの最大許容サイズを80Mバイトに設定する方法を示します。-Xmx83886080 -Xmx81920k -Xmx80m
-Xmx
オプションは-XX:MaxHeapSize
と同等です。 -
-Xnoclassgc
-
クラスのガベージ・コレクション(GC)を無効にします。これによりいくらかのGC時間が節約され、アプリケーション実行時の割込みが短くなります。起動時に
-Xnoclassgc
を指定すると、GC時にアプリケーションのクラス・オブジェクトがそのままの状態にされ、常に有効であると見なされます。これにより、より多くのメモリーが永続的に占有されることになるため、慎重に使用しないと、メモリー不足の例外がスローされる可能性があります。 -
-Xrs
-
JVMによるオペレーティング・システム・シグナルの使用を減らします。シャットダウン・フックにより、JVMが突然終了した場合でも、シャットダウン時にユーザー・クリーン・アップ・コード(データベース接続のクローズなど)を実行して、Javaアプリケーションの正常なシャットダウンができるようになりました。
-
Oracle Solaris、LinuxおよびmacOS:
-
JVMは、シグナルをキャッチすることによって、異常終了のためのシャットダウン・フックを実装します。JVMは、
SIGHUP
、SIGINT
、およびSIGTERM
を使用して、シャットダウン・フックの実行を開始します。 -
JVMを埋め込んでいるアプリケーションが
SIGINT
やSIGTERM
などのシグナルを頻繁にトラップする必要があると、JVMのシグナル・ハンドラの処理に支障が出る可能性があります。-Xrs
オプションを使用すると、この問題に対処できます。-Xrs
を使用すると、SIGINT
、SIGTERM
、SIGHUP
およびSIGQUIT
に対するシグナル・マスクはJVMによって変更されず、これらのシグナルに対するシグナル・ハンドラはインストールされません。
-
-
Windows:
-
JVMは、コンソール制御イベントを監視して予期しない終了のシャットダウン・フックを実装します。具体的には、JVMは、シャットダウン・フック処理を開始するコンソール制御ハンドラを登録し、
CTRL_C_EVENT
、CTRL_CLOSE_EVENT
、CTRL_LOGOFF_EVENT
およびCTRL_SHUTDOWN_EVENT
に対してTRUE
を返します。 -
JVMは、デバッグ用のスレッド・スタックをダンプする機能を実現するためにも、同様のメカニズムを使用します。JVMは、スレッド・ダンプを実行するために
CTRL_BREAK_EVENT
を使用します。 -
JVMがサービス(Webサーバー用のサーブレット・エンジンなど)として実行されている場合、
CTRL_LOGOFF_EVENT
を受け取ることはできますが、オペレーティング・システムが実際にはプロセスを終了しないため、シャットダウンを開始しないでください。このような干渉の可能性を避けるため、-Xrs
オプションを使用できます。-Xrs
オプションを使用すると、JVMは、コンソール制御ハンドラをインストールしないため、CTRL_C_EVENT
、CTRL_CLOSE_EVENT
、CTRL_LOGOFF_EVENT
またはCTRL_SHUTDOWN_EVENT
の監視や処理を行わないことを意味します。
-
-Xrs
を指定した場合は、2つの影響があります。-
Oracle Solaris、LinuxおよびmacOS:
SIGQUIT
によるスレッド・ダンプは使用できません。 -
Windows: [Ctrl]+[Break]によるスレッド・ダンプは使用できません。
シャットダウン・フックの実行は、JVMが終了しようとしている時点で
System.exit()
を呼び出すなどして、ユーザー・コード側で行います。 -
-
-Xshare:mode
-
クラス・データ共有(CDS)モードを設定します。
このオプションの
mode
引数には次を指定できます。 -
-XshowSettings
-
すべての設定を表示してから、続行します。
-
-XshowSettings:category
-
設定を表示し、続行します。このオプションの
category
引数には次を指定できます。 -
-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
と似ています。 -
-
-Xverify
- バイトコード・ベリファイアのモードを設定します。
-
--add-reads module=target-module(,target-module)*
-
モジュール宣言に関係なく、
target-module
を読み取るようにmodule
を更新します。target-module
をALL-UNNAMEDにすると、名前のないモジュールをすべて読み取ることができます。 -
--add-exports module/package=target-module(,target-module)*
-
モジュール宣言に関係なく、
package
をtarget-module
にエクスポートするようにmodule
を更新します。target-module
をALL-UNNAMEDにすると、名前のないモジュールをすべてエクスポートできます。 -
--add-opens module/package=target-module(,target-module)*
-
モジュール宣言に関係なく、
package
をtarget-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専用です。
javaの拡張ランタイム・オプション
これらのjava
オプションはJava HotSpot VMのランタイム動作を制御します。
-
-XX:ActiveProcessorCount=x
-
ガベージ・コレクションやForkJoinPoolなどの様々な操作に使用するスレッド・プールのサイズを計算するために、VMが使用するCPUの数をオーバーライドします。
通常、VMはオペレーティング・システムから使用可能なプロセッサの数を決定します。このフラグは、Dockerコンテナ内で複数のJavaプロセスを実行するときに、CPUリソースをパーティション化するために役立ちます。
UseContainerSupport
が有効になっていない場合でも、このフラグが使用されます。コンテナのサポートの有効化および無効化の説明は、-XX:-UseContainerSupport
を参照してください。 -
--XX:AllocateHeapAt=path
-
ファイル・システムへのパスを取得し、メモリー・マッピングを使用してメモリー・デバイスにオブジェクト・ヒープを割り当てます。このオプションを使用すると、ユーザーが指定したNV-DIMMなどの代替メモリー・デバイスに、HotSpot VMがJavaオブジェクト・ヒープを割り当てられるようになります。
DRAMと同じセマンティクス(アトミック操作のセマンティクスを含む)を持つ代替メモリー・デバイスを、既存のアプリケーション・コードを変更せずに、オブジェクト・ヒープ用のDRAMのかわりに使用できます。他のメモリー構造体(コード・ヒープ、メタスペース、スレッド・スタックなど)はすべて、引き続きDRAM内に残ります。
一部のオペレーティング・システムでは、ファイル・システムを使用して非DRAMメモリーを公開します。これらのファイル・システムのメモリー・マップ・ファイルは、ページ・キャッシュをバイパスして、デバイスの物理メモリーに対する仮想メモリーのダイレクト・マッピングを提供します。既存のヒープ関連フラグ(
-Xmx
、-Xms
など)およびガベージ・コレクション関連フラグは、引き続き以前と同様に動作します。 -
-XX:-CompactStrings
-
コンパクト文字列機能を無効にします。デフォルトでは、このオプションが有効になっています。このオプションが有効になっていると、シングルバイト文字のみが含まれるJava文字列は、ISO-8859-1またはLatin-1エンコーディングを使用して1文字当たり1バイトの文字列として内部的に表され、格納されます。これにより、シングルバイト文字列のみが含まれる文字列に必要な容量が50%削減されます。1つ以上のマルチバイト文字が含まれるJava文字列の場合、これらはUTF-16エンコーディングを使用して1文字当たり2バイトとして表され、格納されます。コンパクト文字列機能を無効にすると、すべてのJava文字列に対してUTF-16エンコーディングを内部表現として使用することが強制されます。
コンパクト文字列を無効にした方が有益な場合は、次のとおりです。
-
アプリケーションで圧倒的にマルチバイト文字の文字列を割り当てることがわかっている場合
-
Java SE 8からJava SE 9以降への移行でパフォーマンス低下が観測され、コンパクト文字列がその低下を招いていることを分析が示している予期しないイベント
いずれのシナリオでも、コンパクト文字列を無効にすることが理にかなっています。
-
-
-XX:CompilerDirectivesFile=file
-
プログラムの起動時にディレクティブをファイルからディレクティブのスタックに追加します。コンパイラ・ディレクティブおよびコマンド行に関する項を参照してください。
-
-XX:CompilerDirectivesPrint
-
プログラムの起動時または新しいディレクティブの追加時にディレクティブのスタックを出力します。
-
-XX:ConcGCThreads=n
-
パラレル・マーキング・スレッド数を設定します。
n
をパラレル・ガベージ・コレクション・スレッド(ParallelGCThreads)の数の約1/4に設定します。 -
-XX:+DisableAttachMechanism
-
ツールをJVMに接続するメカニズムを無効にします。デフォルトでは、このオプションは無効になっており、アタッチ・メカニズムは有効になっているため、
jcmd
、jstack
、jmap
、jinfo
などの診断ツールおよびトラブルシューティング・ツールを使用できます。 -
-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引数には次を指定できます。
-
-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.Object
とhello.Main
を指定するには、次の2行を含むテキスト・ファイルを作成します。java/lang/Object hello/Main
このテキスト・ファイルで指定するクラスには、アプリケーションでよく使用されるクラスを含める必要があります。アプリケーション、機能拡張またはブートストラップ・クラス・パスからのあらゆるクラスが含まれる場合があります。
「アプリケーション・クラス・データ共有」を参照してください。
-
-XX:+ShowMessageBoxOnError
-
JVMで回復不能なエラーが発生した場合に、ダイアログ・ボックスの表示を有効にします。これにより、JVMの終了を回避し、プロセスをアクティブに維持するため、これにデバッガを接続して、エラーの原因を調査できます。デフォルトでは、このオプションは無効になっています。
-
-XX:StartFlightRecording=parameter=value
-
JavaアプリケーションのJFR記録を開始します。このオプションは、実行時に記録を開始する
JFR.start
診断コマンドと同等です。JFR記録を開始するときに、次のparameter=value
エントリを設定できます。-
delay=time
-
Javaアプリケーションの起動時間から記録を開始するまでの遅延時間を指定します。時間を秒で指定する場合は
s
、分の場合はm
、時間の場合はh
、日の場合はd
を追加します。たとえば、10m
と指定すると、10分を意味します。デフォルトでは、遅延はなく、このパラメータは0に設定されます。 -
disk={true|false}
-
一時データをディスク・リポジトリに書き込むかどうかを指定します。デフォルトでは、このパラメータは
false
に設定されています。有効にするには、パラメータをtrue
に設定します。 -
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では、新しい命令
XBEGIN
、XABORT
、XEND
およびXTEST
が導入されています。XBEGIN
およびXEND
命令は、トランザクションとして実行するための命令セットを囲みます。トランザクションの実行時に競合が見つからなかった場合、メモリーとレジスタの変更が、XEND
命令で同時にコミットされます。XABORT
命令ではトランザクションを明示的に中止でき、XEND
命令では命令セットがトランザクション内で実行中かどうかを確認できます。トランザクションのロックは、別のスレッドが同じトランザクションにアクセスしようとしたときに展開されます。したがって、そのトランザクションへのアクセスを当初リクエストしなかったスレッドはブロックされます。RTMでは、トランザクションが中止または失敗した場合のために、フォールバックの操作セットを指定する必要があります。RTMロックとは、TSXのシステムに委譲されているロックです。
RTMにより、重要なリージョンにおいて衝突が少なく競合度の高いロックのパフォーマンスが向上されます(これは、複数のスレッドによって同時にアクセスできないコードです)。また、RTMにより、粗粒度ロックのパフォーマンスも向上されますが、一般的にマルチスレッド・アプリケーションでのパフォーマンスはよくありません。(粗粒度ロックとは、ロックの取得および解放のオーバーヘッドを最小化するために長い期間ロックを保持する戦略であり、一方、細粒度ロックとは必要な場合のみロックし可能なかぎり早期にロック解除することで最大限の並行処理の達成を試みる戦略です。)さらに、異なるスレッドによって使用されている軽度な競合ロックの場合、RTMにより、誤ったキャッシュ・ライン共有(キャッシュ・ライン・ピンポンとも呼ばれる)を削減できます。これは、異なるプロセッサからの複数のスレッドが異なるリソースにアクセスしている場合に発生しますが、リソースは同じキャッシュ・ラインを共有します。結果として、プロセッサは他のプロセッサのキャッシュ・ラインを繰り返し無効にし、これにより、キャッシュではなくメイン・メモリーからの読取りが強制されます。
-
-XX:+UseSHA
-
SPARCハードウェアのSHA暗号化ハッシュ関数のハードウェアベースの組込みを有効にします。
UseSHA
オプションは、UseSHA1Intrinsics
、UseSHA256Intrinsics
およびUseSHA512Intrinsics
オプションと組み合せて使用します。UseSHA
およびUseSHA*Intrinsics
フラグはデフォルトで有効であり、SPARC T4以上のJava HotSpot Server VM 64ビットでのみサポートされます。SHA操作に対して
sun.security.provider.Sun
プロバイダを使用する場合のみ、この機能を適用できます。組込みを制御するフラグには、オプション-XX:+UnlockDiagnosticVMOptions
が必要になりました。すべてのハードウェアベースのSHA組込みを無効にするには、
-XX:-UseSHA
を指定します。特定のSHA組込みのみ無効化するには、適切な対応するオプションを使用してください。たとえば:-XX:-UseSHA256Intrinsics
。 -
-XX:+UseSHA1Intrinsics
-
SHA-1暗号化ハッシュ関数の組込みを有効にします。組込みを制御するフラグには、オプション
-XX:+UnlockDiagnosticVMOptions
が必要になりました。 -
-XX:+UseSHA256Intrinsics
-
SHA-224およびSHA-256暗号化ハッシュ関数の組込みを有効にします。組込みを制御するフラグには、オプション
-XX:+UnlockDiagnosticVMOptions
が必要になりました。 -
-XX:+UseSHA512Intrinsics
-
SHA-384およびSHA-512暗号化ハッシュ関数の組込みを有効にします。組込みを制御するフラグには、オプション
-XX:+UnlockDiagnosticVMOptions
が必要になりました。 -
-XX:+UseSuperWord
-
スカラー操作のスーパーワード操作への変換を有効にします。スーパーワードとは、ベクトル化最適化です。このオプションはデフォルトで有効化されています。スカラー操作のスーパーワード操作への変換を無効にするには、
-XX:-UseSuperWord
を指定します。Java HotSpot Server VMのみが、このオプションをサポートしています。
javaの拡張保守性オプション
これらのjava
オプションは、システム情報を収集し、詳細デバッグを実行する機能を提供します。
-
-XX:+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
を付けます。デフォルト値は、システム構成に基づいて実行時に選択されます。『Java SE HotSpot仮想マシン・ガベージ・コレクション・チューニング・ガイド 』のエルゴノミクスを参照してください。次の例では、様々な単位を使用して、割り当てられたメモリーのサイズを6Mバイトに設定する方法を示します。
-XX:InitialHeapSize=6291456 -XX:InitialHeapSize=6144k -XX:InitialHeapSize=6m
このオプションを0に設定した場合、初期サイズは、Old世代とYoung世代に割り当てられたサイズの合計として設定されます。Young世代のヒープのサイズは、-XX:NewSize
オプションを使用して、設定できます。ノート:
-Xms
オプションでは、ヒープの最小ヒープ・サイズと初期ヒープ・サイズの両方を設定します。コマンドラインで-XX:InitialHeapSize
の後に-Xms
が指定されている場合、初期ヒープ・サイズは-Xms
で指定された値に設定されます。 -
-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
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
コード・ヒープの状態の分析
-
JITがオン/オフを何度も繰り返したのはなぜか。
-
すべてのコード・ヒープ領域はどこに行ってしまったのか。
-
メソッド・スイーパが効果的に機能しないのはなぜか。
これを把握するため、コード・ヒープのオンザフライ分析を可能にするコード・ヒープの状態の分析機能が実装されました。分析プロセスは2つのパートに分かれています。最初のパートでは、コード・ヒープ全体を調べて、有用または重要と判断されたすべての情報が集約されます。2番目のパートは複数の独立したステップで構成されており、収集された情報がデータの様々な側面に重点を置いて出力されます。データの収集と出力は、「リクエスト」ベースで実行されます。
構文
jcmd pid Compiler.CodeHeap_Analytics [function] [granularity]
-Xlog:codecache=Trace
-Xlog:codecache=Debug
コード・ヒープの状態の分析機能、サポートされている関数および粒度オプションの詳細は、『CodeHeap State Analytics (OpenJDK)』を参照してください。
JVM統合ロギングフレームワークを使用したロギングの有効化
-Xlog
オプションを使用してJava仮想マシン(JVM)統合ロギング・フレームワークを使用したロギングを構成または有効にします。
形式
-Xlog[:[what][:[output][:[decorators][:output-options[,...]]]]]
-
what
-
タグとレベルの組合せを形式
tag1
[+tag2
...][*
][=level
][,...]で指定します。ワイルドカード(*
)が指定されている場合を除き、指定されたとおりのタグでタグ付けされたログ・メッセージのみが照合されます。「-Xlogのタグおよびレベル」を参照してください。 -
output
-
出力のタイプを設定します。
output
を省略すると、タイプはデフォルトでstdout
になります。「-Xlogの出力」を参照してください。 -
decorators
-
カスタムのデコレータ・セットを使用するように出力を構成します。
decorators
を省略すると、デフォルトでuptime
、level
およびtags
になります。「デコレーション」を参照してください。 -
output-options
-
-Xlog
ロギング出力オプションを設定します。
説明
Java仮想マシン(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*
|
少なくとも |
-Xlog:gc*=trace
|
最下位レベルのgc ログ情報を出力します。出力にはすべてのgc 関連のタグと詳細なログ情報が表示されます。
|
-Xlog:gc+phases=debug
|
様々な |
-Xlog:gc+heap=debug
|
|
-Xlog:safepoint
|
同じレベルでアプリケーションの同時実行時間とアプリケーションの停止時間の詳細を出力します。 |
-Xlog:gc+ergo*=trace
|
|
-Xlog:gc+age=trace |
|
-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
を省略すると、デフォルトでuptime
、level
およびtags
になります。none
デコレータは特殊で、すべてのデコレーションをオフにする場合に使用します。
time
(t
)、utctime
(utc
)、uptime
(u
)、timemillis
(tm
)、uptimemillis
(um
)、timenanos
(tn
)、uptimenanos
(un
)、hostname
(hn
)、pid
(p
)、tid
(ti
)、level
(l
)、tags
(tg
)の各デコレータも、デコレーションなしのnone
のように指定することができます。
表2-1 可能なロギング・メッセージのデコレーション
デコレーション | 説明 |
---|---|
time またはt |
ISO-8601形式の現在の日付と時刻。 |
utctime またはutc |
協定世界時。 |
uptime またはu |
JVMが起動してからの時間(秒およびミリ秒)。たとえば、6.567s。 |
timemillis またはtm |
|
uptimemillis またはum |
JVMが起動してからのミリ秒数。 |
timenanos またはtn |
|
uptimenanos またはun |
JVMが起動してからのナノ秒数。 |
hostname またはhn |
ホスト名。 |
pid またはp |
プロセス識別子。 |
tid またはti |
スレッド識別子。 |
level またはl |
ログ・メッセージに関連付けられたレベル。 |
tags またはtg |
ログ・メッセージに関連付けられたタグ・セット。 |
XlogへのGCロギング・フラグの変換
表2-2 従来のガベージ・コレクションのロギング・フラグとXlog構成とのマッピング
従来のガーベジ・コレクション(GC)のフラグ | Xlog構成 | 説明 |
---|---|---|
G1PrintHeapRegions |
|
なし |
GCLogFileSize |
使用可能な構成はありません |
ログ・ローテーションはフレームワークによって処理されます。 |
NumberOfGCLogFiles |
なし |
ログ・ローテーションはフレームワークによって処理されます。 |
PrintAdaptiveSizePolicy |
|
ほとんどの情報に |
PrintGC |
|
なし |
PrintGCApplicationConcurrentTime |
|
|
PrintGCApplicationStoppedTime |
|
|
PrintGCCause |
なし |
GCの原因は常に記録されるようになりました。 |
PrintGCDateStamps |
なし |
データ・スタンプはフレームワークによって記録されます。 |
PrintGCDetails |
|
なし |
PrintGCID |
なし |
GC IDは常に記録されるようになりました。 |
PrintGCTaskTimeStamps |
|
なし |
PrintGCTimeStamps |
なし |
タイム・スタンプはフレームワークによって記録されます。 |
PrintHeapAtGC |
|
なし |
PrintReferenceGC |
|
古いロギングでは、 |
PrintStringDeduplicationStatistics |
|
なし |
PrintTenuringDistribution |
|
ほとんどの関連情報に |
UseGCLogFileRotation |
なし |
|
Xlogへのランタイム・ロギング・フラグの変換
表2-3 ランタイム・ロギング・フラグとXlog構成とのマッピング
従来のランタイム・フラグ | Xlog構成 | 説明 |
---|---|---|
TraceExceptions |
|
なし |
TraceClassLoading |
|
通常の情報に |
TraceClassLoadingPreorder |
|
なし |
TraceClassUnloading |
|
通常の情報に |
VerboseVerification |
|
なし |
TraceClassPaths |
|
なし |
TraceClassResolution |
|
なし |
TraceClassInitialization |
|
なし |
TraceLoaderConstraints |
|
なし |
TraceClassLoaderData |
|
通常の情報に |
TraceSafepointCleanupTime |
|
なし |
TraceSafepoint |
|
なし |
TraceMonitorInflation |
|
なし |
TraceBiasedLocking |
|
通常の情報に |
TraceRedefineClasses |
|
|
-Xlogの使用例
次に、-Xlog
の例を示します。
-
-Xlog
-
すべてのメッセージを、
info
レベルを使用してuptime
、levels
およびtags
のデコレーションでstdout
に記録します。これは、次を使用するのと同等です。-Xlog:all=info:stdout:uptime,levels,tags
-
-Xlog:gc
-
gc
タグでタグ付けされたメッセージを、info
レベルを使用してstdout
に記録します。レベルwarning
の他のすべてのメッセージに対するデフォルトの構成は有効です。 -
-Xlog:gc,safepoint
-
gc
タグまたはsafepoint
タグのいずれかでタグ付けされたメッセージを、どちらもinfo
レベルを使用してデフォルトのデコレーションでstdout
に記録します。gc
とsafepoint
の両方でタグ付けされたメッセージは記録されません。 -
-Xlog:gc+ref=debug
-
gc
とref
の両方のタグでタグ付けされたメッセージを、debug
レベルを使用してデフォルトのデコレーションでstdout
に記録します。この2つのタグのいずれかのみでタグ付けされたメッセージは記録されません。 -
-Xlog:gc=debug:file=gc.txt:none
-
gc
タグでタグ付けされたメッセージを、debug
レベルを使用してデコレーションなしでgc.txt
と呼ばれるファイルに記録します。レベルwarning
の他のすべてのメッセージに対するデフォルトの構成は引き続き有効です。 -
-Xlog:gc=trace:file=gctrace.txt:uptimemillis,pids:filecount=5,filesize=1024
-
gc
タグでタグ付けされたメッセージを、trace
レベルを使用してローテーションするファイル・セット(サイズ1MBのファイルを5つ使用し、ベース名がgctrace.txt
)に記録し、デコレーションuptimemillis
およびpid
を使用します。レベル
warning
の他のすべてのメッセージに対するデフォルトの構成は引き続き有効です。 -
-Xlog:gc::uptime,tid
-
gc
タグでタグ付けされたメッセージをデフォルト・レベル'info'を使用してデフォルト出力stdout
に記録し、デコレーションuptime
およびtid
使用します。レベルwarning
の他のすべてのメッセージに対するデフォルトの構成は引き続き有効です。 -
-Xlog:gc*=info,safepoint*=off
-
info
レベルを使用して少なくともgc
でタグ付けされたメッセージを記録しますが、safepoint
でタグ付けされたメッセージのロギングをオフにします。gc
とsafepoint
の両方でタグ付けされたメッセージは記録されません。 -
-Xlog:disable -Xlog:safepoint=trace:safepointtrace.txt
-
警告およびエラーを含めてすべてのロギングをオフにした後、
safepoint
でタグ付けされたメッセージを、trace
レベルを使用してファイルsafepointtrace.txt
に対して有効にします。コマンド行が-Xlog:disable
で開始されているため、デフォルトの構成は適用されません。
複雑な-Xlogの使用例
-Xlog
オプションを使用した複雑な例をいくつか次に示します。
-
-Xlog:gc+class*=debug
-
少なくとも
gc
タグとclass
タグでタグ付けされたメッセージを、debug
レベルを使用してstdout
に記録します。レベルwarning
の他のすべてのメッセージに対するデフォルトの構成は引き続き有効です -
-Xlog:gc+meta*=trace,class*=off:file=gcmetatrace.txt
-
少なくとも
gc
タグおよびmeta
タグでタグ付けされたメッセージを、trace
レベルを使用してファイルmetatrace.txt
に記録しますが、class
でタグ付けされたメッセージはすべてオフにします。gc
、meta
およびclass
でタグ付けされたメッセージは、class*
がoffに設定されているため、記録されません。レベルwarning
の他のすべてのメッセージに対するデフォルトの構成は、class
が含まれるメッセージを除いて有効です。 -
-Xlog:gc+meta=trace
-
gc
およびmeta
に完全一致するタグでタグ付けされたメッセージを、trace
レベルを使用してstdout
に記録します。レベルwarning
の他のすべてのメッセージに対するデフォルトの構成は引き続き有効です。 -
-Xlog:gc+class+heap*=debug,meta*=warning,threads*=off
-
少なくとも
gc
タグ、class
タグおよびheap
タグでタグ付けされたメッセージを、trace
レベルを使用してstdout
に記録しますが、meta
でタグ付けされたメッセージのみwarningレベルを使用します。レベルwarning
の他のすべてのメッセージに対するデフォルトの構成は、threads
が含まれるメッセージを除いて有効です。
Java仮想マシンのフラグ引数の検証
検証対象のすべてのJava仮想マシン(JVM)コマンド行フラグに指定された値を使用していて、入力値が無効である場合または範囲外である場合は、適切なエラー・メッセージが表示されます。
java.lang.management
に含まれるクラスなど)のいずれを使用して人間工学に基づいて設定されていようと、すべてのJava仮想マシン(JVM)のコマンド行フラグに指定された値は検証されます。人間工学の詳細は、Java Platform, Standard Edition HotSpot仮想マシン・ガベージ・コレクション・チューニング・ガイドを参照してください。
範囲および制約は、すべてのフラグの値がJVMの初期化中に設定されたとき、またはフラグの値が実行時に(jcmd
ツールを使用するなどして)変更されたときに検証されます。値が範囲または制約チェックに違反した場合、JVMは終了し、該当するエラー・メッセージがエラー・ストリームに出力されます。
java -XX:AllocatePrefetchStyle=5 -version
intx AllocatePrefetchStyle=5 is outside the allowed range [ 0 ... 3 ]
Improperly specified VM option 'AllocatePrefetchStyle=5'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
フラグ-XX:+PrintFlagsRanges
は、すべてのフラグの範囲を出力します。このフラグを使用すると、範囲によって指定された値でフラグを自動的にテストすることが可能になります。範囲が指定されているフラグについて、型、名前および実際の範囲が出力されます。
intx ThreadStackSize [ 0 ... 9007199254740987 ] {pd product}
範囲が指定されていないフラグの場合は、値が出力に表示されません。たとえば、size_t NewSize [ ... ] {product}
これは、実装する必要があるフラグの特定に役立ちます。自動テスト・フレームワークでは、値がなく実装されないフラグをスキップできます。 ラージ・ページ
ヒュージ・ページとも呼ばれるラージ・ページは、標準のメモリー・ページ・サイズ(プロセッサおよびオペレーティング・システムによって異なります)よりはるかに大きいメモリー・ページとして使用します。ラージ・ページは、プロセッサのTranslation-Lookaside Bufferを最適化します。
Translation-Lookaside Buffer (TLB)は、最近使用された仮想から物理へのアドレス変換を保持するページ変換キャッシュです。TLBは、少ないシステム・リソースです。プロセッサが複数のメモリー・アクセスが必要な場合のある階層ページ表から読み取る必要があるため、TLBミスは負荷がかかる可能性があります。大きいメモリー・ページ・サイズを使用して、単一のTLBエントリで大きいメモリー範囲を表すことができます。これにより、TLB不足が少なくなり、メモリー集約型のアプリケーションのパフォーマンスが向上する可能性があります。
ただし、ラージ・ページのページ・メモリーは、システムのパフォーマンスに悪影響を与える場合があります。たとえば、大量のメモリーがアプリケーションで確保される場合、通常メモリー不足や他のアプリケーションの過剰なページングが発生し、システム全体が遅くなる可能性があります。また、長時間稼働しているシステムは、過剰な断片化が発生する可能性があります。これにより、十分な大きさのページ・メモリーを予約できない可能性があります。これが発生した場合、OSまたはJVMのいずれかが通常のページの使用に戻ります。
Oracle Solaris、LinuxおよびWindowsでは、ラージ・ページをサポートします。
Oracle Solarisでのラージ・ページのサポート
Oracle Solaris 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
としてログインして、次のステップを実行してください:
-
オプション
-XX:+UseSHM
(-XX:+UseHugeTLBFS
のかわり)を使用する場合、SHMMAX
値を増やしますJavaヒープ・サイズより大きくする必要があります。4GB以下の物理RAMを搭載するシステムでは、次によりすべてのメモリーが共有可能になります。# echo 4294967295 > /proc/sys/kernel/shmmax
-
オプション
-XX:+UseSHM
または-XX:+UseHugeTLBFS
を使用する場合、ラージ・ページの数を指定します。次の例では、4GBシステムの3GBがラージ・ページに予約されます(2048KBのラージ・ページ・サイズを仮定する場合、3GB = 3 * 1024MB = 3072MB = 3072 * 1024KB = 3145728KB and 3145728KB / 2048KB = 1536):# echo 1536 > /proc/sys/vm/nr_hugepages
ノート:
-
/proc
に含まれる値はシステムを再起動した後にリセットされるため、初期化スクリプト(rc.local
やsysctl.conf
など)で設定することをお薦めします。 -
OSカーネル・パラメータ
/proc/sys/kernel/shmmax
または/proc/sys/vm/nr_hugepages
を構成(またはサイズ変更)する場合、JavaプロセスがJavaヒープ以外の領域に対してラージ・ページを割り当てることがあります。これらのステップを使用して、次の領域に対してラージ・ページを割り当てることができます:-
Javaヒープ
-
コード・キャッシュ
-
パラレルGCのマーキング・ビットマップ・データ構造
その結果、Javaヒープのサイズに
nr_hugepages
パラメータを構成すると、領域のサイズが非常に大きいためにJVMがラージ・ページのコード・キャッシュ領域の割当てに失敗する場合があります。 -
Windowsでのラージ・ページのサポート
Windowsでラージ・ページ・サポートを使用するには、管理者が最初に追加の権限をアプリケーションを実行するユーザーに割り当てる必要があります。
-
「コントロール パネル」→「管理ツール」→「ローカル セキュリティ ポリシー」を選択します。
-
「ローカル ポリシー」を選択し、「ユーザー権利の割り当て」をクリックします。
-
「メモリ内のページのロック」をダブルクリックしてユーザーまたはグループを追加します。
-
システムを再起動します。
デフォルトでは、管理者はメモリー内のページをロックする権限がないため、アプリケーションを実行する管理者でもこれらのステップが必要であることに注意してください。
アプリケーション・クラス・データ共有
アプリケーション・クラス・データ共有(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
を指定する必要はなくなりました。
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-path 1 mp |
使用可能 | 使用可能2 |
--module |
使用可能 | 使用可能 |
--add-module |
使用可能 | 使用可能 |
--upgrade-module-path 3 |
使用不可(指定した場合は終了します) | 使用可能(CDSを無効化します) |
--patch-module 4 |
使用不可(指定した場合は終了します) | 使用可能(CDSを無効化します) |
--limit-modules 5 |
使用不可(指定した場合は終了します) | 使用可能(CDSを無効化します) |
1--module-path
でモジュールを指定する方法は2通り(モジュラJARまたは展開したモジュール)ありますが、モジュラJARのみがサポートされています。
2ダンプ時と実行時に異なるmp
を指定できます。たとえば、アーカイブ済のクラスKをダンプ時にmp1.jar
からロードしたが、mp
を変更して実行時に別のmp2.jar
からこのクラスを使用できるようにすると、アーカイブ・バージョンのKは実行時に無視されます。Kは動的にロードされます。
3現在、アップグレード可能なシステム・モジュールは2つ(java.compiler
とjdk.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
アプリケーションで使用されるすべてのクラスを含む共有アーカイブ・ファイルを作成します。最後のステップで、共有アーカイブ・ファイルを持つアプリケーションを実行します。
-
test.Hello
アプリケーションで使用されるすべてのクラスのリストを作成します。次のコマンドは、このアプリケーションで使用されるすべてのクラスのリストを含む、hello.classlist
という名前のファイルを作成します。java -Xshare:off -XX:DumpLoadedClassList=hello.classlist -cp hello.jar test.Hello
-cp
パラメータで指定するクラス・パスには、JARファイルのみを含める必要があることに注意してください。 -
hello.classlist
内のすべてのクラスを含む、hello.jsa
という名前の共有アーカイブを作成します。java -Xshare:dump -XX:SharedArchiveFile=hello.jsa -XX:SharedClassListFile=hello.classlist -cp hello.jar
アーカイブ作成時に使用するクラス・パスは、実行時に使用されるクラス・パスと同一(または、その接頭辞)である必要があることに注意してください。
-
共有アーカイブ
hello.jsa
を持つアプリケーションtest.Hello
を実行します。java -XX:SharedArchiveFile=hello.jsa -cp hello.jar test.Hello
-
オプション:
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
ファイルを追加する必要があります。
-
Hello
アプリケーションで使用されるすべてのクラスのリストと、Hi
アプリケーションに関する別のリストを作成します。java -XX:DumpLoadedClassList=hello.classlist -cp common.jar:hello.jar Hello
java -XX:DumpLoadedClassList=hi.classlist -cp common.jar:hi.jar Hi
-
共有アーカイブ・ファイルを共有するすべてのアプリケーションで使用されるクラスの単一のリストを作成します。
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
-
common.classlist
内のすべてのクラスを含む、common.jsa
という名前の共有アーカイブを作成します。java -Xshare:dump -XX:SharedArchiveFile=common.jsa -XX:SharedClassListFile=common.classlist -cp common.jar:hello.jar:hi.jar
使用するクラス・パス・パラメータは、
Hello
およびHi
アプリケーションで共有される共通のクラス・パス接頭辞です。 -
同一の共有アーカイブを持つ
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%です。これらの小さい設定を使用した場合にパフォーマンスが犠牲になる可能性があるため、許容できないパフォーマンス低下を招かないように可能なかぎりこれらの設定を減らすことで、小さいフットプリントのために最適化する必要があります。