序號
|
參數名
|
說明
|
JDK
|
默認值
|
使用過
|
1
|
JVM執行模式
|
|
|
|
|
2
|
-client
-server
|
設置該JVM運行與Client 或者Server Hotspot模式,這兩種模式從本質上來說是在JVM中運行不同的JIT(運行時編譯模塊)代碼,並且兩者在JVM內部的接口是一致的。客戶端模式優化的是系統啓動時間更快,而服務端模式的優化則更關注與系統的整體性能。一般來說Client選項用於GUI的應用,Server選項多用於後臺服務器應用。
另外兩者在編譯策略、垃圾收集策略、堆使用上也有所不同
|
|
|
是
|
3
|
-d32
-d64
|
指明該Java VM是運行與32位環境還是64位環境,默認是運行在32位環境下的,如果是配置了64位模式則需要操作系統也必須是64位的,當然CPU更需要是64位的。另外如果我們選擇了-server參數,則就暗含了64位模式。
|
|
默認32模式
|
|
4
|
-hotspot
|
在Hotspot類型的JVM中缺省使用,缺省爲Client Hotspot模式。
|
|
默認client模式
|
|
5
|
-Xmixed
|
JVM執行模式的設置參數,混合模式即支持Hotspot即時編譯的運行模式.
支持Hotspot的JVM缺省都是運行於混合模式的。
|
|
默認混合模式
|
|
|
-Xcomp
|
JVM優先以編譯模式運行,不能編譯的,以解釋模式運行。
|
|
|
|
6
|
-Xint
|
設置JVM的執行模式爲解釋執行模式,純解釋執行的JVM對多數應用來說基本上時沒有意義的,僅僅可能會在一些嵌入式系統中應用
|
|
|
|
7
|
內存分配相關參數
|
|
|
|
|
8
|
-Xms
|
設置JVM啓動時初始內存堆的大小
|
1.6
|
物理內存的1/64.
|
是
|
9
|
-Xmx
|
設置JVM啓動後動態申請堆內存的最大堆空間
|
1.6
|
MIN(物理內存的1/4,1G)
|
是
|
10
|
-Xmn
|
爲新生代分配的內存大小。
|
|
和cpu核數相關,建議1core對應512M,不超過1G。
|
是
|
11
|
-Xss
|
設置JVM線程棧的空間最大值。
|
1.6
|
當設置值小於64K時,用默認值。
|
是
|
12
|
-XX:ThreadStackSize=512
|
每個線程棧大小(K),等於0時表示使用缺省值
|
|
Sparc: 512K,Solaris Intel: 256K,Sparc 64bit: 1024 其他的都爲 0
|
|
13
|
-XX:NewRatio=2
|
新生代內存容量與老生代內存容量的比例。
Ratio of new/old generation sizes. The default value is 2.
|
1.6
|
Client模式默認8,Server模式:2
|
是
|
14
|
-XX:MaxNewSize=size
|
Maximum size of new generation (in bytes). Since 1.4, MaxNewSize is computed as a function of NewRatio. [1.3.1 Sparc: 32m; 1.3.1 x86: 2.5m.]
|
|
|
|
15
|
-XX:NewSize=2m
|
新生代預估默認值。Default size of new generation (in bytes) [5.0 and newer: 64 bit VMs are scaled 30% larger; x86: 1m; x86, 5.0 and older: 640k]
|
1.6
|
2228K
|
|
16
|
-XX:SurvivorRatio=64
|
存活區和eden區所佔的比率:2:64。
Ratio of eden/survivor space size.
|
1.6
|
32
|
是
|
17
|
-XX:PermSize=256m
|
爲持久代分配的初始化內存空間。
|
|
|
|
18
|
-XX:MaxPermSize=256m
|
爲持久代分配的最大內存空間。
|
|
client/server:64M
|
是
|
19
|
-XX:MaxTenuringThreshold=30
|
每次垃圾收集在新生代之間Copy的次數,超過該次數則移至Old區。
Maximum value for tenuring threshold. The default value is 15.
|
|
The default value is 15 for the parallel collector and is 4 for CMS.
|
是
|
20
|
-XX:TargetSurvivorRatio=50
|
該值是一個百分比,控制允許使用的生存區空間的比例。該參數設置較大的話可提高對survivor空間的使用率。
|
|
默認值是50。即佔到50%,則執行Copy策略。
|
是
|
21
|
-XX: PretenureSizeThreshold=64K
|
當申請內存的對象超過該值時,直接在old區分配。
|
|
默認值是0,即所有的對象都在Eden區分配。
|
|
22
|
-XX:MaxHeapFreeRatio=size
|
JVM中堆空間的最大預估值空閒百分比。GC進行垃圾收集時後,如果預估值堆空閒空間超過預定值,收縮預估值內存。
|
|
默認值70
|
是
|
23
|
-XX:MinHeapFreeRatio=size
|
JVM中堆空間的最小預估值空閒百分比。GC進行垃圾收集後,堆空間不得低於預定值,增加分配的內存。
|
|
默認值40
|
是
|
|
-XX:MaxDirectMemorySize=size
|
直接內存最大值。即NIO進行操作時,可以分配的最大緩存值,默認和heap最大值一致。
|
|
默認和heap最大值一致。
|
|
24
|
JVM優化
|
|
|
|
|
25
|
-XX:CompileThreshold=10000
|
設置方法是否進行即時編譯的調用次數的下限值。調用次數超過設定值,進行JIT編譯。
|
|
-server選項的缺省值爲10000,-client選項的缺省值爲1500
|
是
|
|
-XX:+BackgroundCompilation
|
後臺啓用jit編譯
|
|
|
|
26
|
-XX:-CITime
|
設置Hotspot的一次即時編譯所需要的最大時間
|
|
|
|
27
|
-XX:+AggressiveOpts
|
啓用激進的編譯優化
|
|
JDK 5 update 6後引入,但需要手動啓用。
JDK6默認啓用。
|
|
28
|
-XX:+UseFastAccessorMethods
|
原始類型的快速優化,get,set方法轉成本地代碼。
|
|
|
|
29
|
-XX:+DoEscapeAnalysis
|
增加逃逸分析。如果對象的指針未出創建者的方法體,該對象在線程棧內直接分配空間。
|
1.6
|
|
|
30
|
-XX:+DisableExplicitGC
|
屏蔽程序主動垃圾收集的函數system.gc()
|
|
|
是
|
31
|
-XX:FreqInlineSize=size
|
限制經常使用的動態編譯的函數的虛擬機指令的最大數量,
|
|
|
|
32
|
-XX:+UseLargePages
|
啓用大內存分頁。注意操作系統需支持。
關聯參數:-XX:LargePageSizeInBytes=4m
|
|
|
|
33
|
-XX:LargePageSizeInBytes=4m
|
設置堆內存的內存頁大小。
|
|
默認4K。
|
|
34
|
-XX:+UseBiasedLocking
|
啓用偏向鎖。
|
|
JDK 5 update 6後引入,但需要手動啓用。
JDK6默認啓用。
|
|
35
|
-XX:+UseSpinning
|
啓用多線程自旋鎖優化。
自旋鎖優化原理
大家知道,Java的多線程安全是基於Lock機制實現的,而Lock的性能往往不如人意。
原因是,monitorenter與monitorexit這兩個控制多線程同步的bytecode原語,是JVM依賴操作系統互斥(mutex)來實現的。
互斥是一種會導致線程掛起,並在較短的時間內又必須重新調度回原線程的,較爲消耗資源的操作。
爲了避免進入OS互斥,Java6的開發者們提出了自旋鎖優化。
自旋鎖優化的原理是在線程進入OS互斥前,通過CAS自旋一定的次數來檢測鎖的釋放。
如果在自旋次數未達到預設值前鎖已被釋放,則當前線程會立即持有該鎖。
|
|
java1.4.2和1.5需要手動啓用, java6默認已啓用
|
|
36
|
-XX:PreBlockSpin=10
|
控制多線程自旋鎖優化的自旋次數。(什麼是自旋鎖優化?見 -XX:+UseSpinning 處的描述)
關聯選項:
-XX:+UseSpinning
|
|
java6來說已經默認啓用了,這裏默認自旋10次
|
|
37
|
-XX:+UseSplitVerifier
|
使用新的Class類型校驗器 。
新Class類型校驗器有什麼特點?
新Class類型校驗器,將老的校驗步驟拆分成了兩步:
1,類型推斷。
2,類型校驗。
新類型校驗器通過在javac編譯時嵌入類型信息到bytecode中,省略了類型推斷這一步,從而提升了classloader的性能。
Classload順序(供參考)
load -> verify -> prepare -> resove -> init
關聯選項:
-XX:+FailOverToOldVerifier
|
|
java5默認不啓用
java6默認啓用
|
|
38
|
-XX:+FailOverToOldVerifier
|
如果新的Class校驗器檢查失敗,則使用老的校驗器。
爲什麼會失敗?
因爲JDK6最高向下兼容到JDK1.2,而JDK1.2的class info 與JDK6的info存在較大的差異,所以新校驗器可能會出現校驗失敗的情況。
關聯選項:
-XX:+UseSplitVerifier
|
|
Java6新引入選項,默認啓用
|
|
39
|
-XX:+HandlePromotionFailure
|
關閉新生代收集擔保。
在一次理想化的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異常。
|
|
java5以前是默認不啓用,java6默認啓用
|
|
40
|
-XX:+UseTLAB
|
啓用線程本地緩存區(Thread Local)。
|
|
1.4.2以前和使用-client選項時,默認不啓用,其餘版本默認啓用
|
|
41
|
-XX:+UseThreadPriorities
|
使用本地線程的優先級。
|
|
默認啓用
|
|
42
|
-XX:-UseLWPSynchronization
|
使用操作系統提供的輕量級線程LWP同步來代替基於Java虛擬機的線程的同步
|
|
限於solaris,默認啓用
|
|
43
|
-XX:+UseBoundThreads
|
綁定所有的用戶線程到內核線程。
減少線程進入飢餓狀態(得不到任何cpu time)的次數。
|
|
限於solaris,默認啓用
|
|
44
|
垃圾收集器設置
|
|
|
|
|
45
|
-XX:+UseSerialGC
|
設置串行收集器。
|
|
|
是
|
46
|
-XX:+UseParallelGC
|
選擇垃圾收集器爲並行收集器,此配置僅對年輕代有效,即上述配置下,年輕代使用並行收集,而老年代仍舊使用串行收集。採用了多線程並行管理和回收垃圾對象,提高了回收效率,提高了服務器的吞吐量,適合於多處理器的服務器。
|
|
|
是
|
47
|
-XX:+UseParNewGC
|
指定在 New Generation使用 parallel collector,是 UseParallelGC的 gc的升級版本 ,有更好的性能或者優點 ,可以和 CMS gc一起使用
|
|
|
是
|
48
|
-XX:+UseParallelOldGC
|
採用對於老年代並行收集的策略,可以提高收集效率。JDK6.0支持對老年代並行收集。
|
|
|
是
|
49
|
-XX:+UseConcMarkSweepGC
|
指定在老年代使用 concurrent cmark sweep gc。gc thread和 app thread並行 (在 init-mark和 remark時 pause app thread)。app pause時間較短 ,適合交互性強的系統 ,如 web server。它可以併發執行收集操作,降低應用停止時間,同時它也是並行處理模式,可以有效地利用多處理器的系統的多進程處理。新生代默認使用:parnew
|
|
使用此垃圾收集器是,sun建議NewRatio=4
|
|
50
|
-XX:+CMSIncrementalMode
|
設置爲增量模式。適用於單CPU情況
|
|
|
|
51
|
-XX:+ClassUnloading
|
對持久代卸載的類進行回收
|
|
|
|
52
|
-XX:+CMSClassUnloadingEnabled
|
使CMS收集持久代的unload的類,而不是fullgc
|
|
|
|
53
|
-XX:+CMSPermGenSweepingEnabled
|
使CMS收集持久代的類不引用的class,而不是fullgc。
|
|
1.JDK 1.6 32位下不可用。
2.JDK 1.5 64位下可用。
|
|
73
|
-XX:+UseAdaptiveSizePolicy
|
設置此選項後,並行收集器會對於收集時間、分配比例、收集之 後 堆的空閒空間等數據進行統計分析,然後以此爲依據調整新生代和舊生代的大小以達到最佳效果。此值建議使用並行收集器時,一直打開。
|
|
適合吞吐量優先的垃圾收集器。
使用sun jdk(1.6.30以上到1.7的全部版本已經確認有該問題,jdk8修復,其他版本待驗證
|
是
|
74
|
-XX:+AggressiveHeap
|
選項會檢測主機的資源(內存大小、處理器數量),然後調整相關的參 數,使得長時間運行的、內存申請密集的任務能夠以最佳狀態運行。該選項最初是爲擁有大量內存和 很多處理器的主機而設計的,但是從J2SE1.4.1以及其後繼版本來看,即使是對於那些只有4顆CPU的 主機,該選項都是很有幫助的。因此,吞吐收集器(-XX:+UseParallelGC)、大小自適應 (-XX:+UseAdaptiveSizePolicy)以及本選項(-XX:+AggressiveHeap)經常結合在一起使用。要使 用本選項,主機上至少要有256M的物理內存,堆內存的最初大小是基於物理內存計算出來的,然後 會根據需要儘可能的利用物理內存。用於JVM運行於大內存模式下,JVM的堆空間至少在1G以
上。與-Xms、-Xmx不同時使用,慎用!會導致JVM極度消耗內存
|
|
適合吞吐量優先的垃圾收集器。
|
是,在基建的性能調優時用過,並沒有顯示出出色的性能。
|
54
|
垃圾收集器相關參數
|
|
|
|
|
55
|
-XX:+ScavengeBeforeFullGC
|
並收集,在Full GC前觸發一次Minor GC。
|
|
默認啓用
|
|
57
|
-XX:+CMSParallelRemarkEnabled
|
儘量減少 mark的時間。
|
|
|
該參數未驗證。
|
|
-XX:CMSScavengeBeforRemark
|
併發收集,在remark之前,啓動次收集。
|
|
|
|
56
|
-XX:+UseGCOverheadLimit
|
限制GC的運行時間。如果GC耗時過長,就拋OOM。
|
|
默認啓用
|
|
58
|
-XX:CMSFullGCsBeforeCompaction=10
|
由於併發收集器不對內存空間進行壓縮、整理,所以運行一段時間以後會產生“碎片”,使得運行效率降低。此值設置運行多少次GC以後對內存空間進行壓縮、整理。發生多少次CMS Full GC,這個參數最好不要設置,因爲要做compaction的話,也就是真正的Full GC是串行的,非常慢,讓它自己去決定什麼時候需要做compaction。
|
|
配合併發垃圾收集器。
|
|
59
|
-XX:+UseCMSCompactAtFullCollection
|
打開對老年代的壓縮。可能會影響性能,但是可以消除碎片,在FULL GC的時候,壓縮內存, CMS是不會移動內存的,因此,這個非常容易產生碎片,導致內存不夠用,因此,內存的壓縮這個時候就會被啓用。增加這個參數是個好習慣。
|
|
配合併發垃圾收集器。
|
|
60
|
-XX:CMSInitiatingOccupancyFraction
|
說明老年代到百分之多少滿的時候開始執行對老年代的併發垃圾回收(CMS),這個參數設置有很大技巧,基本上滿足公式:
(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn
時就不會出現promotion failed。在我的應用中Xmx是6000,Xmn是500,那麼Xmx-Xmn是5500兆,也就是老年代有5500兆,CMSInitiatingOccupancyFraction=90說明老年代到90%滿的時候開始執行對老年代的併發垃圾回收(CMS),這時還剩10%的空間是5500*10%=550兆,所以即使Xmn(也就是年輕代共500兆)裏所有對象都搬到老年代裏,550兆的空間也足夠了,所以只要滿足上面的公式,就不會出現垃圾回收時的promotion failed;
如果按照Xmx=2048,Xmn=768的比例計算,則CMSInitiatingOccupancyFraction的值不能超過40,否則就容易出現垃圾回收時的promotion failed。
|
|
jdk:1.5配合併發垃圾收集器。默認是68%。
JDK 1.6 默認是92%。(太高,建議修改爲80%)。
|
|
61
|
-XX:+UseCMSInitiatingOccupancyOnly
|
是否僅僅按照指定比例啓動CMS收集,默認爲false。指示只有在老年代在使用了初始化的比例後 concurrent collector 啓動收集。
配合:,CMSInitiatingOccupancyFraction參數使用。
|
|
默認false
|
|
|
-XX:CMSScheduleRemarkEdenSizeThreshold
|
即Eden區域多大的時候開始觸發remark,默認是2M
|
|
默認是2M
|
|
|
-XX:CMSScheduleRemarkEdenPenetration
|
即Eden區域多大的時候開始出發remark,eden使用量超過百分比多少的時候觸發,默認是50%。
|
|
默認是50%。
|
|
|
-XX:CMSMaxAbortablePrecleanTime
|
但是如果長期不做remark導致old做不了,可以設置超時,這個超時默認是5秒,超過5秒鐘做remark;設置preclean步驟的超時時間,單位爲毫秒。
|
|
默認5秒
|
|
|
-XX:CMSInitiatingPermOccupancyFraction
|
持久代內存達到多是,進行垃圾收集。
|
|
|
|
69
|
-XX:ConcGCThreads=n
|
Number of threads concurrent garbage collectors will use. The default value varies with the platform on which the JVM is running.
|
|
配合併發垃圾收集器。
(ParallelGCThreads + 3)/4);
ParallelGCThreads是年輕代的並行收集線程數
|
JDK 32位 1.6下不可用。
|
|
-XX:ParallelCMSThreads
|
同上-XX:ConcGCThreads=n
|
|
|
|
70
|
-XX:MaxGCPauseMillis=
|
指定垃圾回收時的最長暫停時間。爲毫秒.如果指定了此值的話,堆大小和垃圾回收相關參數會進行調整以達到指定值。設定此值可能會減少應用的吞吐量。
|
|
適合吞吐量優先的垃圾收集器。
|
|
71
|
-XX:GCTimeRatio=
|
爲垃圾回收時間與非垃圾回收時間的比值.公式爲1:(1+N)。例如,-XX:GCTimeRatio=19時,表示5%的時間用於垃圾回收。默認情況爲99,即1%的時間用於垃圾回收。
|
|
適合吞吐量優先的垃圾收集器。
默認值:1%
|
|
|
?-XX:+CMSConcurrentMTEnabled
|
在併發階段利用多核。
|
|
|
|
72
|
-XX:ParallelGCThreads=8
|
配置並行收集器的線程數,即:同時多少個線程一起進行垃圾回收。此值最好配置與處理器數目相等。
Sets the number of threads used during parallel phases of the garbage collectors. The default value varies with the platform on which the JVM is running.
|
|
並行垃圾收集器配套使用。
ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8);
在cms垃圾收集中:
指定在stop-the-world過程中,並行線程的個數,默認cpu個數。
|
|
75
|
-Xnoincgc
|
在垃圾收集中不使用火車算法
|
|
|
|
76
|
-Xincgc
|
在垃圾收集中使用火車算法,降低暫停時間。注意會佔用10%左右的CPU資源。
|
|
適合低停頓垃圾收集器。
|
|
62
|
-XX:+CMSIncrementalMode
|
在併發垃圾收集器中,使用增量模式。默認爲不使用。
|
1.5
|
配合併發垃圾收集器。
默認不啓用
|
以下綠色表示增量收集,適用於單CPU情況。Sun不推薦使用
|
63
|
-XX:+CMSIncrementalPacing
|
This flag enables automatic adjustment of the incremental mode duty cycle based on statistics collected while the JVM is running.
|
1.5
|
配合併發垃圾收集器。
默認不啓用
|
|
64
|
-XX:CMSIncrementalDutyCycle=
|
This is the percentage (0-100) of time between minor collections that the concurrent collector is allowed to run. If CMSIncrementalPacing is enabled, then this is just the initial value.
|
1.5
|
配合併發垃圾收集器。
默認50
|
|
65
|
-XX:CMSIncrementalDutyCycleMin=
|
This is the percentage (0-100) which is the lower bound on the duty cycle when CMSIncrementalPacing is enabled.
|
1.5
|
配合併發垃圾收集器。
10
|
|
66
|
-XX:CMSIncrementalSafetyFactor=
|
This is the percentage (0-100) used to add conservatism when computing the duty cycle
|
1.5
|
配合併發垃圾收集器。
10
|
|
67
|
-XX:CMSIncrementalOffset=
|
This is the percentage (0-100) by which the incremental mode duty cycle is shifted to the right within the period between minor collections.
|
1.5
|
配合併發垃圾收集器。
0
|
|
68
|
-XX:CMSExpAvgFactor=
|
This is the percentage (0-100) used to weight the current sample when computing exponential averages for the concurrent collection statistics
|
1.5
|
配合併發垃圾收集器。
25
|
|
77
|
調試選項
|
|
|
|
|
78
|
-XX:-CITime
|
打印JIT編譯器編譯耗時。
|
|
1.4引入。
默認啓用
|
|
79
|
-XX:HeapDumpPath=./java_pid.hprof
|
堆內存快照的存儲文件路徑。文件名一般爲
java___ _heapDump.hprof
|
|
不啓用
|
|
80
|
-XX:+HeapDumpOnOutOfMemoryError
|
在OOM時,輸出一個dump.core文件到
|
|
1.4.2 update12 和 5.0 update 7 引入。
默認不啓用
|
|
81
|
-XX:ErrorFile=./hs_err_pid.log
|
|
1.6
|
如果JVM crashed,將錯誤日誌輸出到指定文件路徑。
|
|
|
-verbose:gc
|
輸出垃圾回收信息和-Xloggc:path配合使用
|
|
|
|
|
-Xloggc:filename
-XX:GCLogFileSize=5M
|
gc日誌輸出文件;日誌文件分隔,每5M分隔一個文件。
|
|
|
|
82
|
-XX:+PrintCompilation
|
往stdout打印方法被JIT編譯時的信息。
例如:
1 java.lang.String::charAt (33 bytes)
|
|
不啓用
|
|
83
|
-XX:+PrintGC
|
開啓GC日誌打印。
打印格式例如:
[Full GC 131115K->7482K(1015808K), 0.1633180 secs]
|
|
不啓用
|
|
84
|
-XX:+PrintGCDetails
|
打印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]
|
|
不啓用
|
|
85
|
-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.06secs]
|
|
不啓用
|
|
86
|
-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後存活的對象大小。
|
|
不啓用
|
|
87
|
-XX:+TraceClassLoading
|
打印class裝載信息到stdout。記Loaded狀態。
|
|
不啓用
|
|
88
|
-XX:+TraceClassLoadingPreorder
|
按class的引用/依賴順序打印類裝載信息到stdout。不同於 TraceClassLoading,本選項只記 Loading狀態。
|
1.4.2
|
不啓用
|
|
89
|
-XX:+TraceClassUnloading
|
打印class的卸載信息到stdout。記Unloaded狀態。
|
|
不啓用
|
|
90
|
-XX:+TraceClassResolution
|
打印所有靜態類,常量的代碼引用位置。用於debug。
例如:
RESOLVE java.util.HashMap java.util.HashMap$Entry HashMap.java:209
說明HashMap類的209行引用了靜態類 java.util.HashMap$Entry
|
1.4.2
|
不啓用
|
|
91
|
-XX:+TraceClassUnloading
|
打印class的卸載信息到stdout。記Unloaded狀態。
|
|
不啓用
|
|
92
|
-XX:+TraceLoaderConstraints
|
打印class的裝載策略變化信息到stdout。
例如:
[Adding new constraint for name: java/lang/String, loader[0]: sun/misc/Launcher$ExtClassLoader, loader[1]: ]
裝載策略變化是實現classloader隔離/名稱空間一致性的關鍵技術。
|
1.6
|
不啓用
|
|
93
|
-XX:+PerfSaveDataToFile
|
當java進程因OOM或crashed被強制終止後,生成一個堆快照文件(什麼是堆內存快照? 見 -XX:HeapDumpPath 處的描述)
|
|
|
|
JVM性能調優參數整理
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.