JVM角度調(diào)試優(yōu)化MyEclipse

更新時間：2016年05月17日 09:39:31 作者：GameKing

這篇文章主要介紹了從JVM角度對MyEclipse進行調(diào)試優(yōu)化，為大家分析調(diào)試優(yōu)化MyEclipse的步驟，感興趣的小伙伴們可以參考一下

在將工作電腦的操作系統(tǒng)更換為win7之后，我的MyEclipse的啟動速度和運行速率一直很不理想。特別是在同時修改調(diào)試多個頁面模板的時候，來回切換兩個文件總是會卡個十來秒。試過關掉各種插件和驗證也無濟于事。于是在大致的研究完JVM后，決定從JVM的角度來試著解決這個問題。

啟動優(yōu)化：

首先來看下我的myeclipse.ini里面的默認啟動參數(shù)：

-Xmx512m ：設置堆內(nèi)存最大值為512M
-XX:MaxPermSize=256m ：設置持久代最大值為256m
-XX:ReservedCodeCacheSize=64m ：設置代碼占用的內(nèi)存大小為64m

從啟動參數(shù)上看不出什么，于是往里面加入打印內(nèi)存變化相關參數(shù)：

-XX:+PrintGCTimeStamps : 打印每次GC的時間戳
-XX:+PrintGCDetails ： 打印每次GC的詳細信息
-Xloggc:myEclipseGC.log ：將GC的記錄輸出到文件
-verbose:gc : 輸出每次GC的相關情況

然后啟動MyEclipse，然后查看myEclipseGC.log里面的信息：

啟動耗時大概在30秒左右，選擇性的截取一小部分日志，可以看到，在myeclipse啟動的前10秒內(nèi)，JVM總共執(zhí)行了300多次的GC和9次的FULL GC。

從GC頻率和信息可以看出內(nèi)存的回收率很高，且大小在不斷調(diào)整，這應該是由于年輕代的空間不足導致，需要設定一個不小的初始值。

然后來重點關注FULL GC：

復制代碼代碼如下:

961: [Full GC 5.961: [Tenured: 34568K->34456K(49676K), 0.1397651 secs] 35336K->34456K(53452K), [Perm : 26623K->26458K(26624K)], 0.1398562 secs] [Times: user=0.14 sys=0.00, real=0.14 secs]

030: [Full GC 9.030: [Tenured: 53310K->52332K(64588K), 0.2034757 secs] 56020K->52332K(69516K), [Perm : 43007K->42996K(43008K)], 0.2036030 secs] [Times: user=0.20 sys=0.00, real=0.20 secs]

從兩次日志的對比中可以看到，F(xiàn)ULL GC主要是在回收Tenured和Perm這兩個區(qū)域，并且這兩個區(qū)域的大小都在不斷的調(diào)整中，所以決定先把它們的大小固定下來。

于是調(diào)整后的參數(shù)如下：

-Xms512m ：設定堆的最小值為512m
-Xmn192m : 設定年輕代的大小為192m
-XX:PermSize=192m : 設定持久代的初始值為192m
-XX:MaxPermSize=192m
-XX:ReservedCodeCacheSize=64m
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-Xloggc:myEclipseGC.log
-verbose:gc

重新啟動一次MyEclipse，查看日志信息：

啟動耗時12秒左右，從日志可以看出，在前10秒內(nèi)總共只進行了5次GC，不涉及各區(qū)域大小的調(diào)整，這個結果還是可以接受的，因為工作時不怎么需要頻繁重啟。

工作響應速度優(yōu)化：

接下來研究困擾了我很久的來回切換html文件時的經(jīng)常性延時和大卡問題，為了更直觀的研究JVM的內(nèi)存變化，決定借助jconsole這個java自帶的輔助工具。先把myeclipse.ini的參數(shù)還原，避免被第一階段的優(yōu)化干擾。

啟動myeclipse，啟動jconsole并接入myeclipse所在的JVM，穩(wěn)定后的整個堆的內(nèi)存圖如下：

接下來試著打開幾個模板，然后觀察內(nèi)存的變化。

首先是堆內(nèi)存的整體使用情況：

可以看到，在打開了幾個模板之后，堆內(nèi)存的使用從原先的100M以下突增至300M以上。使用量增加了三倍，但是還在我設置的512M范圍之內(nèi)。所以可以暫時不考慮繼續(xù)增加堆內(nèi)存，轉而考慮調(diào)整各區(qū)內(nèi)存大小比例問題。

于是觀察下各個區(qū)在這段時間的內(nèi)存使用情況，其中，Eden區(qū)如下：

Eden區(qū)在這段時間的內(nèi)存使用率大增，且發(fā)生了多次GC。通過底下的監(jiān)控信息可以知道，eden區(qū)在默認情況下只分配了31M的最大內(nèi)存，這顯然是不夠用的。稍微執(zhí)行點操作都會觸發(fā)eden區(qū)的GC，這應該是模板打開切換發(fā)生延時卡頓的原因之一，需要調(diào)整。

接下來是Tenured區(qū)：

JVM默認給這個區(qū)域分配的最大空間是470M。隨著內(nèi)存使用的變化，這個區(qū)域的實際大小一直在調(diào)整，每次區(qū)域大小的調(diào)整都會發(fā)生FULL GC，這應該是經(jīng)常性大卡的原因之一。而新模板的打開是觸發(fā)這種調(diào)整的主要原因。從這個區(qū)域內(nèi)存的使用上來看，將這個區(qū)域的內(nèi)存空間維持并固定在450M左右，保持一定的冗余還是有必要的。

從這點來看，jvm的堆內(nèi)存還是有必要稍微擴充下以維持一個較大的Tenured區(qū)和Eden區(qū)。

最后來看下perm區(qū)：

作為方法區(qū)的一部分，這個區(qū)域的內(nèi)存變化并不大，并且比較穩(wěn)定，本來不需要留太多的冗余。但是考慮到當前打開的工程實際代碼量并不大，決定暫時維持在128M左右，日后慢慢調(diào)整。

于是根據(jù)上面的分析將參數(shù)調(diào)整為：

-Xmx768m
-Xms768m
-Xmn256m
-XX:PermSize=192m
-XX:MaxPermSize=192m
-XX:ReservedCodeCacheSize=64m

重啟myeclipse，接入Jconsole，同時打開三十來個模板做了下測試。在觀查各個區(qū)的內(nèi)存使用率時發(fā)現(xiàn)一個問題，在將年輕代調(diào)整為256M以后，由于Eden不再頻繁的發(fā)生GC，進入 Tenured區(qū)的數(shù)據(jù)量明顯減少，Tenured區(qū)的內(nèi)存使用圖如下：