Eclipse.ini里面很久以前为了让程序运行快点改过堆分配大小,其参数配置的改变只是固定了堆的大小,为此增加了两行:
今天突然想玩玩调优,稍微看来一点资料打算就开干了,我也不喜欢纸上谈兵那种只在没意思,也想把这个过程记录下来和大家分享一下,实现说明一下我对JVM的内存分配方式和GC机制只是稍微有点了解,如果有说错的地方请不要拍砖,请指正,也可以给我发邮件,[email protected]我的邮箱。
首先,增加了GC日志,在eclipse.ini后面加上四行:
关闭eclipse所有项目,然后重启
此时在eclipse目录下会出现gc.log这个日志文件,以下是内容:
首先解释一下这个日志的格式
拿第一行来做例子:
2.321:是时间点,网上没有找到这个具体的定义,但是估计是从系统启动到执行这条GC的时间。
Full GC 2.321 :是指明GC方式,通常将对新生代迚行的回收称为Minor GC;对旧生代迚行的回收称为Major GC,但由于Major GC除并发GC外均需对整个堆以及持久代逆行扫描和回收,因此又称为Full GC。
[Tenured: 0K->19557K(349568K), 0.1294009 secs] 95872K->19557K(506816K):这个是说明了Thnured generation的回收情况,同理如果是“GC”则是针对Young generation的回收,如果是Perm测试持久代的回收。其中0K->19557K(349568K)说明的是旧生代的分配情况,(这里说明一点,GC不仅是负责垃圾回收的,而且也决定内存的分配)我们可以看到旧生代从0k分配到了19557K,可以分配的空间为34956K,然后是分配时间为0.1294009秒,这里是动态分配的信息,紧跟在后面的是回收的信息,前面是回收时间点的Heap实际的使用量,后面是回收之后的Heap使用量。(后面的Perm的信息也和这一样)。
[Times: user=0.13 sys=0.00, real=0.13 secs] :这个说明了我并没有找到相应的说明,但是我的理解是回收过程的时间组成,user表示是该用户使用的时间,sys表示的是系统使用的时间,real就是实际使用时间,应该是user和sys的和。
有了以上的说明我可以开始对这个日志做一下分析:
(在word里面拷贝的这个日志会换行,建议拷贝到编辑器里面查看,方便做对比。)
看看三个红框里面的数据这个是可用值,看看这些值的变化规律,只有持久代的可用值在不断的增大,由此基本可以判断出这几次Full GC是由于重新分配持久代的内存空间造成的(当然造成Full GC的原因不止这一种,我现在也没有都记住,还是在实践中加强记忆来得快)。
很明显,持久代的空间在启动的额过程中明显不足,那么就增加持久代的空间分配,要为持久代分配空间就必须使用–XX:PermSize–XX:MaxPermSize这个参数,简单计算一下,这次启动完后没有任何动作的情况下持久代的可用空间使用为45056/1024=44M,那么应该设置为多少最好呢,这得从这个代里面存放的内容入手,这个代里面是JVM的方法区,主要是存放一些方法字节码和静态变量,还会放些什么我暂时也不知道,但是应该不会太多,所以我认为持久代的大小应该是相对比较固定大小的波动不会太大的,在整个程序的运行过程中不会有非常大的变化,由于我使用的eclipse是已经装过插件的,以后再扩展插件的几率很小,所以我选择将–XX:PermSize=64M –XX:MaxPermSize=96M,在运行试试看(中间NG了一次结果和没优化一样,原因是-Xx的前面那个中画线貌似不识别,可能是中文输入法的问题,建议在E文输入法中来敲参数,否则设置错误的话失败了都很难找出问题),感觉启动快多了,看看日志:
|
|
哈哈,已经不再有Full GC,第一步优化成功启动速度减少了19秒,相当可观,去dota一把了,明天看看还能怎么继续优化。