最近自從eclipse安裝了很多插件以後啟動變得非常的慢每次啟動要消耗近半分鐘這是不正常的 今天決定好好優化一下
我所使用的eclipse是Eclipse Java EE IDE for Web Developers 版本 跑在MAC OSX上 SSD+G RAM 這麼高性能的機器竟然不能秒開eclipse 這太說不過去了 哦還有我使用的JVM是Oracle的HotSpot來自於JDK bit
首先在優化前讓我們看看eclipse啟動時JVM的各項性能指標 因為我並不能准確的判定eclipse的啟動完成時間 所以我只能說大約事件
首先啟動JDK自帶的JVM性能監視工具在java\bin的目錄下有一個jvisualvm它是綁定在JDK中的visualvm雙擊啟動 visualvm 然後啟動eclipse 在eclipse啟動完成以後使用visualvm的查看eclipse的Visual GC情況 如圖:
上圖中說明在eclipse的啟動過程中JIT對字節碼進行了向機器碼的編譯花去了秒的時間Class加載花去了秒的時間Minor GC發生了次花去秒Full GC發生了次僅僅花去了毫秒
我們再去MBean選項查看發現新生代使用ParNew垃圾收集器而老年代使用的是CMS垃圾收集器
總上情況看出由於MAC的性能比較好所以垃圾回收並沒有消耗太多的時間並且CMS+ParNew本身就是並行垃圾回收不會造成用戶程序太多的停頓 時間主要消耗在了JIT的即時編譯和Class加載上了
首先要優化的就是class加栽因為eclipse這個工具是一個成熟的工具經過了這麼多人的驗證所以我充分信任eclipse的代碼允許 eclipse的代碼在加載的時候跳過字節碼驗證 關閉字節碼驗證的方法是在vm的args中加入參數 Xverify:none 對於eclipse來說找到eclipseini 加入Xverify:none 讓我們再重啟一下eclipse看看class加載時間是否減小 再次啟動發現class加載事件縮小到秒比之前少了秒
然後優化的是JIT的時間 在使用eclipse編寫程序時主要是文本編輯編譯和運行JIT雖然可以帶給我們高性能但是JIT在編譯機器碼的時候卻要消耗很多的時間 eclipse對項目的編譯和運行本身就很慢切運行時是啟動一個新的java進程跟eclipse本身無關所以我可以接受拋棄JIT編譯器而只是用JVM解釋器執行字節碼所帶來的效率降低 這樣可以去除JIT編譯的時間 做法如下在eclipseini中加入vm的參數 Xint 意思是只使用解釋器 讓我們來看看結果:
JVM編譯器時間變成了 一下減掉秒 但是由於缺少了運行時的即時編譯優化方案代碼的運行時間變長了 eclipse的整體啟動時間慢了更多超過了秒 由此可見JIT是多麼有用的一項技術所以禁止JIT的嘗試失敗了我們把之前的參數Xint去掉
哦對了我還裝了很多的插件尤其是android開發插件啟動的時候對插件的激活也會花去很多時間 屏蔽插件激活的方法: Windows > Preferences 輸入 startup 點擊 Startup and Shutdown 把不需要的插件勾掉 此外還需要關掉不必要的validation方法為:Windows > Preferences > Validation 只選你需要的
做完以上工作我發現eclipse啟動稍微快了一些 掐著秒表計算的花了大約秒
最後再優化一下GC和堆棧吧雖然說GC已經表現的很好了都沒有超過秒但是GC的頻率如此高說明JVM的內存的分配是不合理的為此我們需要重新對JVM內存進行劃分 為了對JVM的內存進行合理分配我們需要了解eclipse啟動過程中GC到底發生了什麼事情 打開gc log的方法如下:
想eclipseini的vm參數中添加
XX:+PrintGCDetails
Xloggc:/users/joey/Documents/gclog
啟動eclipse生成gclog 打開log進行分析
第一次Minor GC發現新生代的大小約為M 堆的大小約為M 再接下來的GC中新生代始終沒有擴容這說明新生代的大小合適
: [GC : [ParNew: K>K(K) secs] K>K(K) secs] [Times: user= sys= real= secs]
第一次發生Full GC時發現老年代已經擴容到約M而永生代擴容到約M
: [Full GC (System) : [CMS: K>K(K) secs] K>K(K) [CMS Perm : K>K(K)] secs] [Times: user= sys= real= secs]
而直到最後一次GC 老年代占用也沒超過M永生帶占用也沒有超過M 但他們的占用空間均超過了M 由此我們有理由規定一個初始堆大小 最終通過分析我給eclipseini添加了如下幾個參數:
server
Xverify:none
XX:PermSize=m
XX:MaxPermSize=m
Xmsm
Xmxm
Xmnm
Xssm
server是讓JVM以server模式運行加重JIT的優化作用由於eclipse是經常開著不關在server模式下JIT會隨著運行的時間把字節碼更深刻的變成成機器代碼加快運行速度
Xverify:none 跳過對字節碼的驗證
PermSize永生帶設置為M堆的初始大小設置為M新生代站了M 每個線程棧大小設為M
在這種設置下Full GC已經完全消失但還是剩下了次左右的Minor GC大約花掉秒 這是可以接受的 如果為了完全消除GC而把新生代的空間設大那也是一種內存的浪費 重啟eclipse啟動時間已經落在了秒之內如圖:
From:http://tw.wingwit.com/Article/program/Java/hx/201311/26314.html
