最佳化JVM參數提升Eclipse運行速度

來源:互聯網
上載者:User

標籤:http   java   使用   os   io   檔案   資料   ar   

 

http://www.iteye.com/topic/1117534

 

 首先建立評估體系,將workspace裡所有的項目close掉,關閉eclipse。最佳化的用例就是啟動eclipse,open一個項目,eclipse會自動build這個項目,保證沒有感覺到明顯的卡,也就是沒有full GC。  

開始:  

eclipse.ini裡加入列印gc情況的參數:

-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-verbose:gc
-Xloggc:gc.log

這樣eclipse在運行過程中會記錄gc日誌,顯示詳細的gc情況,並列印在gc.log中,通過分析這個日誌尋找eclipse的效能瓶頸和最佳化方式。  
我最初的參數只是在原版基礎上調了堆大小  

-Xms512m
-Xmx512m

將堆初始化和最大值設為一樣,消除堆大小根據當前堆使用方式而變化帶來的影響。  
啟動eclipse,發現gc.log裡打出了很多full gc的日誌  

引用4.226: [Full GC 4.226: [Tenured: 18470K->19304K(30544K), 0.1159544 secs] 25154K->19304K(44368K), [Perm : 24574K->24554K(24576K)], 0.1160431 secs] [Times: user=0.13 sys=0.00, real=0.13 secs]

在啟動的6秒多時間裡共出現了8次full gc,所以啟動慢,覺得啟動時候挺卡的。從日誌裡可以看出來 FullGC主要是在回收tenured區和Perm區,其中Perm一直都是快滿的狀態,Perm : 24574K->24554K(24576K),Perm大小在不斷調整,所以需要固定Perm區的大小,保證夠用,eclipse.ini裡加 入  

-XX:PermSize=64m
-XX:MaxPermSize=64m

再啟動:發現沒有full gc了只有數量比較多的minor gc,挑啟動開始到啟動完成的第一條和最後一條日誌  

引用0.209: [GC 0.209: [DefNew: 4416K->511K(4928K), 0.0034707 secs] 4416K->614K(15872K), 0.0035239 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]  
….  
6.383: [GC 6.383: [DefNew: 18880K->1985K(21184K), 0.0055311 secs] 46992K->30098K(68040K), 0.0055694 secs]

 

這6秒中GC日誌打了69次, 而記憶體回收率還是蠻高的 young區18880-1985=16895 jvm 46992-30098=16894 都快接近100%了,可以看出young區是由小到大在不斷調整大小,所以不斷GC,因此設一個初始值吧,據說設定heap的1/4比較好,那就是 128M,所以eclipse.ini加入  

-Xmn128m

再重啟,發現GC日誌就四條了,eclipse啟動自然快了  

引用1.292: [GC 1.292: [DefNew: 104960K->10984K(118016K), 0.0334165 secs] 104960K->10984K(511232K), 0.0334603 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]  
2.182: [GC 2.182: [DefNew: 115944K->1852K(118016K), 0.0221714 secs] 115944K->11466K(511232K), 0.0222142 secs] [Times: user=0.00 sys=0.02, real=0.02 secs]  
3.987: [GC 3.987: [DefNew: 106779K->12531K(118016K), 0.0378228 secs] 116393K->22145K(511232K), 0.0378692 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]  
5.377: [GC 5.377: [DefNew: 117491K->9403K(118016K), 0.0513728 secs] 127105K->31364K(511232K), 0.0514133 secs]

但是,啟動後open我的多重專案,這些項目互相依賴,eclipse自動build,感覺有點小卡,發現日誌裡多了4次full GC,所以就卡了…  

引用67.320: [Full GC (System) 67.320: [Tenured: 88847K->68809K(393216K), 0.2121213 secs] 117385K->68809K(511232K), [Perm : 41915K->41915K(65536K)], 0.2121747 secs] [Times: user=0.20 sys=0.00, real=0.20 secs]  
103.759: [Full GC (System) 103.759: [Tenured: 81882K->66784K(393216K), 0.3287387 secs] 185350K->66784K(511232K), [Perm : 53464K->53414K(65536K)], 0.3287897 secs] [Times: user=0.33 sys=0.00, real=0.33 secs]

這個時候Tenured區和Perm都還沒到很接近最大值,但是為什麼還有full GC呢,開始以為是JVM悲觀認為Tenured區剩餘空間不足以應對下一次minor GC 所以進行了full GC調整Tenured空間,索性直接增加了堆最大值到-Xmx728m(工作電腦的記憶體是3.5G),但重啟後full gc還是有4次,而且有幾次minor GC用的時間超過了0.1秒,這是因為增加了堆大小,導致GC用時也增加了,不能接受。所以還是改回-Xmx512m。  
再仔細觀察日誌,發現Full GC (System) 字樣,這個意思是eclipse裡調用了System.gc()手動觸發了系統GC,好吧,哥已經給你分配足夠空間了,你就省省吧,在eclipse.ini裡加入:  

-XX:+DisableExplicitGC

這樣就差不多了,整個過程沒有出現full gc,再編碼2個小時,中間只出現了一次full gc,在open build某50W行+的代碼的時候,eclipse還是卡了…  
最後又稍微調了一下各代的大小,得到目前的參數:  

-Xms512m
-Xmx512m
-XX:PermSize=96m
-XX:MaxPermSize=96m
-Xmn168m
-XX:+DisableExplicitGC

另外沒有去調GC策略,主要是覺得eclipse是用戶端程式,預設的client單線程的GC策略應該是比較適合的,以後有時間再試試看吧。

JAVA 虛擬機器預設分配64M記憶體,如果你的應用比較大,超出64M內 存,Java虛擬機器就會拋出outOfMemoryError,並停止運行。不管是什麼應用(Web應用、Application等),只需要修改你的機 器上的運行Java命令,在javaxxx命令中添加-Xms(最小使用記憶體)、-Xmx(最大使用記憶體)即可解決。當然,這兒的記憶體容量都是指物理內 存,不能超出你的機器的實體記憶體的總容量。

    對於單獨的.class,可以用下面的方法對Test運行時的jvm記憶體進行設定。
java -Xms64m -Xmx256m Test
-Xms是設定記憶體初始化的大小
-Xmx是設定最大能夠使用記憶體的大小(最好不要超過實體記憶體大小)

在eclipse中的設定方法

方 法1:對應在Eclipse中的設定為:視窗->喜好設定->JAVA->已安裝的JRE,在缺 省的VM自變數中增加:-Xmx256M (也可以添加其他參數如-Xms128M -XX:PermSize=64M -XX:MaxPermSize=128M)

方法2:修改eclipse.ini
-vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M
這裡有幾個問題:
1. 各個參數的含義什嗎?
2. 為什麼有的機器我將-Xmx和-XX:MaxPermSize都設定為512M之後Eclipse可以啟動,而有些機器無法啟動? 
3. 為何將上面的參數寫入到eclipse.ini檔案Eclipse沒有執行對應的設定?
下面我們一一進行回答
1. 各個參數的含義什嗎?
參數中-vmargs的意思是設定JVM參數,所以後面的其實都是JVM的參數了,我們首先瞭解一下JVM記憶體管理的機制,然後再解釋每個參數代表的含義。
堆(Heap)和非堆(Non-heap)記憶體
按 照官方的說法:“JAVA 虛擬機器具有一個堆,堆是運行時資料區域,所有類執行個體和數組的記憶體均從此處分配。堆是在 JAVA 虛擬機器啟動時建立的。”“在JVM中堆之外的記憶體稱為非堆記憶體(Non-heap memory)”。可以看出JVM主要管理兩種類型的記憶體:堆和非堆。簡單來說堆就是Java代碼可及的記憶體,是留給開發人員使用的;非堆就是JVM留給 自己用的,所以方法區、JVM內部處理或最佳化所需的記憶體(如JIT編譯後的代碼緩衝)、每個類結構(如運行時常數池、欄位和方法資料)以及方法和構造方法 的代碼都在非堆記憶體中。
堆記憶體配置
JVM初始分配的記憶體由-Xms指定,預設是實體記憶體的1/64;JVM最大分配的記憶體由-Xmx指 定,預設是實體記憶體的1/4。預設空餘堆記憶體小於 40%時,JVM就會增大堆直到-Xmx的最大限制;空餘堆記憶體大於70%時,JVM會減少堆直到-Xms的最小限制。因此伺服器一般設定-Xms、 -Xmx相等以避免在每次GC 後調整堆的大小。
非堆記憶體配置
JVM使用-XX:PermSize設定非堆記憶體初始值,預設是實體記憶體的1/64;由XX:MaxPermSize設定最大非堆記憶體的大小,預設是實體記憶體的1/4。
JVM記憶體限制(最大值)
首 先JVM記憶體限制於實際的最大實體記憶體(廢話!呵呵),假設實體記憶體無限大的話,JVM記憶體的最大值跟作業系統有很大的關係。簡單的說就32位處理器雖然 可控記憶體空間有4GB,但是具體的作業系統會給一個限制,這個限制一般是2GB-3GB(一般來說Windows系統下為1.5G-2G,Linux系統 下為2G-3G),而64bit以上的處理器就不會有限制了。
2. 為什麼有的機器我將-Xmx和-XX:MaxPermSize都設定為512M之後Eclipse可以啟動,而有些機器無法啟動? 
通過上面對JVM記憶體管理的介紹我們已經瞭解到JVM記憶體包含兩種:堆記憶體和非堆記憶體,另外JVM最大記憶體首先取決於實際的實體記憶體和作業系統。所以說設定VM參數導致程式無法啟動主要有以下幾種原因:
1) 參數中-Xms的值大於-Xmx,或者-XX:PermSize的值大於-XX:MaxPermSize;
2) -Xmx的值和-XX:MaxPermSize的總和超過了JVM記憶體的最大限制,比如當前作業系統最大記憶體限制,或者實際的實體記憶體等等。說到實際物理 記憶體這裡需要說明一點的是,如果你的記憶體是1024MB,但實際系統中用到的並不可能是1024MB,因為有一部分被硬體佔用了。
3. 為何將上面的參數寫入到eclipse.ini檔案Eclipse沒有執行對應的設定? 
那為什麼同樣的參數在捷徑或者命令列中有效而在eclipse.ini檔案中是無效的呢?這是因為我們沒有遵守eclipse.ini檔案的設定規則:
參數形如“項 值”這種形式,中間有空格的需要換行書寫,如果值中有空格的需要用雙引號包括起來。比如我們使用-vm C:\Java\jre1.6.0\bin\javaw.exe參數設定虛擬機器,在eclipse.ini檔案中要寫成這樣:
-vm

C:\Java\jre1.6.0\bin\javaw.exe
按照上面所說的,最後參數在eclipse.ini中可以寫成這個樣子:
-vmargs
-Xms128M
-Xmx512M
-XX:PermSize=64M
-XX:MaxPermSize=128M
實際啟動並執行結果可以通過Eclipse中“Help”-“About Eclipse SDK”視窗裡面的“Configuration Details”按鈕進行查看。

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.