接着昨天的干，首先看看昨天的日志，两次都是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，今天要回家，估计结果一时半出不来，等结果出来了我再整理一下发出来。