主题:优化JVM参数提高eclipse运行速度

受此文启发: 随想配置:更快的启动eclipse

性能优化从身边做起。

首先建立评估体系,将workspace里所有的项目close掉,关闭eclipse。优化的用例就是启动eclipse,open一个项目,eclipse会自动build这个项目,保证没有感觉到明显的卡,也就是没有full GC。

开始:

eclipse.ini里加入打印gc情况的参数:

-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-verbose:gc
-Xloggc:gc.log



这样eclipse在运行过程中会记录gc日志,显示详细的gc情况,并打印在gc.log中,通过分析这个日志寻找eclipse的性能瓶颈和优化方式。
我最初的参数只是在原版基础上调了堆大小

-Xms512m
-Xmx512m



将堆初始化和最大值设为一样,消除堆大小根据当前堆使用情况而变化带来的影响。
启动eclipse,发现gc.log里打出了很多full gc的日志

引用
4.226: [Full GC 4.226: [Tenured: 18470K->19304K(30544K), 0.1159544 secs] 25154K->19304K(44368K), [Perm : 24574K->24554K(24576K)], 0.1160431 secs] [Times: user=0.13 sys=0.00, real=0.13 secs]


在启动的6秒多时间里共出现了8次full gc,所以启动慢,觉得启动时候挺卡的。从日志里可以看出来 FullGC主要是在回收tenured区和Perm区,其中Perm一直都是快满的状态,Perm : 24574K->24554K(24576K),Perm大小在不断调整,所以需要固定Perm区的大小,保证够用,eclipse.ini里加入

-XX:PermSize=64m
-XX:MaxPermSize=64m



再启动:发现没有full gc了只有数量比较多的minor gc,挑启动开始到启动完成的第一条和最后一条日志

引用
0.209: [GC 0.209: [DefNew: 4416K->511K(4928K), 0.0034707 secs] 4416K->614K(15872K), 0.0035239 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
….
6.383: [GC 6.383: [DefNew: 18880K->1985K(21184K), 0.0055311 secs] 46992K->30098K(68040K), 0.0055694 secs]


这6秒中GC日志打了69次, 而内存回收率还是蛮高的 young区18880-1985=16895 jvm 46992-30098=16894 都快接近100%了,可以看出young区是由小到大在不断调整大小,所以不断GC,因此设一个初始值吧,据说设置heap的1/4比较好,那就是128M,所以eclipse.ini加入

-Xmn128m



再重启,发现GC日志就四条了,eclipse启动自然快了

引用
1.292: [GC 1.292: [DefNew: 104960K->10984K(118016K), 0.0334165 secs] 104960K->10984K(511232K), 0.0334603 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
2.182: [GC 2.182: [DefNew: 115944K->1852K(118016K), 0.0221714 secs] 115944K->11466K(511232K), 0.0222142 secs] [Times: user=0.00 sys=0.02, real=0.02 secs]
3.987: [GC 3.987: [DefNew: 106779K->12531K(118016K), 0.0378228 secs] 116393K->22145K(511232K), 0.0378692 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
5.377: [GC 5.377: [DefNew: 117491K->9403K(118016K), 0.0513728 secs] 127105K->31364K(511232K), 0.0514133 secs]



但是,启动后open我的多个项目,这些项目互相依赖,eclipse自动build,感觉有点小卡,发现日志里多了4次full GC,所以就卡了…

引用
67.320: [Full GC (System) 67.320: [Tenured: 88847K->68809K(393216K), 0.2121213 secs] 117385K->68809K(511232K), [Perm : 41915K->41915K(65536K)], 0.2121747 secs] [Times: user=0.20 sys=0.00, real=0.20 secs]
103.759: [Full GC (System) 103.759: [Tenured: 81882K->66784K(393216K), 0.3287387 secs] 185350K->66784K(511232K), [Perm : 53464K->53414K(65536K)], 0.3287897 secs] [Times: user=0.33 sys=0.00, real=0.33 secs]



这个时候Tenured区和Perm都还没到很接近最大值,但是为什么还有full GC呢,开始以为是JVM悲观认为Tenured区剩余空间不足以应对下一次minor GC 所以进行了full GC调整Tenured空间,索性直接增加了堆最大值到-Xmx728m(工作电脑的内存是3.5G),但重启后full gc还是有4次,而且有几次minor GC用的时间超过了0.1秒,这是因为增加了堆大小,导致GC用时也增加了,不能接受。所以还是改回-Xmx512m。
再仔细观察日志,发现Full GC (System) 字样,这个意思是eclipse里调用了System.gc()手动触发了系统GC,好吧,哥已经给你分配足够空间了,你就省省吧,在eclipse.ini里加入:

-XX:+DisableExplicitGC



这样就差不多了,整个过程没有出现full gc,再编码2个小时,中间只出现了一次full gc,在open build某50W行+的代码的时候,eclipse还是卡了…
最后又稍微调了一下各代的大小,得到目前的参数:

-Xms512m
-Xmx512m
-XX:PermSize=96m
-XX:MaxPermSize=96m
-Xmn168m
-XX:+DisableExplicitGC


另外没有去调GC策略,主要是觉得eclipse是客户端程序,默认的client单线程的GC策略应该是比较适合的,以后有时间再试试看吧。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
提高 JAVA IDE 的性能的JVM开关 Submitted by 小天蝎 on 2005, August 18, 2:45 PM. integration 我的本本是p4 1.8G的dell c640 内存1G,eclipse 3.1 + myeclipse 4.0m2 速度还不错。 运行参数如下:eclipse.exe -vmargs -Xverify:none -XX:+UseParallelGC -XX:PermSize=20M -------------- JVM 提供了各种用于调整内存分配和垃圾回收行为的标准开关和非标准开关。其中一些设置可以提高 JAVA IDE 的性能。 注意,由于 -X (尤其是 -XX JVM)开关通常是 JVMJVM 供应商特定的,本部分介绍的开关可用于 Sun Microsystems J2SE 1.4.2。 以下设置在大多数系统上将产生比工厂更好的设置性能。 -vmargs - 表示将后面的所有参数直接传递到所指示的 Java VM。 -Xverify:none - 此开关关闭Java字节码验证,从而加快了类装入的速度,并使得在仅为验证目的而启动的过程中无需装入类。此开关缩短了启动时间,因此没有理由不使用它。 -Xms24m - 此设置指示 Java 虚拟机将其初始堆大小设置为 24 MB。通过指示 JVM 最初应分配给堆的内存数量,可以使 JVM 不必在 IDE 占用较多内存时增加堆大小。 -Xmx96m - 此设置指定 Java 虚拟机应对堆使用的最大内存数量。为此数量设置上限表示 Java 进程消耗的内存数量不得超过可用的物理内存数量。对于具有更多内存的系统可以增加此限制,96 MB 设置有助于确保 IDE 在内存量为 128MB 到 256MB 的系统上能够可靠地执行操作。注意:不要将该值设置为接近或大于系统的物理内存量,否则将在主要回收过程中导致频繁的交换操作。 -XX:PermSize=20m - 此 JVM 开关不仅功能更为强大,而且能够缩短启动时间。该设置用于调整内存"永久区域"(类保存在该区域中)的大小。因此我们向 JVM 提示它将需要的内存量。该设置消除了许多系统启动过程中的主要垃圾收集事件。SunONE Studio 或其它包含更多模块的 IDE 的用户可能希望将该数值设置得更高。 下面列出了其它一些可能对 ECLIPSE 在某些系统(不是所有系统)上的性能产生轻微或明显影响的 JVM 开关。尽管使用它们会产生一定的影响,但仍值得一试。 -XX:CompileThreshold=100 - 此开关将降低启动速度,原因是与不使用此开关相比,HotSpot 能够更快地将更多的方法编译为本地代码。其结果是提高了 IDE 运行时的性能,这是因为更多的 UI 代码将被编译而不是被解释。该值表示方法在被编译前必须被调用的次数。 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC - 如果垃圾回收频繁中断,则请尝试使用这些开关。此开关导致 JVM 对主要垃圾回收事件(如果在多处理器工作站上运行,则也适用于次要回收事件)使用不同的算法,这些算法不会影响整个垃圾回收进程。注意:目前尚不确定此收集器是提高还是降低单处理器计算机的性能。 -XX:+UseParallelGC - 某些测试表明,至少在内存配置相当良好的单处理器系统中,使用此回收算法可以将次要垃圾回收的持续时间减半。注意,这是一个矛盾的问题,事实上此回收器主要适用于具有千兆字节堆的多处理器。尚无可用数据表明它对主要垃圾回收的影响。注意:此回收器与 -XX:+UseConcMarkSweepGC 是互斥的。=====================================================================================================================建议启动参数:c:\eclipse\eclipse.exe -vmargs -Xverify:none -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值