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

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

1.1元空間(MetaSpace)

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

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

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

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

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

1.2年輕代(Yong)

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

1.3老年代(Tenured)

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

2.Graphs區(qū)域

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

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

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

2.4)Eden Space(Eden 區(qū))：括號內(nèi)的204.875M表現(xiàn)最大容量,204.875M表現(xiàn)當(dāng)前容量,后面的71.497M表現(xiàn)當(dāng)前使用情況,5 collections表現(xiàn)垃圾收集次數(shù),531.593表現(xiàn)垃圾收集花費時間.

2.5)Survivor 0/Survivor 1(S0和S1區(qū))：括號內(nèi)的253562M表現(xiàn)最大容量,25.562M表現(xiàn)當(dāng)前容量,之后的值是當(dāng)前使用情況

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

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

3.Histogram區(qū)域：survivor區(qū)域參數(shù)跟年齡柱狀圖

3.1)Tenuring Threshold：表現(xiàn)新生代對象年齡大于當(dāng)前值則進入老年代

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

3.3)Tenuring Threshold與Max Tenuring Threshold區(qū)別：

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

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

3.5)Current Survivor Size：當(dāng)前survivor空間年夜小

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

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

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

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

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

-Xmn 256M 新生代內(nèi)存年夜小

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

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

-XX:MetaspaceSize=256m

-XX:MaxMetaspaceSize=256m

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

編譯時間和類加載優(yōu)化

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

-Xverify:none

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

當(dāng)虛擬在-client時使用的是C1輕量級編譯器 ,-server模式下使用的是C2重量級編譯器,提供更加強有力的優(yōu)化步伐.這里我們使用C2,因為我已經(jīng)習(xí)慣了長時間不關(guān)閉Eclipse.

-server

觀察cpu發(fā)現(xiàn)我的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

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

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

-XX:PretenureSizeThreshold=1048576

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

-XX:+UseStringDeduplication

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

-XX:+UseStringDeduplication

FullGC 觸發(fā)0次,類加載縮短10秒左右.啟動時間根本穩(wěn)定在16s左右