性能優(yōu)化從身邊做起。
首先建立評估體系，將workspace里所有的項目close掉，關(guān)閉eclipse。優(yōu)化的用例就是啟動eclipse，open一個項目，eclipse會自動build這個項目，保證沒有感覺到明顯的卡，也就是沒有full GC。
開始：
eclipse.ini里加入打印gc情況的參數(shù)：
| -XX:+PrintGCTimeStamps |
| -XX:+PrintGCDetails |
| -verbose:gc |
| -Xloggc:gc.log |
這樣eclipse在運行過程中會記錄gc日志，顯示詳細(xì)的gc情況，并打印在gc.log中，通過分析這個日志尋找eclipse的性能瓶頸和優(yōu)化方式。
我最初的參數(shù)只是在原版基礎(chǔ)上調(diào)了堆大小
將堆初始化和最大值設(shè)為一樣，消除堆大小根據(jù)當(dāng)前堆使用情況而變化帶來的影響。
啟動eclipse，發(fā)現(xiàn)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秒多時間里共出現(xiàn)了8次full gc，所以啟動慢，覺得啟動時候挺卡的。從日志里可以看出來 FullGC主要是在回收tenured區(qū)和Perm區(qū)，其中Perm一直都是快滿的狀態(tài)，Perm : 24574K->24554K(24576K)，Perm大小在不斷調(diào)整，所以需要固定Perm區(qū)的大小，保證夠用，eclipse.ini里加入
| -XX:PermSize=64m |
| -XX:MaxPermSize=64m |
再啟動：發(fā)現(xiàn)沒有full gc了只有數(shù)量比較多的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次， 而內(nèi)存回收率還是蠻高的 young區(qū)18880-1985=16895 jvm 46992-30098=16894 都快接近100%了，可以看出young區(qū)是由小到大在不斷調(diào)整大小，所以不斷GC，因此設(shè)一個初始值吧，據(jù)說設(shè)置heap的1/4比較好，那就是128M，所以eclipse.ini加入
再重啟，發(fā)現(xiàn)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，感覺有點小卡，發(fā)現(xiàn)日志里多了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區(qū)和Perm都還沒到很接近最大值，但是為什么還有full GC呢，開始以為是JVM悲觀認(rèn)為Tenured區(qū)剩余空間不足以應(yīng)對下一次minor GC 所以進(jìn)行了full GC調(diào)整Tenured空間，索性直接增加了堆最大值到-Xmx728m（工作電腦的內(nèi)存是3.5G），但重啟后full gc還是有4次，而且有幾次minor GC用的時間超過了0.1秒，這是因為增加了堆大小，導(dǎo)致GC用時也增加了，不能接受。所以還是改回-Xmx512m。
再仔細(xì)觀察日志，發(fā)現(xiàn)Full GC (System) 字樣，這個意思是eclipse里調(diào)用了System.gc()手動觸發(fā)了系統(tǒng)GC，好吧，哥已經(jīng)給你分配足夠空間了，你就省省吧，在eclipse.ini里加入：
這樣就差不多了，整個過程沒有出現(xiàn)full gc，再編碼2個小時，中間只出現(xiàn)了一次full gc，在open build某50W行+的代碼的時候，eclipse還是卡了…
最后又稍微調(diào)了一下各代的大小，得到目前的參數(shù)：
| -Xms512m |
| -Xmx512m |
| -XX:PermSize=96m |
| -XX:MaxPermSize=96m |
| -Xmn168m |
| -XX:+DisableExplicitGC |
另外沒有去調(diào)GC策略，主要是覺得eclipse是客戶端程序，默認(rèn)的client單線程的GC策略應(yīng)該是比較適合的，以后有時間再試試看吧。
