接着昨天的幹，首先看看昨天的日誌，兩次都是minoj GC,舊生代和持久代都沒有可用GC，研究的重點就是這兩次GC，從日誌的最後HEAP信息來看
Heap
def new generation total 157248K, used 19646K [0x04b00000, 0x0f5a0000, 0x0f5a0000)
eden space 139776K, 9% used [0x04b00000, 0x05788208, 0x0d380000)
from space 17472K, 38% used [0x0d380000, 0x0da27790, 0x0e490000)
to space 17472K, 0% used [0x0e490000, 0x0e490000, 0x0f5a0000)
tenured generation total 349568K, used 19156K [0x0f5a0000, 0x24b00000, 0x24b00000)
the space 349568K, 5% used [0x0f5a0000, 0x108553c8, 0x10855400, 0x24b00000)
compacting perm gen total 65536K, used 40825K [0x24b00000, 0x28b00000, 0x2ab00000)
the space 65536K, 62% used [0x24b00000, 0x272de638, 0x272de800, 0x28b00000)
No shared spaces configured.
舊生代的的使用率爲5%，而新生代的的使用率特別是from這一塊已經是38%，我推測是對象由於eden晉升到from導致哦那關鍵不足的時候導致的GC(我還沒有找到監控eden和from，to的內存變化的方法，jConsole的話是可以看到，但是前提是要先讓程序啓動找到PID，，這樣一來又來不急開jConsole，很麻煩，所以暫時放棄)，看看新生代的空間爲154M，先將其設置爲200M，即增加參數-Xmn256M,果然有效果，看看日誌
Gc3.log
4.367: [GC 4.368: [DefNew: 209792K->21157K(235968K), 0.0987968 secs] 209792K->21157K(498112K), 0.0989220 secs] [Times: user=0.08 sys=0.01, real=0.10 secs]
Heap
def new generation total 235968K, used 115536K [0x10010000, 0x20010000, 0x20010000)
eden space 209792K, 44% used [0x10010000, 0x15c3ac40, 0x1ccf0000)
from space 26176K, 80% used [0x1e680000, 0x1fb296e8, 0x20010000)
to space 26176K, 0% used [0x1ccf0000, 0x1ccf0000, 0x1e680000)
tenured generation total 262144K, used 0K [0x20010000, 0x30010000, 0x30010000)
the space 262144K, 0% used [0x20010000, 0x20010000, 0x20010200, 0x30010000)
compacting perm gen total 65536K, used 40839K [0x30010000, 0x34010000, 0x36010000)
the space 65536K, 62% used [0x30010000, 0x327f1fa0, 0x327f2000, 0x34010000)
No shared spaces configured.
這次只有一次GC，新生代的使用率得到了提高，舊生代貌似沒有被使用，效果不錯，但是這次的調優對啓動速度的影響沒有昨天那麼明顯。
接下來需要優化的是看看eclipse在持續運行過程中的GC情況並加以優化，這樣需要打開一些項目，看eclipse在初始化項目的時候會做什麼樣的GC，今天要回家，估計結果一時半出不來，等結果出來了我再整理一下發出來。
