JVM優化-縮短eclipse的啓動時間

追加: 首先要聲明一下,這個案例在<深刻理解JVM虛擬機>這本書中也提到過. 這本書是我曾經學習JVM的第一本書.裏面關於Heap的優化思想,來源於此.建議你們想學JVM原理的,能夠找來此書看看. 寫這篇文章,是由於最近在給一個社交網站服務器作調優,忽然以爲我機器上的eclipse跑的比較多,因此順便優化下eclipse.至於基於WebSphere服務器的性能調優,這回涉及到更多的工具和方法,會在之後的文章中看到.

最近自從eclipse安裝了不少插件之後,啓動變得很是的慢,每次啓動,要消耗近半分鐘.這是不正常的. 今天決定好好優化一下.

我所使用的eclipse是Eclipse Java EE IDE for Web Developers 3.8版本. 跑在MAC OSX上, SSD+8G RAM, 這麼高性能的機器居然不能秒開eclipse, 這太說不過去了. 哦,還有我使用的JVM是Oracle的HotSpot,來自於JDK1.6 64bit.

首先,在優化前,讓咱們看看eclipse啓動時,JVM的各項性能指標. 由於我並不能準確的斷定eclipse的啓動完成時間, 因此我只能說大約事件.

首先啓動JDK自帶的JVM性能監視工具,在java\bin的目錄下,有一個jvisualvm,它是綁定在JDK中的visualvm.雙擊啓動visualvm. 而後啓動eclipse, 在eclipse啓動完成之後,使用visualvm的查看eclipse的Visual GC狀況, 如圖:

上圖中說明在eclipse的啓動過程當中,JIT對字節碼進行了向機器碼的編譯,花去了22秒的時間.Class加載花去了10秒的時間,Minor GC發生了72次,花去0.64秒,Full GC發生了12次,僅僅花去了61毫秒.

咱們再去MBean選項查看,發現新生代使用ParNew垃圾收集器,而老年代使用的是CMS垃圾收集器.

總上狀況看出,因爲MAC的性能比較好,因此垃圾回收並無消耗太多的時間,而且CMS+ParNew自己就是並行垃圾回收,不會形成用戶程序太多的停頓. 時間主要消耗在了JIT的即時編譯和Class加載上了.

首先要優化的就是class加栽.由於eclipse這個工具是一個成熟的工具,通過了這麼多人的驗證,因此我充分信任eclipse的代碼,容許eclipse的代碼在加載的時候,跳過字節碼驗證. 關閉字節碼驗證的方法是在vm的args中加入參數 -Xverify:none. 對於eclipse來講,找到eclipse.ini, 加入-Xverify:none. 讓咱們再重啓一下eclipse,看看class加載時間是否減少. 再次啓動,發現class加載事件縮小到7秒,比以前少了3秒.

而後優化的是JIT的時間. 在使用eclipse編寫程序時,主要是文本編輯,編譯和運行,JIT雖然能夠帶給咱們高性能,可是JIT在編譯機器碼的時候,卻要消耗不少的時間. eclipse對項目的編譯和運行自己就很慢,切運行時是啓動一個新的java進程,跟eclipse自己無關,因此,我能夠接受拋棄JIT編譯器,而只是用JVM解釋器執行字節碼所帶來的效率下降. 這樣能夠去除JIT編譯的時間. 作法以下,在eclipse.ini中加入vm的參數 -Xint, 意思是隻使用解釋器. 讓咱們來看看結果:

JVM編譯器時間變成了0, 一下減掉20秒. 可是,因爲缺乏了運行時的即時編譯優化方案,代碼的運行時間變長了, eclipse的總體啓動時間慢了更多,超過了30秒. 因而可知,JIT是多麼有用的一項技術.因此禁止JIT的嘗試失敗了.咱們把以前的參數-Xint去掉.

哦,對了,我還裝了不少的插件,尤爲是android開發插件.啓動的時候對插件的激活也會花去不少時間. 屏蔽插件激活的方法: Windows -> Preferences, 輸入 「startup」, 點擊 「Startup and Shutdown」, 把不須要的插件勾掉. 此外,還須要關掉沒必要要的validation,方法爲:Windows -> Preferences -> Validation. 只選你須要的.

作完以上工做,我發現eclipse啓動稍微快了一些. 掐着秒錶計算的花了大約15秒.

最後,再優化一下GC和堆棧吧.雖說,GC已經表現的很好了,都沒有超過1秒,可是GC的頻率如此高,說明JVM的內存的分配是不合理的.爲此,咱們須要從新對JVM內存進行劃分. 爲了對JVM的內存進行合理分配,咱們須要瞭解eclipse啓動過程當中,GC到底發生了什麼事情. 打開gc log的方法以下:

想eclipse.ini的vm參數中添加
-XX:+PrintGCDetails
-Xloggc:/users/joey/Documents/gc.log

啓動eclipse,生成gc.log, 打開log,進行分析.

第一次Minor GC發現,新生代的大小約爲20M. 堆的大小約爲40M. 再接下來的GC中,新生代始終沒有擴容.這說明,新生代的大小合適.
0.720: [GC 0.720: [ParNew: 17024K->2112K(19136K), 0.0099529 secs] 17024K->2324K(38848K), 0.0100285 secs] [Times: user=0.03 sys=0.00, real=0.01 secs] 

第一次發生Full GC時,發現老年代已經擴容到約93M,而永生代擴容到約128M
67.213: [Full GC (System) 67.213: [CMS: 57969K->57877K(93124K), 0.3563491 secs] 62179K->57877K(112260K), [CMS Perm : 80490K->80392K(128708K)], 0.3565176 secs] [Times: user=0.36 sys=0.00, real=0.36 secs]

而直到最後一次GC, 老年代佔用也沒超過125M,永生帶佔用也沒有超過125M. 但他們的佔用空間均超過了100M. 由此,咱們有理由規定一個初始堆大小. 最終,經過分析,我給eclipse.ini添加了以下幾個參數:

-server
-Xverify:none
-XX:PermSize=128m
-XX:MaxPermSize=256m
-Xms256m
-Xmx512m
-Xmn40m
-Xss2m

-server是讓JVM以server模式運行,加劇JIT的優化做用,因爲eclipse是常常開着不關,在server模式下,JIT會隨着運行的時間,把字節碼更深入的變成成機器代碼.加快運行速度.
-Xverify:none, 跳過對字節碼的驗證.
PermSize永生帶設置爲128M,堆的初始大小設置爲256M,新生代站了40M. 每一個線程棧大小設爲2M.

在這種設置下,Full GC已經徹底消失,但仍是剩下了20次左右的Minor GC,大約花掉0.3秒, 這是能夠接受的. 若是爲了徹底消除GC而把新生代的空間設大,那也是一種內存的浪費. 重啓eclipse,啓動時間已經落在了15秒以內.如圖: