最近剛好看完《深入理解java虛擬機》,而Eclispe的啟動速度實在是慢到了頂點,正好借此機會對Eclipse進行調優.首先使用Visual VM+Visual GC 對Eclipse進行數據采集

1.先介紹一下界面(Java Heap 分代)：

1.1元空間(MetaSpace)

jdk1.8之后永久帶(Perm)已經被移除,替換為了元空間(MetaSpace),元空間直接使用物理內存分配,而不依賴于java虛擬機.jdk1.7之前永久代是用來描述描述辦法區的,類變量,常量,class對象,以及各種字面量和符號引用都是存放在永久帶中的.但是從1.7之后永久代開始做永久代的轉移,因為永久代很容易導致內存溢出,并且很難做調優.

了解更多的關于永久代和元空間的問題可以看以下的博客,這里不做過多的論述.

http://www.cnblogs.com/paddix/p/5309550.html

-XX:MetaspaceSize,初始空間大小,達到該值就會觸發垃圾收集進行類型卸載,同時GC會對該值進行調整：如果釋放了大量的空間,就適當降低該值；如果釋放了很少的空間,那么在不跨越MaxMetaspaceSize時,適當提高該值.

-XX:MaxMetaspaceSize,最年夜空間,默認是沒有限制的.

1.2年輕代(Yong)

年輕代重要有伊甸園區 (Eden)和兩個存活區(Survivor)組成,默認的比例是8：1：1,新生的對象大部門都是在年輕代分配的,也是Minor GC 的區域,至于對象是如何分配的大家仔細閱讀《深入理解java虛擬機》,這里不做過多的闡述.

1.3老年代(Tenured)

大對象直接在老年代分配以及達到必定年齡的對象會從年輕代晉升到老年代,Full GC的主要區域,一般Full GC的時間會是Minor GC的10倍之多.

2.Graphs區域

2.1)Compile Time(JIT編譯時間):11418 compiles 表現編譯總數 ,16.878s表現編譯時間.

2.2) Class Loader(類加載時間): 18530loaded表現加載類數量, 0 unloaded表現卸載的類數量,28.237s表現類加載花費的時間 .

2.3)GC Time(GC Time)：9 collections表現垃圾收集的總次數,648.756ms表現垃圾收集花費的時間,last cause表現最近垃圾收集的原因 .

2.4)Eden Space(Eden 區)：括號內的204.875M表現最大容量,204.875M表現當前容量,后面的71.497M表現當前使用情況,5 collections表現垃圾收集次數,531.593表現垃圾收集花費時間.

2.5)Survivor 0/Survivor 1(S0和S1區)：括號內的253562M表現最大容量,25.562M表現當前容量,之后的值是當前使用情況

2.6)Old Gen(老年代)：括號內的1.75G表現最大容量,1.75表現當前容量,之后的93.877M表現當前使用情況,4collections表現垃圾收集次數 ,117.163s表現垃圾收集花費時間

2.7)MetaSpace(元空間)：括號內的1.02表現最大容量,115.941M表現當前容量,之后的105.090M表現當前使用情況 .

3.Histogram區域：survivor區域參數跟年齡柱狀圖

3.1)Tenuring Threshold：表現新生代對象年齡大于當前值則進入老年代

3.2)Max Tenuring Threshold：表現新生代對像最大年齡值.

3.3)Tenuring Threshold與Max Tenuring Threshold區別：

虛擬機給每個對象都定義了一個對象年齡的(Age)的計數器,保留在對象頭里,如果Eden中的對象經過一次Minor GC之后任然存活并且能被Survivor容納的話,將被移動到Survivor中,并且對象年齡設置為1,對象在Survivor中沒“熬過”一次Minor GC,年齡增加1歲,當增加到一定程度(默認是15歲)的時候就會被晉升到老年代中.晉升到老年代的閾值可以通過參數-XX:MaxTenuringThresold設置.但是虛擬機并并不永遠要求對象的年齡必須達到MaxTenuringThresold的值才晉升到老年代,如果Survivor中相同年齡對象大小的總和大于Survivor空間的一半,年齡大于或者等于該年齡的對象就可以直接進如老年代.

3.4)Desired Survivor Size：Survivor空間年夜小驗證闕值(默認是survivor空間的一半),用于Tenuring Threshold判斷對象是否提前進入老年代.

3.5)Current Survivor Size：當前survivor空間年夜小

3.6)histogram柱狀圖：表現年齡段對象的存儲柱狀圖

此時我的eclipse啟動時間為25秒.

察看堆內存的使用情況,本人win8系統,8G運行內存,所以我直接在這里指定了堆內存的初始值和最大值相等,不支持它動態的伸縮,提升性能.

-Xms 1024M(默認物理內存1/64)

-Xmx 1024M(默認物理內存1/4)

-Xmn 256M 新生代內存年夜小

并且可以看出老年代大小為新生代的3倍

可以看出java Heap 運行完全正常.

-XX:MetaspaceSize=256m

-XX:MaxMetaspaceSize=256m

將元空間設置一下(很遺憾的是元空間還是存在動態伸縮的問題,不知道為什么)

編譯時間和類加載優化

在進行類加載的時候,字節碼驗證耗時尤為嚴重,而驗證的過程又不是必需的,而且Eclipse已經是非常成熟的軟件,所以它的編譯代碼認為是可靠的,不需要再類加載的時候進行字節碼驗證,所以我們關閉字節碼驗證的過程.

-Xverify:none

JIT編譯是指虛擬機的JIT編譯器,編譯熱點代碼的耗時,隨著代碼使用次數的增加,可以讓我們的代碼被編譯的越來越徹底,運行速度變得更快.虛擬機提供了一個參數-Xint禁止編譯器工作,然則我們不要去關閉這個參數.

當虛擬在-client時使用的是C1輕量級編譯器 ,-server模式下使用的是C2重量級編譯器,提供更加強有力的優化步伐.這里我們使用C2,因為我已經習慣了長時間不關閉Eclipse.

-server

觀察cpu發現我的CPU占用率還是蠻高的,這是為什么?因為在新版本的Eclipse中默認的垃圾收集器便是并行的組合.

-XX:+UseConcMarkSweepGC

開啟CMS收集器后,新生代默認收集器是ParNew

最終的配置是：

-XX:+UseConcMarkSweepGC

-XX:CMSInitiatingOccupancyFraction=85

-XX:CMSFullGCsBeforeCompaction=8

-XX:+UseStringDeduplication

-server

-Xverify:none

-Xms1024m

-Xmx1024m

-Xmn256m

-XX:MetaspaceSize=256m

-XX:MaxMetaspaceSize=256m

-XX:PretenureSizeThreshold=1048576

-XX:CMSInitiatingOccupancyFraction=85 -XX:CMSFullGCsBeforeCompaction=5

第一個參數是因為CMS收集器的并發清除,會產生浮動垃圾,CMS無法在當此垃圾收集的時候處理他們,但是又不克不及因為浮動垃圾填滿整個老年代才去收集垃圾,因為要留一部分空間給用戶線程使用,-XX:CMSInitiatingOccupancyFraction=85,通過配置當老年代超過85%空間被使用就會觸發CMS收集器.

第二個參數是因為CMS收集器采用的是標志-清除算法,老年代會產生空間碎片,導致在分配大對象的時候找不到連續的內存空間而不得不觸發FullGC,為此CMS提供了一個參數+UseCMSCompactAtFullCollection用于在CMS頂不住要進行Full GC的時候開啟內存的合并整理過程,但是合并整理的過程并不是并發的,而是stop the world ,停頓時間就變長了,-XX:CMSFullGCsBeforeCompaction=8 而這個參數是指在8次不合并整理的Full GC 后帶來一次壓縮整理的過程.

-XX:PretenureSizeThreshold=1048576

考慮到實際情況,將年夜于1M的對象直接分配到老年代,減少minor GC的次數

-XX:+UseStringDeduplication

這參數是字符串去重,必需和G1收集器合并使用,我嘗試使用了一下G1收集器發現效果并不是特別明顯.

-XX:+UseStringDeduplication

FullGC 觸發0次,類加載縮短10秒左右.啟動時間根本穩定在16s左右