最近刚好看完《深入理解java虚拟机》,而Eclispe的启动速度实在是慢到了顶点,正好借此机会对Eclipse进行调优.首先使用Visual VM+Visual GC 对Eclipse进行数据采集

1.先介绍一下界面(Java Heap 分代)：

1.1元空间(MetaSpace)

jdk1.8之后永久带(Perm)已经被移除,替换为了元空间(MetaSpace),元空间直接使用物理内存分配,而不依赖于java虚拟机.jdk1.7之前永久代是用来描述描述办法区的,类变量,常量,class对象,以及各种字面量和符号引用都是存放在永久带中的.但是从1.7之后永久代开始做永久代的转移,因为永久代很容易导致内存溢出,并且很难做调优.

了解更多的关于永久代和元空间的问题可以看以下的博客,这里不做过多的论述.

http://www.cnblogs.com/paddix/p/5309550.html

-XX:MetaspaceSize,初始空间大小,达到该值就会触发垃圾收集进行类型卸载,同时GC会对该值进行调整：如果释放了大量的空间,就适当降低该值；如果释放了很少的空间,那么在不跨越MaxMetaspaceSize时,适当提高该值.

-XX:MaxMetaspaceSize,最年夜空间,默认是没有限制的.

1.2年轻代(Yong)

年轻代重要有伊甸园区 (Eden)和两个存活区(Survivor)组成,默认的比例是8：1：1,新生的对象大部门都是在年轻代分配的,也是Minor GC 的区域,至于对象是如何分配的大家仔细阅读《深入理解java虚拟机》,这里不做过多的阐述.

1.3老年代(Tenured)

大对象直接在老年代分配以及达到必定年龄的对象会从年轻代晋升到老年代,Full GC的主要区域,一般Full GC的时间会是Minor GC的10倍之多.

2.Graphs区域

2.1)Compile Time(JIT编译时间):11418 compiles 表现编译总数 ,16.878s表现编译时间.

2.2) Class Loader(类加载时间): 18530loaded表现加载类数量, 0 unloaded表现卸载的类数量,28.237s表现类加载花费的时间 .

2.3)GC Time(GC Time)：9 collections表现垃圾收集的总次数,648.756ms表现垃圾收集花费的时间,last cause表现最近垃圾收集的原因 .

2.4)Eden Space(Eden 区)：括号内的204.875M表现最大容量,204.875M表现当前容量,后面的71.497M表现当前使用情况,5 collections表现垃圾收集次数,531.593表现垃圾收集花费时间.

2.5)Survivor 0/Survivor 1(S0和S1区)：括号内的253562M表现最大容量,25.562M表现当前容量,之后的值是当前使用情况

2.6)Old Gen(老年代)：括号内的1.75G表现最大容量,1.75表现当前容量,之后的93.877M表现当前使用情况,4collections表现垃圾收集次数 ,117.163s表现垃圾收集花费时间

2.7)MetaSpace(元空间)：括号内的1.02表现最大容量,115.941M表现当前容量,之后的105.090M表现当前使用情况 .

3.Histogram区域：survivor区域参数跟年龄柱状图

3.1)Tenuring Threshold：表现新生代对象年龄大于当前值则进入老年代

3.2)Max Tenuring Threshold：表现新生代对像最大年龄值.

3.3)Tenuring Threshold与Max Tenuring Threshold区别：

虚拟机给每个对象都定义了一个对象年龄的(Age)的计数器,保留在对象头里,如果Eden中的对象经过一次Minor GC之后任然存活并且能被Survivor容纳的话,将被移动到Survivor中,并且对象年龄设置为1,对象在Survivor中没“熬过”一次Minor GC,年龄增加1岁,当增加到一定程度(默认是15岁)的时候就会被晋升到老年代中.晋升到老年代的阈值可以通过参数-XX:MaxTenuringThresold设置.但是虚拟机并并不永远要求对象的年龄必须达到MaxTenuringThresold的值才晋升到老年代,如果Survivor中相同年龄对象大小的总和大于Survivor空间的一半,年龄大于或者等于该年龄的对象就可以直接进如老年代.

3.4)Desired Survivor Size：Survivor空间年夜小验证阙值(默认是survivor空间的一半),用于Tenuring Threshold判断对象是否提前进入老年代.

3.5)Current Survivor Size：当前survivor空间年夜小

3.6)histogram柱状图：表现年龄段对象的存储柱状图

此时我的eclipse启动时间为25秒.

察看堆内存的使用情况,本人win8系统,8G运行内存,所以我直接在这里指定了堆内存的初始值和最大值相等,不支持它动态的伸缩,提升性能.

-Xms 1024M(默认物理内存1/64)

-Xmx 1024M(默认物理内存1/4)

-Xmn 256M 新生代内存年夜小

并且可以看出老年代大小为新生代的3倍

可以看出java Heap 运行完全正常.

-XX:MetaspaceSize=256m

-XX:MaxMetaspaceSize=256m

将元空间设置一下(很遗憾的是元空间还是存在动态伸缩的问题,不知道为什么)

编译时间和类加载优化

在进行类加载的时候,字节码验证耗时尤为严重,而验证的过程又不是必需的,而且Eclipse已经是非常成熟的软件,所以它的编译代码认为是可靠的,不需要再类加载的时候进行字节码验证,所以我们关闭字节码验证的过程.

-Xverify:none

JIT编译是指虚拟机的JIT编译器,编译热点代码的耗时,随着代码使用次数的增加,可以让我们的代码被编译的越来越彻底,运行速度变得更快.虚拟机提供了一个参数-Xint禁止编译器工作,然则我们不要去关闭这个参数.

当虚拟在-client时使用的是C1轻量级编译器 ,-server模式下使用的是C2重量级编译器,提供更加强有力的优化步伐.这里我们使用C2,因为我已经习惯了长时间不关闭Eclipse.

-server

观察cpu发现我的CPU占用率还是蛮高的,这是为什么?因为在新版本的Eclipse中默认的垃圾收集器便是并行的组合.

-XX:+UseConcMarkSweepGC

开启CMS收集器后,新生代默认收集器是ParNew

最终的配置是：

-XX:+UseConcMarkSweepGC

-XX:CMSInitiatingOccupancyFraction=85

-XX:CMSFullGCsBeforeCompaction=8

-XX:+UseStringDeduplication

-server

-Xverify:none

-Xms1024m

-Xmx1024m

-Xmn256m

-XX:MetaspaceSize=256m

-XX:MaxMetaspaceSize=256m

-XX:PretenureSizeThreshold=1048576

-XX:CMSInitiatingOccupancyFraction=85 -XX:CMSFullGCsBeforeCompaction=5

第一个参数是因为CMS收集器的并发清除,会产生浮动垃圾,CMS无法在当此垃圾收集的时候处理他们,但是又不克不及因为浮动垃圾填满整个老年代才去收集垃圾,因为要留一部分空间给用户线程使用,-XX:CMSInitiatingOccupancyFraction=85,通过配置当老年代超过85%空间被使用就会触发CMS收集器.

第二个参数是因为CMS收集器采用的是标志-清除算法,老年代会产生空间碎片,导致在分配大对象的时候找不到连续的内存空间而不得不触发FullGC,为此CMS提供了一个参数+UseCMSCompactAtFullCollection用于在CMS顶不住要进行Full GC的时候开启内存的合并整理过程,但是合并整理的过程并不是并发的,而是stop the world ,停顿时间就变长了,-XX:CMSFullGCsBeforeCompaction=8 而这个参数是指在8次不合并整理的Full GC 后带来一次压缩整理的过程.

-XX:PretenureSizeThreshold=1048576

考虑到实际情况,将年夜于1M的对象直接分配到老年代,减少minor GC的次数

-XX:+UseStringDeduplication

这参数是字符串去重,必需和G1收集器合并使用,我尝试使用了一下G1收集器发现效果并不是特别明显.

-XX:+UseStringDeduplication

FullGC 触发0次,类加载缩短10秒左右.启动时间根本稳定在16s左右