優化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秒之內.如圖: