JVM角度调试优化MyEclipse_java

在将工作电脑的操作系统更换为win7之后,我的MyEclipse的启动速度和运行速率一直很不理想。特别是在同时修改调试多个页面模板的时候,来回切换两个文件总是会卡个十来秒。试过关掉各种插件和验证也无济于事。于是在大致的研究完JVM后,决定从JVM的角度来试着解决这个问题。

启动优化:

首先来看下我的myeclipse.ini里面的默认启动参数:

-Xmx512m :设置堆内存最大值为512M
-XX:MaxPermSize=256m :设置持久代最大值为256m
-XX:ReservedCodeCacheSize=64m :设置代码占用的内存大小为64m

从启动参数上看不出什么,于是往里面加入打印内存变化相关参数:

-XX:+PrintGCTimeStamps : 打印每次GC的时间戳
-XX:+PrintGCDetails : 打印每次GC的详细信息
-Xloggc:myEclipseGC.log :将GC的记录输出到文件
-verbose:gc : 输出每次GC的相关情况

然后启动MyEclipse,然后查看myEclipseGC.log里面的信息:

启动耗时大概在30秒左右,选择性的截取一小部分日志,可以看到,在myeclipse启动的前10秒内,JVM总共执行了300多次的GC和9次的FULL GC。

从GC频率和信息可以看出内存的回收率很高,且大小在不断调整,这应该是由于年轻代的空间不足导致,需要设定一个不小的初始值。

然后来重点关注FULL GC:

复制代码 代码如下:

5.961: [Full GC 5.961: [Tenured: 34568K->34456K(49676K), 0.1397651 secs] 35336K->34456K(53452K), [Perm : 26623K->26458K(26624K)], 0.1398562 secs] [Times: user=0.14 sys=0.00, real=0.14 secs]
9.030: [Full GC 9.030: [Tenured: 53310K->52332K(64588K), 0.2034757 secs] 56020K->52332K(69516K), [Perm : 43007K->42996K(43008K)], 0.2036030 secs] [Times: user=0.20 sys=0.00, real=0.20 secs]

从两次日志的对比中可以看到,FULL GC主要是在回收Tenured和Perm这两个区域,并且这两个区域的大小都在不断的调整中,所以决定先把它们的大小固定下来。

于是调整后的参数如下:

-Xms512m :设定堆的最小值为512m
-Xmn192m : 设定年轻代的大小为192m
-XX:PermSize=192m : 设定持久代的初始值为192m
-XX:MaxPermSize=192m
-XX:ReservedCodeCacheSize=64m
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-Xloggc:myEclipseGC.log
-verbose:gc

重新启动一次MyEclipse,查看日志信息:

启动耗时12秒左右,从日志可以看出,在前10秒内总共只进行了5次GC,不涉及各区域大小的调整,这个结果还是可以接受的,因为工作时不怎么需要频繁重启。

工作响应速度优化:

接下来研究困扰了我很久的来回切换html文件时的经常性延时和大卡问题,为了更直观的研究JVM的内存变化,决定借助jconsole这个java自带的辅助工具。先把myeclipse.ini的参数还原,避免被第一阶段的优化干扰。

启动myeclipse,启动jconsole并接入myeclipse所在的JVM,稳定后的整个堆的内存图如下:

接下来试着打开几个模板,然后观察内存的变化。

首先是堆内存的整体使用情况:

可以看到,在打开了几个模板之后,堆内存的使用从原先的100M以下突增至300M以上。使用量增加了三倍,但是还在我设置的512M范围之内。所以可以暂时不考虑继续增加堆内存,转而考虑调整各区内存大小比例问题。

于是观察下各个区在这段时间的内存使用情况,其中,Eden区如下:

Eden区在这段时间的内存使用率大增,且发生了多次GC。通过底下的监控信息可以知道,eden区在默认情况下只分配了31M的最大内存,这显然是不够用的。稍微执行点操作都会触发eden区的GC,这应该是模板打开切换发生延时卡顿的原因之一,需要调整。

接下来是Tenured区:

JVM默认给这个区域分配的最大空间是470M。随着内存使用的变化,这个区域的实际大小一直在调整,每次区域大小的调整都会发生FULL GC,这应该是经常性大卡的原因之一。而新模板的打开是触发这种调整的主要原因。从这个区域内存的使用上来看,将这个区域的内存空间维持并固定在450M左右,保持一定的冗余还是有必要的。

从这点来看,jvm的堆内存还是有必要稍微扩充下以维持一个较大的Tenured区和Eden区。

最后来看下perm区:

作为方法区的一部分,这个区域的内存变化并不大,并且比较稳定,本来不需要留太多的冗余。但是考虑到当前打开的工程实际代码量并不大,决定暂时维持在128M左右,日后慢慢调整。

于是根据上面的分析将参数调整为:

-Xmx768m
-Xms768m
-Xmn256m
-XX:PermSize=192m
-XX:MaxPermSize=192m
-XX:ReservedCodeCacheSize=64m

重启myeclipse,接入Jconsole,同时打开三十来个模板做了下测试。在观查各个区的内存使用率时发现一个问题,在将年轻代调整为256M以后,由于Eden不再频繁的发生GC,进入 Tenured区的数据量明显减少 ,Tenured区的内存使用图如下:

如上图,在特意打开很多模板的情况下,450M+的空间只使用了不到250M,空间利用率太低,需再做调整。

总结

 以上是我对自己的myeclipse进行调优的一些思路和实际调优的过程,在实际使用中又根据自己的喜好进行了一些调整定制,最终形成的myeclipse.ini的参数如下:

-vmargs
-Xmx512m
-Xms512m
-Xmn192m
-XX:PermSize=128m
-XX:MaxPermSize=128m
-XX:ReservedCodeCacheSize=64m

在这个参数设置下,myeclipse的响应速度比较有保证,各种延时卡顿的现象的出现频率大大降低。缺点是常驻的占用的系统内存偏高,喜欢同时打开多个myeclipse的同学可根据自己的需要和实际情况进行适当的调整。

以上就是本文的全部内容,希望能够对大家的学习有所帮助。

时间: 2024-09-16 21:50:00

JVM角度调试优化MyEclipse_java的相关文章

不做SEO民工 如何从SEO策略角度做优化

做SEO民工与SEO策略的区别是什么?最近顾芳接触了非常多城市SEO工作人员,他们多数都是在玩一个自己的SEO博客,而且博客的排名都在第一页,但收入非常不理想,有的朋友做得好一些收入有二三千一个月,也有连网站域名空间的钱都赚不回来,同时自己还付出了大量的时间,他们都和我说,玩SEO和工人没有什么区别,对这行业很失望,有的朋友已经放弃;同时我也认识一些SEO赚钱高手,他们多数都不会露面在SEO这个圈子内,他们默默的赚钱,他们玩排名只做2种模式,第一种方式是做排名获得定向客户卖产品或服务,这也是最常

从用户体验角度去优化网站

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 中国人最常用的搜索引擎是百度.百度以"为人们提供最便捷的信息获取方式"为宗旨,技术水平专业,在国内搜索引擎市场独占鳌头.但市场竞争还是存在的,360.谷歌.搜狗等都有自己的独特优势,能够帮助网民获取有利的信息.对于一个企业网站来说,如何提高网站的用户体验感,如何从用户体验角度去优化网站,这个问题值得网络负责人考虑.如果用户

浅析从用户的角度做优化

每个SEOer们都懂得搜索引擎排名的重要性,所以我们网站的构造.内链.内容都是为了更好的获得获得排名去做的.每天做更新网站时都是哪个方面利于排名 就怎么做,实不知我们都属于盲目优化,我们忽视了一个很重要的一点,那就是用户体验度.怎么从用户的角度做SEO呢?笔者来分享下几个注意的问题,希望对 站长们有所帮助. 一.网站内容问题 一般的我们站内的文章都是采集或者伪原创来增加网站内容量,目的是让搜索引擎蜘蛛来爬时,可以大大的增加网站收录,获得更好的排名.从用户的角度而言, 用户需要的是一篇高质量的内容

一步步优化JVM五:优化延迟或者响应时间

本节的目标是做一些优化以满足对应用对延迟的需求.这次需要几个步骤,包括完善Java堆大小的配置,评估垃圾回收占用的时间和频率,也许还要尝试切换到不同的垃圾回收器,以及由于使用了不同的垃圾回收器,需要重新优化Java堆空间大小.       这一步有如下可能的结果:       1.应用的延迟需求被满足了.如果这一步的优化操作满足了应用的延迟需求,你可以继续下一步优化(优化吞吐量).       2.应用的延迟需求未被满足.如果这一步的优化操作未能满足延迟需求,你可能需要重新看看延迟需求是否合理或

一步步优化JVM六:优化吞吐量

如果你已经进行完了前面的步骤了,那么你应该知道这是最后一步了.在这一步里面,你需要测试应用的吞吐量和为了更高的吞吐量而优化JVM.    这一步的输入就是应用的吞吐量性能要求.应用的吞吐量是在应用层面衡量而不是在JVM层面衡量,因此,应用必须要报告出一些吞吐量指标或者应用的某些操作的吞吐量性能指标.观察到的吞吐量指标然后用可以用来和应用需要的性能指标进行比较,如果达到或者超过要求,那么这一步就完成了.如果你需要更好的吞吐量的话,有一些JVM优化可以去做.      这一步的另外一个输入就是,有多

电脑显卡怎么调试优化?

  我们经常会因自己的显卡不能支持最新的游戏而烦恼,而经常对显卡的BIOS和驱动程序进行升级,就可达到显卡优化的目的. 1.显卡BIOS的更新 显卡的BIOS升级有两个方面的内容.一是升级显卡本来品牌的BIOS,其作用如同升级主板的BIOS一样,是为了使显卡提供更多的功能,消除原BIOS中的Bug;二是将原有小厂的显卡BIOS换为知名品牌显卡的BIOS(但显卡的芯片必须一致).当然,显卡BIOS更新的危险性很大,你最好在升级显卡BIOS时,请一位高手帮助. 2.及时升级显卡的驱动程序 据有关资料

JVM中锁优化,偏向锁、自旋锁、锁消除、锁膨胀

本文将简单介绍HotSpot虚拟机中用到的锁优化技术. 自旋锁 互斥同步对性能最大的影响是阻塞的实现,挂起线程和恢复线程的操作都需要转入内核态中完成,这些操作给系统的并发性能带来了很大的压力.而在很多应用上,共享数据的锁定状态只会持续很短的一段时间.若实体机上有多个处理器,能让两个以上的线程同时并行执行,我们就可以让后面请求锁的那个线程原地自旋(不放弃CPU时间),看看持有锁的线程是否很快就会释放锁.为了让线程等待,我们只须让线程执行一个忙循环(自旋),这项技术就是自旋锁. 如果锁长时间被占用,

Android] Android开发优化之——从代码角度进行优化

通常我们写程序,都是在项目计划的压力下完成的,此时完成的代码可以完成具体业务逻辑,但是性能不一定是最优化的.一般来说,优秀的程序员在写完代码之后都会不断的对代码进行重构.重构的好处有很多,其中一点,就是对代码进行优化,提高软件的性能.下面我们就从几个方面来了解Android开发过程中的代码优化.   1)静态变量引起内存泄露 在代码优化的过程中,我们需要对代码中的静态变量特别留意.静态变量是类相关的变量,它的生命周期是从这个类被声明,到这个类彻底被垃圾回收器回收才会被销毁.所以,一般情况下,静态

解析Android开发优化之:从代码角度进行优化的技巧_Android

通常我们写程序,都是在项目计划的压力下完成的,此时完成的代码可以完成具体业务逻辑,但是性能不一定是最优化的.一般来说,优秀的程序员在写完代码之后都会不断的对代码进行重构.重构的好处有很多,其中一点,就是对代码进行优化,提高软件的性能.下面我们就从几个方面来了解Android开发过程中的代码优化. 1)静态变量引起内存泄露 在代码优化的过程中,我们需要对代码中的静态变量特别留意.静态变量是类相关的变量,它的生命周期是从这个类被声明,到这个类彻底被垃圾回收器回收才会被销毁.所以,一般情况下,静态变量