关于垃圾回收的倡议书

亲爱的同学们：

河流，是鱼儿的归宿；天空，是鸟儿的归宿；那垃圾的归宿在哪儿呢？其实环保离我们并不遥远，只要我们每个人多向环保走一步；一个动作，一声宣传……我们的校园生活就会变得更美！来吧！加入我们环保卫队的行列！现在，环保卫队将在各班级展开废品回收活动。为此，团委向全校师生发出倡议：

1、做到无碳循环。自觉并积极做好废品回收，以供再利用；减少会产生校园垃圾的因素，减少不可回收、不可循环物品的使用。特别是塑料袋，因为降解一个塑料袋至少得需要300年，试想，你的子孙将在一个由塑料袋组成的世界里生活！那样的世界好吗？

2、做好垃圾分类处理，把不可回收的垃圾和可回收的垃圾（如矿泉水瓶、废纸等）分类投放在班级指定的垃圾袋内，由生活委员统一保管好，等待环保卫队前来回收。

3、一个人的道德素养不仅表现在言谈上，更表现在行为举止上，请不要随意乱扔垃圾，自觉美化环境，请随手捡起你身边的垃圾，为美化我们的校园而努力。

4、收集后环保卫队将统一卖，在分等为班级购置日用品。

5、请大家积极宣传和响应环保。积极参加、配合环保卫队。相信有了你们的加入，我们的明天会更美好！

保护环境，人人有责。从小事做起，做好废品回收，做好环保，相信只要我们共同努力，鱼儿的归宿会更美，鸟儿的归宿会更美，我们的校园生活也一定会更美。

此倡议

共青团东明中学委员会 20xx年8月30日

第二篇：垃圾回收

JVM的垃圾回收机制详解和调优

1.JVM的gc概述

gc即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言并不要求jvm有gc，也没有规定gc如何工作。不过常用的jvm都有gc，而且大多数gc都使用类似的算法管理内存和执行收集操作。

在充分理解了垃圾收集算法和执行过程后，才能有效的优化它的性能。有些垃圾收集专用于特殊的应用程序。比如，实时应用程序主要是为了避免垃圾收集中断，而大多数OLTP应用程序则注重整体效率。理解了应用程序的工作负荷和jvm支持的垃圾收集算法，便可以进行优化配置垃圾收集器。

垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。gc首先要判断该对象是否是时候可以收集。两种常用的方法是引用计数和对象引用遍历。

1.1.引用计数

引用计数存储对特定对象的所有引用数，也就是说，当应用程序创建引用以及引用超出范围时，jvm必须适当增减引用数。当某对象的引用数为0时，便可以进行垃圾收集。

1.2.对象引用遍历

早期的jvm使用引用计数，现在大多数jvm采用对象引用遍历。对象引用遍历从一组对象开始，沿着整个对象图上的每条链接，递归确定可到达（reachable）的对象。如果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集。在对象遍历阶段，gc必须记住哪些对象可以到达，以便删除不可到达的对象，这称为标记（marking）对象。 下一步，gc要删除不可到达的对象。删除时，有些gc只是简单的扫描堆栈，删除未标记的未标记的对象，并释放它们的内存以生成新的对象，这叫做清除（sweeping）。这种方法的问题在于内存会分成好多小段，而它们不足以用于新的对象，但是组合起来却很大。因此，许多gc可以重新组织内存中的对象，并进行压缩（compact），形成可利用的空间。 为此，gc需要停止其他的活动活动。这种方法意味着所有与应用程序相关的工作停止，只有gc运行。结果，在响应期间增减了许多混杂请求。另外，更复杂的gc不断增加或同时运行以减少或者清除应用程序的中断。有的gc使用单线程完成这项工作，有的则采用多线程以增加效率。

2.几种垃圾回收机制

2.1.标记－清除收集器

这种收集器首先遍历对象图并标记可到达的对象，然后扫描堆栈以寻找未标记对象并释放它们的内存。这种收集器一般使用单线程工作并停止其他操作。

2.2.标记－压缩收集器

有时也叫标记－清除－压缩收集器，与标记－清除收集器有相同的标记阶段。在第二阶段，则把标记对象复制到堆栈的新域中以便压缩堆栈。这种收集器也停止其他操作。

2.3.复制收集器

这种收集器将堆栈分为两个域，常称为半空间。每次仅使用一半的空间，jvm生成的新对象则放在另一半空间中。gc运行时，它把可到达对象复制到另一半空间，从而压缩了堆栈。这种方法适用于短生存期的对象，持续复制长生存期的对象则导致效率降低。

2.4.增量收集器

增量收集器把堆栈分为多个域，每次仅从一个域收集垃圾。这会造成较小的应用程序中断。

2.5.分代收集器

这种收集器把堆栈分为两个或多个域，用以存放不同寿命的对象。jvm生成的新对象一般放在其中的某个域中。过一段时间，继续存在的对象将获得使用期并转入更长寿命的域中。分代收集器对不同的域使用不同的算法以优化性能。

2.6.并发收集器

并发收集器与应用程序同时运行。这些收集器在某点上（比如压缩时）一般都不得不停止其他操作以完成特定的任务，但是因为其他应用程序可进行其他的后台操作，所以中断其他处理的实际时间大大降低。

2.7.并行收集器

并行收集器使用某种传统的算法并使用多线程并行的执行它们的工作。在多cpu机器上使用多线程技术可以显著的提高java应用程序的可扩展性。

3.Sun HotSpot 1.4.1 JVM堆大小的调整

Sun HotSpot 1.4.1使用分代收集器，它把堆分为三个主要的域：新域、旧域以及永久域。Jvm生成的所有新对象放在新域中。一旦对象经历了一定数量的垃圾收集循环后，便获得使用期并进入旧域。在永久域中jvm则存储class和method对象。就配置而言，永久域是一个独立域并且不认为是堆的一部分。

下面介绍如何控制这些域的大小。可使用-Xms和-Xmx 控制整个堆的原始大小或最大值。

下面的命令是把初始大小设置为128M：

java –Xms128m

–Xmx256m为控制新域的大小，可使用-XX：NewRatio设置新域在堆中所占的比例。 下面的命令把整个堆设置成128m，新域比率设置成3，即新域与旧域比例为1：3，新域为堆的1/4或32M：

java –Xms128m –Xmx128m–XX：NewRatio =3可使用-XX：NewSize和-XX：MaxNewsize设置新域的初始值和最大值。

下面的命令把新域的初始值和最大值设置成64m：

java –Xms256m –Xmx256m –Xmn64m

永久域默认大小为4m.运行程序时，jvm会调整永久域的大小以满足需要。每次调整时，jvm会对堆进行一次完全的垃圾收集。

使用-XX：MaxPerSize标志来增加永久域搭大小。在WebLogic Server应用程序加载较多类时，经常需要增加永久域的最大值。当jvm加载类时，永久域中的对象急剧增加，从而使jvm不断调整永久域大小。为了避免调整，可使用-XX：PerSize标志设置初始值。 下面把永久域初始值设置成32m，最大值设置成64m.

java -Xms512m -Xmx512m -Xmn128m -XX：PermSize=32m -XX：MaxPermSize=64m

默认状态下，HotSpot在新域中使用复制收集器。该域一般分为三个部分。第一部分为Eden，用于生成新的对象。另两部分称为救助空间，当Eden充满时，收集器停止应用程序，把所有可到达对象复制到当前的from救助空间，一旦当前的from救助空间充满，收集器则把可到达对象复制到当前的to救助空间。From和to救助空间互换角色。维持活动的对象将在救助空间不断复制，直到它们获得使用期并转入旧域。使用-XX：SurvivorRatio可控制新域子空间的大小。

同NewRation一样，SurvivorRation规定某救助域与Eden空间的比值。比如，以下命令把新域设置成64m，Eden占32m，每个救助域各占16m：

java -Xms256m -Xmx256m -Xmn64m -XX：SurvivorRation =2

如前所述，默认状态下HotSpot对新域使用复制收集器，对旧域使用标记－清除－压缩收集器。在新域中使用复制收集器有很多意义，因为应用程序生成的大部分对象是短寿命的。理想状态下，所有过渡对象在移出Eden空间时将被收集。如果能够这样的话，并且移出Eden空间的对象是长寿命的，那么理论上可以立即把它们移进旧域，避免在救助空间反复复制。

但是，应用程序不能适合这种理想状态，因为它们有一小部分中长寿命的对象。最好是保持这些中长寿命的对象并放在新域中，因为复制小部分的对象总比压缩旧域廉价。为控制新域中对象的复制，可用-XX：TargetSurvivorRatio控制救助空间的比例（该值是设置救助空间的使用比例。如救助空间位1M，该值50表示可用500K）。该值是一个百分比，默认值是

50.当较大的堆栈使用较低的sruvivorratio时，应增加该值到80至90，以更好利用救助空间。用-XX：maxtenuring threshold可控制上限。

为放置所有的复制全部发生以及希望对象从eden扩展到旧域，可以把MaxTenuring

Threshold设置成0.设置完成后，实际上就不再使用救助空间了，因此应把SurvivorRatio设成最大值以最大化Eden空间，设置如下：

java ? -XX：MaxTenuringThreshold=0 –XX：SurvivorRatio＝50000 ?

4.BEA JRockit JVM的使用

Bea WebLogic 8.1使用的新的JVM用于Intel平台。在Bea安装完毕的目录下可以看到有一个类似于jrockit81sp1_141_03的文件夹。这就是Bea新JVM所在目录。不同于HotSpot把Java字节码编译成本地码，它预先编译成类。JRockit还提供了更细致的功能用以观察JVM的运行状态，主要是独立的GUI控制台（只能适用于使用Jrockit才能使用jrockit81sp1_141_03自带的console监控一些cpu及memory参数）或者WebLogic Server控制台。

Bea JRockit JVM支持4种垃圾收集器：

4.1.1.分代复制收集器

它与默认的分代收集器工作策略类似。对象在新域中分配，即JRockit文档中的nursery.这种收集器最适合单cpu机上小型堆操作。

4.1.2.单空间并发收集器

该收集器使用完整堆，并与背景线程共同工作。尽管这种收集器可以消除中断，但是收集器需花费较长的时间寻找死对象，而且处理应用程序时收集器经常运行。如果处理器不能应付应用程序产生的垃圾，它会中断应用程序并关闭收集。

分代并发收集器 这种收集器在护理域使用排它复制收集器，在旧域中则使用并发收集器。由于它比单空间共同发生收集器中断频繁，因此它需要较少的内存，应用程序的运行效率也较高，注意，过小的护理域可以导致大量的临时对象被扩展到旧域中。这会造成收集器超负荷运作，甚至采用排它性工作方式完成收集。

4.1.3.并行收集器

该收集器也停止其他进程的工作，但使用多线程以加速收集进程。尽管它比其他的收集器易于引起长时间的中断，但一般能更好的利用内存，程序效率也较高。

默认状态下，JRockit使用分代并发收集器。要改变收集器，可使用-Xgc：，对应四个收集器分别为gencopy，singlecon，gencon以及parallel.可使用-Xms和-Xmx设置堆的初始大小和最大值。要设置护理域，则使用-Xns：java –jrockit –Xms512m –Xmx512m –Xgc：gencon –Xns128m?尽管JRockit支持-verbose：gc开关，但它输出的信息会因收集器的不同而异。JRockit还支持memory、load和codegen的输出。

注意 ：如果 使用JRockit JVM的话还可以使用WLS自带的console（C：

\bea\jrockit81sp1_141_03\bin下）来监控一些数据，如cpu，memery等。要想能构监控必须在启动服务时startWeblogic.cmd中加入－Xmanagement参数。

5.如何从JVM中获取信息来进行调整

-verbose.gc开关可显示gc的操作内容。打开它，可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。打开-xx：+ printgcdetails开关，可以详细了解gc中的变化。打开-XX： + PrintGCTimeStamps开关，可以了解这些垃圾收集发生的时间，自jvm启动以后以秒计量。最后，通过-xx： + PrintHeapAtGC开关了解堆的更详细的信息。为了了解新域的情况，可以通过-XX：=PrintTenuringDistribution开关了解获得使用期的对象权。

6.Pdm系统JVM调整

6.1.服务器：前提内存1G 单CPU

可通过如下参数进行调整：－server 启用服务器模式（如果CPU多，服务器机建议使用此项）

－Xms，－Xmx一般设为同样大小。 800m

－Xmn 是将NewSize与MaxNewSize设为一致。320m

－XX：PerSize 64m

－XX：NewSize 320m 此值设大可调大新对象区，减少Full GC次数

－XX：MaxNewSize 320m

－XX：NewRato NewSize设了可不设。4

－XX： SurvivorRatio 4

－XX：userParNewGC 可用来设置并行收集

－XX：ParallelGCThreads 可用来增加并行度 4

－XXUseParallelGC 设置后可以使用并行清除收集器

－XX：UseAdaptiveSizePolicy 与上面一个联合使用效果更好，利用它可以自动优化新域大小以及救助空间比值

6.2.客户机：通过在JNLP文件中设置参数来调整客户端JVM

JNLP中参数：initial-heap-size和max-heap-size

这可以在framework的RequestManager中生成JNLP文件时加入上述参数，但是这些值是要求根据客户机的硬件状态变化的（如客户机的内存大小等）。建议这两个参数值设为客户机可用内存的60％（有待测试）。为了在动态生成JNLP时以上两个参数值能够随客户机不同而不同，可靠虑获得客户机系统信息并将这些嵌到首页index.jsp中作为连接请求的参数。

在设置了上述参数后可以通过Visualgc 来观察垃圾回收的一些参数状态，再做相应的调整来改善性能。一般的标准是减少fullgc的次数，最好硬件支持使用并行垃圾回收（要求多CPU）。

Java程序性能调优的基本知识和JDK调优

一 基本知识

1.1 性能是什么

在性能调优之前，我们首先来了解一下性能是什么？关于性能，我想每个学习过Java的人都能列出几点，甚至可以夸夸其谈。在《Java TM Platform Performance》一书中，定义了如下五个方面来作为评判性能的标准：

1) 运算的性能——哪一个算法的执行性能最好？

2) 内存的分配——程序运行时需要耗费多少内存？

3) 启动的时间——程序启动需要多长时间？这在Web项目中的影响不大，但要注意部分程序需要部署或运行在客户端时的情形（比如applet程序）。

4) 程序的可伸缩性——在压力负载的情况下，程序的性能如何？

5) 性能的感知——用户在什么情况下会觉得程序的性能不好？

以上五个方面，在具体的使用场景可以有选择的去评判。至于这五方面的性能调优，在后续的章节中将会陆续的给以相应的性能调优策略。

1.2 调优的规则

我们只需要关心对我们程序有影响，可以察觉到的性能问题，而不是每一个类中的每一个方法我们都需要想方设法的提高性能。如果程序的性能没有达到我们所期 望的要求，我们才需要考虑如何优化性能。同样的，晦涩的代码虽然提高了程序的性能，但同时可能带给我们的是维护的噩梦。我们需要折中的考虑以上两种情况， 使得程序的代码是优美的，并且运行的足够快，达到客户所期望的性能要求。

优化代码甚至会导致不良的结果，Donald Knuth（一位比较牛比较有影响的人物，具体是谁，我也忘了，谁知道，可以告诉我一下，谢谢！）曾说过，“Premature optimization is the root of all evil”。在开始性能调优前，需要先指出不优化代码的一些理由。

1) 如果优化的代码已经正常工作，优化后可能会引入新的bug；

2) 优化代码趋向于使代码更难理解和维护；

3) 在一个平台上优化的代码，在另一个平台上可能更糟；

4) 花费很多时间在代码的优化上，提高了很少的性能，却导致了晦涩的代码。 确实，在优化前，我们必须认真的考虑是否值得去优化。

1.3 调优的步骤

一般我们提高应用程序的性能划分为以下几个步骤：

1) 明确应用程序的性能指标，怎样才符合期望的性能需求；

2) 在目标平台进行测试；

3) 如果性能已经达到性能指标，Stop；

4) 查找性能瓶颈；

5) 修改性能瓶颈；

6) 返回到第2步。

二 JDK调优

2.1 选择合适的JDK版本

不同版本的JDK，甚至不同厂家的JDK可能都存在着很大的差异，对于性能优化的程度不同。一般来说，尽可能选择最新发布的稳定的JDK版本。最新的稳定的JDK版本相对

以前的JDK版本都会做一些bug的修改和性能的优化工作。

2.2 垃圾收集Java堆的优化

垃圾收集就是自动释放不再被程序所使用的对象的过程。当一个对象不再被程序所引用时，它所引用的堆空间可以被回收，以便被后续的新对象所使用。垃圾收集 器必须能够断定哪些对象是不再被引用的，并且能够把它们所占据的堆空间释放出来。如果对象不再被使用，但还有被程序所引用，这时是不能被垃圾收集器所回收 的，此时就是所谓的“内存泄漏”。监控应用程序是否发生了内存泄漏，有一个非常优秀的监控工具推荐给大家——Quest公司的JProbe工具，使用它来 观察程序运行期的内存变化，并可产生内存快照，从而分析并定位内存泄漏的确切位置，可以精确定位到源码内。这个工具的使用我在后续的章节中还会做具体介 绍。

Java堆是指在程序运行时分配给对象生存的空间。通过-mx/-Xmx和-ms/-Xms来设置起始堆的大小和最大堆的大小。 根据自己JDK的版本和厂家决定使用-mx和-ms或-Xmx和-Xms。Java堆大小决定了垃圾回收的频度和速度，Java堆越大，垃圾回收的频度越 低，速度越慢。同理，Java堆越小，垃圾回收的频度越高，速度越快。要想设置比较理想的参数，还是需要了解一些基础知识的。 Java堆的最大值不能太大，这样会造成系统内存被频繁的交换和分页。所以最大内存必须低于物理内存减去其他应用程序和进程需要的内存。而且堆设置的太 大，造成垃圾回收的时间过长，这样将得不偿失，极大的影响程序的性能。以下是一些经常使用的参数设置：

1) 设置-Xms等于-XmX的值；

2) 估计内存中存活对象所占的空间的大小，设置-Xms等于此值，-Xmx四倍于此值；

3) 设置-Xms等于-Xmx的1/2大小；

4) 设置-Xms介于-Xmx的1/10到1/4之间；

5) 使用默认的设置。

大家需要根据自己的运行程序的具体使用场景，来确定最适合自己的参数设置。 除了-Xms和-Xmx两个最重要的参数外，还有很多可能会用到的参数，这些参数通常强烈的依赖于垃圾收集的算法，所以可能因为JDK的版本和厂家而有所 不同。但这些参数一般在Web开发中用的比较少，我就不做详细介绍了。在实际的应用中注意设置-Xms和-Xmx使其尽可能的优化应用程序就行了。对于性 能要求很高的程序，就需要自己再多研究研究Java虚拟机和垃圾收集算法的机制了。可以看看曹晓钢翻译的《深入Java虚拟机》一书。

使用GC Portal 来分析和优化垃圾回收的性能

Portal,port

本文已经过更新，以包括针对 Linux 和 Java Desktop System (JDS )的 GC Portal 软件， 其均可用于 Sun Java System Application Server 7 （以前称为 Sun Java System Application Server 7 (S1AS7)) 和 Tomcat Server。该款 GC Portal 软件最初仅用于 Solaris 和 Windows。该版本的 GC Portal 软件还含有集成到 GC Portal 中的 VisualGC。

通过挖掘由 JVM 生成的 verbose:gc 日志 ，GC Portal 可以从垃圾收集（GC）的角度来对 Java 应用程序进行分析和性能调优。GC Portal 是针对垃圾收集问题的“一站式”页面，并含有大量白皮书、示例案例研究和其他材料。这个 Portal 旨在与 Sun Microsystems 的 HotSpot JVM 一起使用，作为 J2SE 的一部分来发布的。使用 GC Portal 可使开发人员从垃圾收集的角度来对应用程序和 JVM 行为建模。本文介绍了 GC Portal 的设计和功能，使得开发人员可将其用作分析和 调优垃圾收集的一种工具。

为了生成由门户为了分析而处理的 verbose:gc 日志，GC Portal 要求由 JVM 使用以下的 switch 语句：

-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails

为了给 GC Portal 生成相应的日志，不需要使用其他的 JVM switch 语句，但是如果认为适合于调优 JVM 以及应用程序的规模和性能，也可以添加其他语句。 注意: -XX switch 语句是非标准的，在今后的 JVM 版本中可能会改变，恕不另行通知。 从垃圾收集的角度进行应用程序建模和性能调优

Java 应用程序建模使开发人员能够消除由于垃圾收集暂停的频率和持续时间的而引起的不可预知性。这些暂停直接与以下因素相关：

?

?

? 已创建并存活的对象的数目和总大小 这些对象的平均生存时间 JVM 堆的大小

根据 GC Portal 为输入到门户的特定 verbose:gc 日志文件集所提供的分析，开发人员可

以构建模型，这样可帮助他们更好地了解应用程序和 JVM 行为。 verbose:gc 日志包含了有关以下方面的有价值信息：

?

?

?

?

?

? 垃圾收集暂停时间 垃圾收集的频率 应用程序 已创建和已毁灭对象的大小 对象创建的速率 每次垃圾收集所回收的内存

可以对应用程序的行为绘制出图形并进行分析，以确定暂停持续时间、暂停频率、对象创建速率和被释放内存间的不同关系。对该信息的分析可使开发人员通过指定给定情况下的最佳堆大小、其他 JVM 选项以及可选的垃圾收集算法来调优应用程序的性能、优化垃圾收集的频率和收集时间。

来自 verbose:gc 日志的信息，用于分析垃圾收集行为并对其建模 该类信息可用于垃圾收集过程的性能调优。 新一代和老一代中的平均垃圾收集暂停 来源：互连网

作者：Alka Gupta

关键字：Portal,port

在 JVM 中进行垃圾收集时应用程序被暂停的平均时间。

新一代和老一代中的平均垃圾收集频率

垃圾收集器在新一代和老一代中运行的周期性。由于每个 GC 活动的时间实例都已记入日志，所以该信息是可以获得的。

垃圾收集连续开销

为进行垃圾收集而暂停应用程序的系统时间百分比。计算公式：平均垃圾收集暂停时间 * 平均垃圾收集频率 * 100%

垃圾收集并发开销

垃圾收集与应用程序运行并发进行的系统时间百分比。计算：平均并发垃圾收集时间（清除阶段）* 平均并发 GC 频率 / CPU 编号

在新一代和老一代中每次垃圾收集所回收的内存

每次垃圾收集期间所收集的总垃圾。

分配率

在新一代中应用程序分配数据的速率。如果新一代的堆的

occupancy_at_start_of_current_gc=x, occupancy_at_end_of_previous_gc = y 并且垃圾收集频率是每秒 1 次，那么分配率大约是每秒 x-y。

提升率

数据被提升到老一代的速率。

应用程序所分配的总数据

这是应用程序在每次事务处理中所分配的总数据。

总数据可以分成短期数据和长期数据

长期数据就是新一代垃圾收集周期中仍存活并且被提升到老一代的数据。 短期数据

短期存活的数据消亡得很快且被收集在新一代垃圾收集中。可以拿总数据减去长期数据来计算。

总的活动数据

这是在任何时间实例中总的存活数据。这对构建用于调整 JVM 堆大小的模型是至关重要的。例如，对于每秒加载 100 个事务，每个事务具有 50K 的长期数据，最短持续 40 秒，则老一代数据的最低内存占用将是：

50K*40s*100 = 200M

内存泄露

通过监视这些日志中所示的每次清除中所收集的垃圾，可以检测到内存泄露，并能更好地理解“内存不足”错误。

生成垃圾收集日志的标志和 Switch 语句

JVM 可以记录到文件中的有用 GC 相关信息很多。GC Portal 使用该信息，从垃圾收集的角度来调优应用程序以及 JVM 的大小和性能。 当 Java 应用程序使用以下 switch 语句运行时，将生成含有详细垃圾收集信息的这些日志： -verbose:gc

该标志打开垃圾收集信息的日志记录功能。在所有 JVM 中均可用。

-XX:+PrintGCTimeStamps

输出相对于应用程序开始时 GC 发生的时间。仅从 J2SE 1.4.0 中可用。 -XX:+PrintGCDetails

给出关于垃圾收集的详细信息，如：

?

?

?

? 垃圾收集前后新一代和老一代数据的大小 总堆的大小 垃圾收集在新一代和老一代中进行所花费的时间 在每次垃圾收集中所提升对象的大小

来源：互连网

作者：Alka Gupta

关键字：Portal,port

仅从 J2SE 1.4.0 中可用。

为应用程序建模和性能调优使用 GC Portal

GC Portal 可用于更好地理解应用程序的垃圾收集行为，以便调优性能并调整应用程序大小，从而使其能在 lean、peak 和 burst 条件下最佳地 运行。它支持 J2SE 1.2.2、J2SE 1.3、J2SE 1.4 和更新的J2SE 1.4.1，包括两个新的垃圾收集实现：并行收集器和并发收集器。它还允许开发人员提交垃圾收集日志文件并根据这些日志文件分析应用程序行为。它也考虑了 某些特定于应用程序和特定环境的信息，包括：

? 事务处理速率或服务器负载

这适用于运行在客户端 －服务器配置中的一般的服务器端应用程序。对于这样的应用程序，这是客户端可能为服务器生成稳定负载以进行处理的速率，并且这对于服务器的稳定状态分析是 很有用的。稳定状态分析可以包括情况，如最差/峰值/突发状况或平均状况。该信息不是强制的，如果它不可用或者不适用，可以将其忽略。在这样的情况下，门 户所表示的某些信息应该也可以被忽略，包括：

o 理论吞吐量

o 短期数据

o 长期数据

? 目标机器上的处理器数目

该信息由门户用于进行某些计算，如并发 GC 开销。

? 应用程序所用的 JVM 版本(1.2.2_xx、1.3.x、1.4.0、1.4.1)

由于 verbose:gc 日志格式不是标准的，不同的 JVM 中会有变化，所以 GC Portal 需要该信息。

GC Portal 设计

GC Portal 由 4 个引擎组成：

?

?

?

?

? 分析器和报告引擎 图形引擎 智能引擎 会话和存储引擎 VisualGC

分析器和报告引擎

?

? 加载 verbose:gc 日志文件、进行信息挖掘并报告: o 在新一代和老一代中的垃圾收集暂停 o 在新一代和老一代中的垃圾收集频率 o 对象分配的速率 o 对象从年轻提升到老一代的速率 o 总的垃圾收集时间 o 总的应用程序时间 o 新一代和老一代的最初和最终堆大小 o 垃圾收集连续开销 o 垃圾收集并发开销 计算并表示应用程序相关信息

o 每个事务的短期数据

o 每个事务的长期数据

o 理论最大吞吐量

o CPU 效率

对于不是基于事务的应用程序，该信息可以忽略，但对于客户端应用程序或者那些可能出现极为逐步行为的应用程序则是重要的。

?

? 随时间的变化表示应用程序和 JVM 的详细垃圾收集相关行为 用户可以查看垃圾收集数据, 对于整个运行以选定的时间间隔采样。

当应用程序随着时间的变化会显示出不同的行为，如状态、循环或随机地反应应用程序，以及平均汇总信息作为结果可能被曲解时，对整个运行在选定的间隔所采样的详细 垃圾收集信息非常有用。当其随时间而变化时，这些详细的和采样的信息可用于查看应用程序和 JVM

行为。

? 在新一代和老一代中随时间变化的详细内存回收信息

?

?

? 垃圾收集前的内存 垃圾收集后的内存 每次垃圾收集所释放的内存

? 在新一代中对象的老化信息

? 如果使用 -XX:+PrintTenuringDistribution switch 语句来生成日志文件时可

用。

图 1 是一个由 GC Portal 的分析器引擎所提交的示例报告抓图。 图 1. GC Portal 的分析引擎抓图 (点击看大图)

图形引擎

由分析器引擎以表的形式所提交的大部分信息都可以图形表示出来。可以向同一个图形中加入多个图表以帮助进行比较。

?

?

?

? 详细的时间线垃圾收集分析图形表示 每次垃圾收集的内存回收信息的图形表示 来自于不同日志文件 GC 信息的图形比较 每个“年龄”的对象生存时间延续的信息的图形表示

图 2. GC Portal 的图形引擎抓图 (点击看大图)

智能引擎

智能引擎由以下几部分组成：

? 一般的推荐

该部分提供了有关调优垃圾收集性能的一般信息和推荐文章。这个门户并不提供动态推荐或自动调优。推荐包含关于如何进行以下工作的一般信息：

o 减少垃圾收集的暂停和频率

o 减少垃圾收集连续开销

o 调整新一代和老一代堆的大小以处理给定的负载

o 检测内存泄露

o 选择收集器

o 选择不同的 JVM 选项和 switch 语句

? 经验性建模

根据从多个 verbose:gc 日志所分析出的数据来对应用程序运行划分等级，用户可以根据以下选择来选择用于建模的文件（在所有这些已加载的文件中选择）：

o 事务处理速率

o 处理器数目

o 新一代的大小

o 老一代的大小

o JDK 版本

o 堆大小

用户可以根据以下标准来对最佳的 JVM 环境划分等级：

o 垃圾收集暂停

o 垃圾收集顺序开销

o 垃圾收集频率

o CPU 效率

用户也可以查看不同运行的图形比较。

图 3. GC Portal 的智能引擎抓图 (点击看大图)

? 通过 "what-if" 场景来调优大小和性能的计划

垃圾收集的行为方式会随着新一代大小的改变而改变。该功能目前受到限制，仅工作在使用并发收集器的 J2SE1.4.1（及以上）上。

计划输出显示以下方面的可能变化：

?

?

?

?

?

?

?

?

? 垃圾收集暂停 垃圾收集频率 垃圾收集顺序负载 CPU 使用率 (%) 加速 分配速率 提升速率 短期的大小 长期数据的大小

? 案例研究

一些关于如何从垃圾收集角度进行性能调优的现实案例。

? 白皮书

指向某些有关垃圾收集调优的深入信息的白皮书。

会话和存储引擎

?

?

?

? 管理用户会话 管理并存储用户配置文件 安全地管理并存储用户数据/日志 确保用户/数据日志可用于参考查看和经验性建模

图 4. GC Portal 的存储引擎抓图 (点击看大图)

VisualGC

visualgc 工具隶属于一个 HotSpot JVM，它收集并以图形方式显示垃圾收集、类加载器和 HotSpot 编译器性能数据。它与 GC Portal 结合在一起，在 JVM 运行时收集有关垃圾收集的信息。GC Portal 使用 webstart 工具来在浏览器中运行和显示 visualGC 信息。有关该工具的更多信息可在 CoolStuff - jvmstat 网页获得。用于从 GC Portal 内运行 VisualGC 的 ReadMe 文件内建到 GC Portal 软件中。

下载和运行 GC Portal

请阅读 ReadMe 部分以下载、配置和运行 GC Portal 软件。

致谢

作者要感谢 Mayank Srivastava、Nagendra Nagarajayya、Nandula Narasimham 和 S.R.Venkatramanan，感谢他们对 GC Portal 的贡献。同时还要感谢 Sun JVM 垃圾收集架构师和专家 John Coomes、David Detlefs、Steve Heller、Peter Kessler、Ross Knippel、Jon Masamitsu、James Mcilree 和 Y.S. Ramakrishna，感谢他们对本文的帮助和指导。作者还要感谢 Sun 的 JVM 性能团队成员

Timothy Cramer 和 Brian Doherty (VisualGC 和 jvmstat 工具的编写者)，感谢他们有关将 VisualGC 集成到 GC Portal 中的帮助。

关于作者：

Alka Gupta 是 Sun 的 Technical Staff 部的成员。他负责与 Sun 的 ISV 和合作伙伴一同工作，并帮助他们快速而高效地采用 Sun 新推出的技术和平台。她在 Sun 平台上的性能调优领域已经工作了将近 10 年。Alka 毕业于印度理工大学(IIT)。

参考资料 ? ? ? ? ? ? ? ? ? ? ? ? Tuning Garbage Collection with the 1.4.2 Java Virtual Machine Tuning Garbage Collection with the 1.3.1 Java Virtual Machine Turbo-charging the Java HotSpot Virtual Machine, v1.4.x to Improve the Performance and Scalability of Application Servers Improving Java Application Performance and Scalability by Reducing Garbage Collection Times And Sizing Memory Using JDK 1.4.1 Java HotSpot VM Options New Parallel Collector Generational Mostly-concurrent Garbage Collector Sun Java System Sun Java System Application Server 7 JSR 174 Sun Docs VisualGC