轉自：http://www.javaeye.com/topic/756538#1659035
首先建立評估體系，將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的性能瓶頸和優化方式。
我最初的參數只是在原版基礎上調了堆大小
將堆初始化和最大值設為一樣，消除堆大小根據當前堆使用情況而變化帶來的影響。
啟動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加入
再重啟，發現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里加入：
這樣就差不多了，整個過程沒有出現full gc，再編碼2個小時，中間只出現了一次full gc，在open build某50W行+的代碼的時候，eclipse還是卡了…
最后又稍微調了一下各代的大小，得到目前的參數：
| -Xms512m |
| -Xmx512m |
| -XX:PermSize=96m |
| -XX:MaxPermSize=96m |
| -Xmn168m |
| -XX:+DisableExplicitGC |
另外沒有去調GC策略，主要是覺得eclipse是客戶端程序，默認的client單線程的GC策略應該是比較適合的，以后有時間再試試看吧。