|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-06-19
作者：江南白衣，最新版链接：http://blog.csdn.net/calvinxiu/archive/2007/05/18/1614473.aspx，版权所有，转载请保留原文链接。 原本想把题目更简单的定为--《不要停》的，但还是自己YY一下就算了。 一、参考资料：
二、基本概念 1、堆(Heap) JVM管理的内存叫堆。在32Bit操作系统上有1.5G-2G的限制，而64Bit的就没有。 JVM初始分配的内存由-Xms指定，默认是物理内存的1/64但小于1G。 JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4但小于1G。 默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制，可以由-XX:MinHeapFreeRatio=指定。 服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小，所以上面的两个参数没啥用。
2.基本收集算法
可见，没有免费的午餐，无论采用复制还是标记清除算法，自动的东西都要付出很大的性能代价。 3.分代 分代是Java垃圾收集的一大亮点，根据对象的生命周期长短，把堆分为3个代：Young，Old和Permanent，根据不同代的特点采用不同的收集算法，扬长避短也。 Young(Nursery)，年轻代。研究表明大部分对象都是朝生暮死，随生随灭的。因此所有收集器都为年轻代选择了复制算法。 Young的默认值为4M，随堆内存增大，约为1/15，JVM会根据情况动态管理其大小变化。 Young的大小非常非常重要，见“后面暂停时间优先收集器”的论述。 Young里面又分为3个区域，一个Eden，所有新建对象都会存在于该区，两个Survivor区，用来实施复制算法。每次复制就是将Eden和第一块Survior的活对象复制到第2块，然后清空Eden与第一块Survior。Eden与Survivor的比例由-XX:SurvivorRatio=设置，默认为32。Survivio大了会浪费，小了的话，会使一些年轻对象潜逃到老人区，引起老人区的不安，但这个参数对性能并不重要。 Old(Tenured)，年老代。年轻代的对象如果能够挺过数次收集，就会进入老人区。老人区使用标记整理算法。因为老人区的对象都没那么容易死的，采用复制算法就要反复的复制对象，很不合算，只好采用标记清理算法，但标记清理算法其实也不轻松，每次都要遍历区域内所有对象，所以还是没有免费的午餐啊。 -XX:MaxTenuringThreshold=设置熬过年轻代多少次收集后移入老人区，CMS中默认为0，熬过第一次GC就转入，可以用-XX:+PrintTenuringDistribution查看。 Permanent，持久代。装载Class信息等基础数据，默认64M，如果是类很多很多的服务程序，需要加大其设置-XX:MaxPermSize=，否则它满了之后会引起fullgc()或Out of Memory。 注意Spring，Hibernate这类喜欢AOP动态生成类的框架需要更多的持久代内存。 4.minor/major collection 每个代满了之后都会促发collection，（另外Concurrent Low Pause Collector默认在老人区68%的时候促发)。GC用较高的频率对young进行扫描和回收，这种叫做minor collection。 5.小结 Young -- minor collection -- 复制算法 Old(Tenured) -- major colletion -- 标记清除/标记整理算法
三、收集器 1.古老的串行收集器(Serial Collector) 使用 -XX:+UseSerialGC，策略为年轻代串行复制，年老代串行标记整理。 2.吞吐量优先的并行收集器(Throughput Collector) 使用 -XX:+UseParallelGC ，也是JDK5 -server的默认值。策略为： 所以需要2+的CPU时才会优于串行收集器，适用于后台处理，科学计算。 可以使用-XX:MaxGCPauseMillis= 和 -XX:GCTimeRatio 来调整GC的时间。 3.暂停时间优先的并发收集器(Concurrent Low Pause Collector-CMS) 前面说了这么多，都是为了这节做铺垫...... 使用-XX:+UseConcMarkSweepGC，策略为： 3.1 年老代详述 并行(Parallel)与并发(Concurrent)仅一字之差，并行指多条垃圾收集线程并行，并发指用户线程与垃圾收集线程并发，程序在继续运行，而垃圾收集程序运行于另一个个CPU上。 并发收集一开始会很短暂的停止一次所有线程来开始初始标记根对象，然后标记线程与应用线程一起并发运行，最后又很短的暂停一次，多线程并行的重新标记之前可能因为并发而漏掉的对象，然后就开始与应用程序并发的清除过程。可见，最长的两个遍历过程都是与应用程序并发执行的，比以前的串行算法改进太多太多了！！！ 串行标记清除是等年老代满了再开始收集的，而并发收集因为要与应用程序一起运行，如果满了才收集，应用程序就无内存可用，所以系统默认68%满的时候就开始收集。内存已设得较大，吃内存又没有这么快的时候，可以用-XX:CMSInitiatingOccupancyFraction=恰当增大该比率。 3.2 年轻代详述 可惜对年轻代的复制收集，依然必须停止所有应用程序线程，原理如此，只能靠多CPU，多收集线程并发来提高收集速度，但除非你的Server独占整台服务器，否则如果服务器上本身还有很多其他线程时，切换起来速度就..... 所以，搞到最后，暂停时间的瓶颈就落在了年轻代的复制算法上。 因此Young的大小设置挺重要的，大点就不用频繁GC，而且增大GC的间隔后，可以让多点对象自己死掉而不用复制了。但Young增大时，GC造成的停顿时间攀升得非常恐怖，比如在我的机器上，默认8M的Young，只需要几毫秒的时间，64M就升到90毫秒，而升到256M时，就要到300毫秒了，峰值还会攀到恐怖的800ms。谁叫复制算法，要等Young满了才开始收集，开始收集就要停止所有线程呢。 3.3 持久代 可设置-XX:+CMSClassUnloadingEnabled 4.增量(train算法)收集器(Incremental Collector) 已停止维护，–Xincgc选项默认转为并发收集器。 四、暂停时间显示 加入下列参数 (请将PrintGC和Details中间的空格去掉，CSDN很怪的认为是禁止字句）
会程序运行过程中将显示如下输出 9.211: [GC 9.211: [ParNew: 7994K->0K(8128K), 0.0123935 secs] 427172K->419977K(524224K), 0.0125728 secs] 显示在程序运行的9.211秒发生了Minor的垃圾收集，前一段数据针对新生区，从7994k整理为0k，新生区总大小为8128k，程序暂停了12ms，而后一段数据针对整个堆。 对于年老代的收集，暂停发生在下面两个阶段，CMS-remark的中断是17毫秒： [GC [1 CMS-initial-mark: 80168K(196608K)] 81144K(261184K), 0.0059036 secs] [1 CMS-remark: 80168K(196608K)] 82493K(261184K),0.0168943 secs] 再加两个参数 -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime对暂停时间看得更清晰。 五、真正不停的BEA JRockit 与Sun RTS2.0 Bea的JRockit 5.0 R27 的特色之一是动态决定的垃圾收集策略，用户可以决定自己关心的是吞吐量，暂停时间还是确定的暂停时间，再由JVM在运行时动态决定、改变改变垃圾收集策略。 最可惜JRockt的license很奇怪，虽然平时使用免费，但这个30ms的选项就需要购买整个Weblogic Real Time Server的license。 其他免费选项，有：
JavaOne2007上有Sun的 Java Real-Time System 2.0 的介绍，RTS2.0基于JDK1.5，在Real-Time Garbage Collctor上又有改进，但还在beta版状态，只供给OEM，更怪。 六、JDK 6.0的改进 因为JDK5.0在Young较大时的表现还是不够让人满意，又继续看JDK6.0的改进，结果稍稍失望，不涉及我最头痛的年轻代复制收集改良。 1.年老代的标识-清除收集，并行执行标识 2.加大了Young区的默认大小 3.System.gc()可以与应用程序并发执行 七、小结 1. JDK5.0/6.0 对于服务器应用，我们使用Concurrent Low Pause Collector，对年轻代，暂停时多线程并行复制收集；对年老代，收集器与应用程序并行标记--整理收集，以达到尽量短的垃圾收集时间。 本着没有深刻测试前不要胡乱优化的宗旨，命令行属性只需简单写为：  -server -Xms<heapsize></heapsize>M -Xmx<heapsize></heapsize>M -XX:+UseConcMarkSweepGC -XX:+PrintGC Details -XX:+PrintGCTimeStamps 然后要根据应用的情况，在测试软件辅助可以下看看有没有JVM的默认值和自动管理做的不够的地方可以调整，如-xmn 设Young的大小，-XX:MaxPermSize设持久代大小等。 2. JRockit 6.0 R27.2 但因为JDK5的测试结果实在不能满意，后来又尝试了JRockit，总体效果要好些。 -Xms<heapsize></heapsize>M -Xmx<heapsize></heapsize>M -Xgcprio:pausetime -Xpausetarget=200ms -XgcReport -XgcPause -Xverbose:memory
声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
浏览 8250 次
