启动变得非常的慢,最近自从eclips装置了很多插件以后.每次启动,要消耗近半分钟.这是不正常的.今天决定好好优化一下.SSD+8GRA M,所使用的eclipsEclipsJavaEEIDEforWebDevelop3.8版本.跑在MA COSX上.这么高性能的机器竟然不能秒开eclipse,这太说不过去了.哦,还有我使用的JVMOraclHotSpot,来自于JDK1.664bit.优化前,首先.让我看看eclips启动时,JVM各项性能指标.因为我并不能准确的判定eclips启动完成时间,所以我只能说大约事件.java\bin目录下,首先启动JDK自带的JVM性能监视工具.有一个jvisualvm,绑定在JDK中的visualvm.双击启动 visualvm.然后启动eclipse,eclips启动完成以后,使用visualvm检查eclipsVisualGC情况,
JIT对字节码进行了向机器码的编译,说明在eclips启动过程中.花去了22秒的时间.Class加载花去了10秒的时间,MinorGC发生了72次,花去0.64秒,FullGC发生了12次,仅仅花去了61毫秒.发现新生代使用ParNew垃圾收集器,再去MBean选项检查.而老年代使用的CMS垃圾收集器.由于MA C性能比较好,总上情况看出.所以垃圾回收并没有消耗太多的时间,并且CMS+ParNew自身就是并行垃圾回收,不会造成用户顺序太多的停顿.时间主要消耗在JIT即时编译和Class加载上了.经过了这么多人的验证,首先要优化的就是class加栽.因为eclips这个工具是一个成熟的工具.所以我充分信任eclips代码,允许 eclips代码在加载的时候,跳过字节码验证.关闭字节码验证的方法是vmarg中加入参数 -Xverify:none.对于eclips来说,找到eclipse.ini,加入-Xverify:none.让我再重启一下eclipse,看看class加载时间是否减小.再次启动,发现class加载事件缩小到7秒,比之前少了3秒.
主要是文本编辑,然后优化的JIT时间.使用eclips编写顺序时.编译和运行,JIT虽然可以带给我高性能,但是JIT编译机器码的时候,却要消耗很多的时间.eclips对项目的编译和运行自身就很慢,切运行时是启动一个新的java进程,跟eclips自身无关,所以,可以接受抛弃JIT编译器,而只是用JVM解释器执行字节码所带来的效率降低.这样可以去除JIT编译的时间.做法如下,eclipse.ini中加入vm参数 -Xint,意思是只使用解释器.让我来看看结果:一下减掉20秒.但是,JVM编译器时间变成了0.由于缺少了运行时的即时编译优化方案,代码的运行时间变长了,eclips整体启动时间慢了更多,超越了30秒.由此可见,JIT多么有用的一项技术.所以禁止JIT尝试失败了.把之前的参数-Xint去掉.
对了,哦.还装了很多的插件,尤其是android开发插件.启动的时候对插件的激活也会花去很多时间.屏蔽插件激活的方法:Window->Preferences,输入 startup,点击 StartupandShutdown,把不需要的插件勾掉.此外,还需要关掉不必要的validation,方法为:Window->Prefer->Validation.只选你需要的.发现eclips启动稍微快了一些.掐着秒表计算的花了大约15秒做完以上工作，再优化一下GC和堆栈吧.虽然说,最后.GC已经表示的很好了,都没有超过1秒,但是GC频率如此高,说明JVM内存的分配是不合理的.为此,需要重新对JVM内存进行划分.为了对JVM内存进行合理分配,需要了解eclips启动过程中,GC底发生了什么事情.打开gclog方法如下:
想eclipse.inivm参数中添加
-XX:+PrintGCDetails
-Xloggc:/users/joey/Documents/gc.log
生成gc.log,启动eclipse.打开log,进行分析.
新生代的大小约为20M.堆的大小约为40M.再接下来的GC中,第一次MinorGC发现.新生代始终没有扩容.这说明,新生代的大小合适.
0.0099529secs]17024K->2324K38848K,0.720:[GC0.720:[ParNew:17024K->2112K19136K.0.0100285secs][Times:user=0.03sys=0.00,real=0.01secs]
发现老年代已经扩容到约93M,第一次发生FullGC时.而永生代扩容到约128M
0.3563491secs]62179K->57877K112260K,67.213:[FullGCSystem67.213:[CMS:57969K->57877K93124K.[CMSPerm:80490K->80392K128708K],0.3565176secs][Times:user=0.36sys=0.00,real=0.36secs]
老年代占用也没超过125M,而直到最后一次GC.永生带占用也没有超过125M.但他占用空间均超过了100M.由此,有理由规定一个初始堆大小.最终,通过分析,给eclipse.ini添加了如下几个参数:
-server
-Xverify:none
-XX:PermSize=128m
-XX:MaxPermSize=256m
-Xms256m
-Xmx512m
-Xmn40m
-Xss2m
加重JIT优化作用,-server让JVM以server模式运行.由于eclips经常开着不关,server模式下,JIT会随着运行的时间,把字节码更深刻的变成成机器代码.加快运行速度.跳过对字节码的验证-Xverify:none，堆的初始大小设置为256M,PermSiz永生带设置为128M.新生代站了40M.每个线程栈大小设为2M.FullGC已经完全消失,这种设置下.但还是剩下了20次左右的MinorGC,大约花掉0.3秒,这是可以接受的.如果为了完全消除GC而把新生代的空间设大,那也是一种内存的浪费.重启eclipse,启动时间已经落在15秒之内.