java虛擬機參數指南

非穩態選項使用說明

-XX:+<option> 啓用選項

-XX:-<option> 不啓用選項

-XX:<option>=<number> 給選項設置一個數字類型值，可跟單位，例如 32k, 1024m, 2g

-XX:<option>=<string> 給選項設置一個字符串值，例如-XX:HeapDumpPath=./dump.core

行爲選項

選項

默認值與限制

描述

-XX:-AllowUserSignalHandlers

限於Linux和Solaris，默認不啓用

容許爲java進程安裝信號處理器。

Java信號處理相關知識，詳見 http://kenwublog.com/java-asynchronous-notify-based-on-signal

-XX:-DisableExplicitGC

默認不啓用

禁止在運行期顯式地調用 System.gc()。

開啓該選項後，GC的觸發時機將由Garbage Collector全權掌控。

注意：你熟悉的代碼裏沒調用System.gc()，不表明你依賴的框架工具沒在使用。

例如RMI就在多數用戶絕不知情的狀況下，顯示地調用GC來防止自身OOM。

請仔細權衡禁用帶來的影響。

-XX:-RelaxAccessControlCheck

默認不啓用

在Class校驗器中，放鬆對訪問控制的檢查。

做用與reflection裏的setAccessible相似。

-XX:-UseConcMarkSweepGC

默認不啓用

啓用CMS低停頓垃圾收集器。

資料詳見：http://kenwublog.com/docs/CMS_GC.pdf

-XX:-UseParallelGC

-server時啓用

其餘狀況下，默認不啓用

策略爲新生代使用並行清除，年老代使用單線程Mark-Sweep-Compact的垃圾收集器。

-XX:-UseParallelOldGC

默認不啓用

策略爲老年代和新生代都使用並行清除的垃圾收集器。

-XX:-UseSerialGC

-client時啓用

其餘狀況下，默認不啓用

使用串行垃圾收集器。

-XX:+UseSplitVerifier

java5默認不啓用

java6默認啓用

使用新的Class類型校驗器 。

新Class類型校驗器有什麼特色？

新Class類型校驗器，將老的校驗步驟拆分紅了兩步：

1，類型推斷。

2，類型校驗。

新類型校驗器經過在javac編譯時嵌入類型信息到bytecode中，省略了類型推斷這一步，從而提高了classloader的性能。

Classload順序（供參考）

load -> verify -> prepare -> resove -> init

關聯選項：

-XX:+FailOverToOldVerifier

-XX:+FailOverToOldVerifier

Java6新引入選項，默認啓用

若是新的Class校驗器檢查失敗，則使用老的校驗器。

爲何會失敗？

由於JDK6最高向下兼容到JDK1.2，而JDK1.2的class info 與JDK6的info存在較大的差別，因此新校驗器可能會出現校驗失敗的狀況。

關聯選項：

-XX:+UseSplitVerifier

-XX:+HandlePromotionFailure    

java5之前是默認不啓用，java6默認啓用

關閉新生代收集擔保。

什麼是新生代收集擔保？

在一次理想化的minor gc中，Eden和First Survivor中的活躍對象會被複制到Second Survivor。

然而，Second Survivor不必定能容納下全部從E和F區copy過來的活躍對象。

爲了確保minor gc可以順利完成，GC須要在年老代中額外保留一塊足以容納全部活躍對象的內存空間。

這個預留操做，就被稱之爲新生代收集擔保（New Generation Guarantee）。若是預留操做沒法完成時，仍會觸發major gc(full gc)。

爲何要關閉新生代收集擔保？

由於在年老代中預留的空間大小，是沒法精確計算的。

爲了確保極端狀況的發生，GC參考了最壞狀況下的新生代內存佔用，即Eden+First Survivor。

這種策略無疑是在浪費年老代內存，從時序角度看，還會提早觸發Full GC。

爲了不如上狀況的發生，JVM容許開發者手動關閉新生代收集擔保。

在開啓本選項後，minor gc將再也不提供新生代收集擔保，而是在出現survior或年老代不夠用時，拋出promotion failed異常。

-XX:+UseSpinning

java1.4.2和1.5須要手動啓用, java6默認已啓用

啓用多線程自旋鎖優化。

自旋鎖優化原理

你們知道，Java的多線程安全是基於Lock機制實現的，而Lock的性能每每不如人意。

緣由是，monitorenter與monitorexit這兩個控制多線程同步的bytecode原語，是JVM依賴操做系統互斥(mutex)來實現的。

互斥是一種會致使線程掛起，並在較短的時間內又必須從新調度回原線程的，較爲消耗資源的操做。

爲了不進入OS互斥，Java6的開發者們提出了自旋鎖優化。

自旋鎖優化的原理是在線程進入OS互斥前，經過CAS自旋必定的次數來檢測鎖的釋放。

若是在自旋次數未達到預設值前鎖已被釋放，則當前線程會當即持有該鎖。

CAS檢測鎖的原理詳見: http://kenwublog.com/theory-of-lightweight-locking-upon-cas

關聯選項：

-XX:PreBlockSpin=10

-XX:PreBlockSpin=10

-XX:+UseSpinning 必須先啓用，對於java6來講已經默認啓用了，這裏默認自旋10次

控制多線程自旋鎖優化的自旋次數。(什麼是自旋鎖優化？見 -XX:+UseSpinning 處的描述)

關聯選項：

-XX:+UseSpinning

-XX:+ScavengeBeforeFullGC    

默認啓用

在Full GC前觸發一次Minor GC。

-XX:+UseGCOverheadLimit

默認啓用

限制GC的運行時間。若是GC耗時過長，就拋OOM。

-XX:+UseTLAB

1.4.2之前和使用-client選項時，默認不啓用，其他版本默認啓用

啓用線程本地緩存區（Thread Local）。

-XX:+UseThreadPriorities

默認啓用

使用本地線程的優先級。

-XX:+UseAltSigs

限於Solaris，默認啓用

爲了防止與其餘發送信號的應用程序衝突，容許使用候補信號替代 SIGUSR1和SIGUSR2。

-XX:+UseBoundThreads

限於Solaris, 默認啓用

綁定全部的用戶線程到內核線程。

減小線程進入飢餓狀態（得不到任何cpu time）的次數。

-XX:+UseLWPSynchronization

限於solaris，默認啓用

使用輕量級進程（內核線程）替換線程同步。

-XX:+MaxFDLimit

限於Solaris，默認啓用

設置java進程可用文件描述符爲操做系統容許的最大值。

-XX:+UseVMInterruptibleIO

限於solaris，默認啓用

在solaris中，容許運行時中斷線程 。

性能選項

選項與默認值

默認值與限制

描述

-XX:+AggressiveOpts

JDK 5 update 6後引入，但須要手動啓用。

JDK6默認啓用。

啓用JVM開發團隊最新的調優成果。例如編譯優化，偏向鎖，並行年老代收集等。

-XX:CompileThreshold=10000

1000

經過JIT編譯器，將方法編譯成機器碼的觸發閥值，能夠理解爲調用方法的次數，例如調1000次，將方法編譯爲機器碼。

-XX:LargePageSizeInBytes=4m

默認4m

amd64位：2m

設置堆內存的內存頁大小。

調整內存頁的方法和性能提高原理，詳見 http://kenwublog.com/tune-large-page-for-jvm-optimization

-XX:MaxHeapFreeRatio=70

70

GC後，若是發現空閒堆內存佔到整個預估上限值的70%，則收縮預估上限值。

什麼是預估上限值？

JVM在啓動時，會申請最大值（-Xmx指定的數值）的地址空間，但其中絕大部分空間不會被當即分配(virtual)。

它們會一直保留着，直到運行過程當中，JVM發現實際佔用接近已分配上限值時，才從virtual裏再分配掉一部份內存。

這裏提到的已分配上限值，也能夠叫作預估上限值。

引入預估上限值的好處是，能夠有效地控制堆的大小。堆越小，GC效率越高嘛。

注意：預估上限值的大小必定小於或等於最大值。

-XX:MaxNewSize=size

1.3.1 Sparc: 32m

1.3.1 x86: 2.5m

新生代佔整個堆內存的最大值。

-XX:MaxPermSize=64m

5.0之後: 64 bit VMs會增大預設值的30%

1.4 amd64: 96m

1.3.1 -client: 32m

其餘默認 64m

Perm（俗稱方法區）佔整個堆內存的最大值。

-XX:MinHeapFreeRatio=40

40

GC後，若是發現空閒堆內存佔到整個預估上限值的40%，則增大上限值。

(什麼是預估上限值？見 -XX:MaxHeapFreeRatio 處的描述)

關聯選項：

-XX:MaxHeapFreeRatio=70

-XX:NewRatio=2

Sparc -client: 8

x86 -server: 8

x86 -client: 12

-client: 4 (1.3)

8 (1.3.1+)

x86: 12

其餘默認 2

新生代和年老代的堆內存佔用比例。

例如2例如2表示新生代佔年老代的1/2，佔整個堆內存的1/3。

-XX:NewSize=2.125m

5.0之後: 64 bit Vms 會增大預設值的30%

x86: 1m

x86, 5.0之後: 640k

其餘默認 2.125m

新生代預估上限的默認值。(什麼是預估上限值？見 -XX:MaxHeapFreeRatio 處的描述)

-XX:ReservedCodeCacheSize=32m    

Solaris 64-bit, amd64, -server x86: 48m

1.5.0_06以前, Solaris 64-bit amd64: 1024m

其餘默認 32m

設置代碼緩存的最大值，編譯時用。

-XX:SurvivorRatio=8

Solaris amd64: 6

Sparc in 1.3.1: 25

Solaris platforms 5.0之前: 32

其餘默認 8

Eden與Survivor的佔用比例。例如8表示，一個survivor區佔用 1/8 的Eden內存，即1/10的新生代內存，爲何不是1/9？

由於咱們的新生代有2個survivor，即S1和S22。因此survivor總共是佔用新生代內存的 2/10，Eden與新生代的佔比則爲 8/10。

-XX:TargetSurvivorRatio=50

50

實際使用的survivor空間大小佔比。默認是50%，最高90%。

-XX:ThreadStackSize=512

Sparc: 512

Solaris x86: 320 (5.0之前 256)

Sparc 64 bit: 1024

Linux amd64: 1024 (5.0 之前 0)

其餘默認 512.

線程堆棧大小

-XX:+UseBiasedLocking

JDK 5 update 6後引入，但須要手動啓用。

JDK6默認啓用。

啓用偏向鎖。

偏向鎖原理詳見 http://kenwublog.com/theory-of-java-biased-locking

-XX:+UseFastAccessorMethods

默認啓用

優化原始類型的getter方法性能。

-XX:-UseISM

默認啓用

啓用solaris的ISM。

詳見Intimate Shared Memory.

-XX:+UseLargePages

JDK 5 update 5後引入，但須要手動啓用。

JDK6默認啓用。

啓用大內存分頁。

調整內存頁的方法和性能提高原理，詳見http://kenwublog.com/tune-large-page-for-jvm-optimization

關聯選項

-XX:LargePageSizeInBytes=4m

-XX:+UseMPSS

1.4.1 以前: 不啓用

其他版本默認啓用

啓用solaris的MPSS，不能與ISM同時使用。

-XX:+StringCache

默認啓用

啓用字符串緩存。

-XX:AllocatePrefetchLines=1

1

與機器碼指令預讀相關的一個選項，資料比較少，本文檔不作解釋。有興趣的朋友請自行閱讀官方doc。

-XX:AllocatePrefetchStyle=1

1

與機器碼指令預讀相關的一個選項，資料比較少，本文檔不作解釋。有興趣的朋友請自行閱讀官方doc。

調試選項

選項與默認值

默認值與限制

描述

-XX:-CITime

1.4引入。

默認啓用

打印JIT編譯器編譯耗時。

-XX:ErrorFile=./hs_err_pid<pid>.log

Java 6引入。

若是JVM crashed，將錯誤日誌輸出到指定文件路徑。

-XX:-ExtendedDTraceProbes

Java6引入，限於solaris

默認不啓用

啓用dtrace診斷。

-XX:HeapDumpPath=./java_pid<pid>.hprof    

默認是java進程啓動位置，即user.dir

堆內存快照的存儲文件路徑。

什麼是堆內存快照？

當java進程因OOM或crash被OS強制終止後，會生成一個hprof（Heap PROFling）格式的堆內存快照文件。該文件用於線下調試，診斷，查找問題。

文件名通常爲

java_<pid>_<date>_<time>_heapDump.hprof

解析快照文件，可使用 jhat, eclipse MAT，gdb等工具。

-XX:-HeapDumpOnOutOfMemoryError

1.4.2 update12 和 5.0 update 7 引入。

默認不啓用

在OOM時，輸出一個dump.core文件，記錄當時的堆內存快照（什麼是堆內存快照? 見 -XX:HeapDumpPath 處的描述）。

-XX:OnError="<cmd args>;<cmd args>"

1.4.2 update 9引入

當java每拋出一個ERROR時，運行指定命令行指令集。指令集是與OS環境相關的，在linux下多數是bash腳本，windows下是dos批處理。

-XX:OnOutOfMemoryError="<cmd args>;

<cmd args>"

1.4.2 update 12和java6時引入

當第一次發生OOM時，運行指定命令行指令集。指令集是與OS環境相關的，在linux下多數是bash腳本，windows下是dos批處理。

-XX:-PrintClassHistogram

默認不啓用

在Windows下, 按ctrl-break或Linux下是執行kill -3（發送SIGQUIT信號）時，打印class柱狀圖。

Jmap –histo pid也實現了相同的功能。

詳見 http://java.sun.com/javase/6/docs/technotes/tools/share/jmap.html

-XX:-PrintConcurrentLocks

默認不啓用

在thread dump的同時，打印java.util.concurrent的鎖狀態。

Jstack –l pid 也一樣實現了一樣的功能。

詳見 http://java.sun.com/javase/6/docs/technotes/tools/share/jstack.html

-XX:-PrintCommandLineFlags

5.0 引入，默認不啓用

Java啓動時，往stdout打印當前啓用的非穩態jvm options。

例如：

-XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:+DoEscapeAnalysis

-XX:-PrintCompilation

默認不啓用

往stdout打印方法被JIT編譯時的信息。

例如：

1       java.lang.String::charAt (33 bytes)

-XX:-PrintGC

默認不啓用

開啓GC日誌打印。

打印格式例如：

[Full GC 131115K->7482K(1015808K), 0.1633180 secs]

該選項可經過 com.sun.management.HotSpotDiagnosticMXBean API 和 Jconsole 動態啓用。

詳見 http://java.sun.com/developer/technicalArticles/J2SE/monitoring/#Heap_Dump

-XX:-PrintGCDetails

1.4.0引入，默認不啓用

打印GC回收的細節。

打印格式例如：

[Full GC (System) [Tenured: 0K->2394K(466048K), 0.0624140 secs] 30822K->2394K(518464K), [Perm : 10443K->10443K(16384K)], 0.0625410 secs] [Times: user=0.05 sys=0.01, real=0.06 secs]

該選項可經過 com.sun.management.HotSpotDiagnosticMXBean API 和 Jconsole 動態啓用。

詳見 http://java.sun.com/developer/technicalArticles/J2SE/monitoring/#Heap_Dump

-XX:-PrintGCTimeStamps

默認不啓用

打印GC停頓耗時。

打印格式例如：

2.744: [Full GC (System) 2.744: [Tenured: 0K->2441K(466048K), 0.0598400 secs] 31754K->2441K(518464K), [Perm : 10717K->10717K(16384K)], 0.0599570 secs] [Times: user=0.06 sys=0.00, real=0.06

secs]

該選項可經過 com.sun.management.HotSpotDiagnosticMXBean API 和 Jconsole 動態啓用。

詳見 http://java.sun.com/developer/technicalArticles/J2SE/monitoring/#Heap_Dump

-XX:-PrintTenuringDistribution

默認不啓用

打印對象的存活期限信息。

打印格式例如：

[GC

Desired survivor size 4653056 bytes, new threshold 32 (max 32)

- age 1: 2330640 bytes, 2330640 total

- age 2: 9520 bytes, 2340160 total

204009K->21850K(515200K), 0.1563482 secs]

Age1 2表示在第1和2次GC後存活的對象大小。

-XX:-TraceClassLoading

默認不啓用

打印class裝載信息到stdout。記Loaded狀態。

例如：

[Loaded java.lang.Object from /opt/taobao/install/jdk1.6.0_07/jre/lib/rt.jar]

-XX:-TraceClassLoadingPreorder

1.4.2引入，默認不啓用

按class的引用/依賴順序打印類裝載信息到stdout。不一樣於 TraceClassLoading，本選項只記 Loading狀態。

例如：

[Loading java.lang.Object from /home/confsrv/jdk1.6.0_14/jre/lib/rt.jar]

-XX:-TraceCla***esolution

1.4.2引入，默認不啓用

打印全部靜態類，常量的代碼引用位置。用於debug。

例如：

RESOLVE java.util.HashMap java.util.HashMap$Entry HashMap.java:209

說明HashMap類的209行引用了靜態類 java.util.HashMap$Entry

-XX:-TraceClassUnloading

默認不啓用

打印class的卸載信息到stdout。記Unloaded狀態。

-XX:-TraceLoaderConstraints

Java6 引入，默認不啓用

打印class的裝載策略變化信息到stdout。

例如：

[Adding new constraint for name: java/lang/String, loader[0]: sun/misc/Launcher$ExtClassLoader, loader[1]: <bootloader> ]

[Setting class object in existing constraint for name: [Ljava/lang/Object; and loader sun/misc/Launcher$ExtClassLoader ]

[Updating constraint for name org/xml/sax/InputSource, loader <bootloader>, by setting class object ]

[Extending constraint for name java/lang/Object by adding loader[15]: sun/reflect/DelegatingClassLoader  ]

裝載策略變化是實現classloader隔離/名稱空間一致性的關鍵技術。

對此感興趣的朋友，詳見 http://kenwublog.com/docs/Dynamic+Class+Loading+in+the+Java+Virtual+Machine.pdf 中的 contraint rules一章。

-XX:+PerfSaveDataToFile

默認啓用

當java進程因OOM或crashed被強制終止後，生成一個堆快照文件（什麼是堆內存快照? 見 -XX:HeapDumpPath 處的描述）。