浅谈Sun JVM中的内存管理及调优

1. Sun JVM的GC概述

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

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

垃圾收集的目的在于清除再也不使用的对象。GC经过肯定对象是否被活动对象引用，来肯定是否收集该对象。GC首先要判断该对象是不是时候能够收集。两种经常使用的方法是引用计数和对象引用遍历。

1.1. 引用计数

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

1.2. 对象引用遍历

早期的Sun JVM使用引用计数，如今大多数Sun JVM采用对象引用遍历。对象引用遍历从一组对象开始，沿着整个对象图上的每条连接，递归肯定可到达（reachable）的对象。若是某对象不能从这些根对象的一个（至少一个）到达，则将它做为垃圾收集。在对象遍历阶段，GC必须记住哪些对象能够到达，以便删除不可到达的对象，这称为标记（marking）对象。

下一步，GC要删除不可到达的对象。删除时，有些GC只是简单的扫描堆栈，删除未标记的对象，并释放它们的内存以生成新的对象，这叫作清除（sweeping）。这种方法的问题在于内存会分红好多小段，而它们不足以用于新的对象，可是组合起来却很大。所以，许多GC能够从新组织内存中的对象，并进行压缩（compact），造成可利用的空间。

为此，GC须要中止其余的活动。这种方法意味着全部与应用程序相关的工做中止，只有GC运行。结果，在响应期间增减了许多混杂请求。另外，更复杂的GC不断增长或同时运行，以减小或者清除应用程序的中断。有的GC使用单线程完成这项工做，有的则采用多线程以增长效率。

2. 几种垃圾回收机制

2.1. 标记－清除收集器

这种收集器首先遍历对象图并标记可到达的对象，而后扫描堆栈以寻找未标记对象并释放它们的内存。这种收集器通常使用单线程工做并中止其余操做。

2.2. 标记－压缩收集器

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

2.3.复制收集器

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

2.4.增量收集器

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

2.5.分代收集器

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

2.6.并发收集器

并发收集器与应用程序同时运行。这些收集器在某点上（好比压缩时），通常都不得不中止其余操做，以完成特定的任务，可是由于其余应用程序可进行其余的后台操做，因此中断其余处理的实际时间大大下降。

2.7.并行收集器

并行收集器使用某种传统的算法，并使用多线程并行地执行它们的工做。在多cpu机器上使用多线程技术能够显著的提升java应用程序区性的可扩展性。

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

Sun HotSpot 1.4.1使用分代收集器，它把堆分为三个主要的域：新域、旧域以及永久域。Sun JVM生成的全部新对象放在新域中。一旦对象经历了必定数量的垃圾收集循环后，便得到使用期并进入旧域。在永久域中Sun 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。运行程序时，Sun JVM会调整永久域的大小以知足须要。每次调整时，Sun JVM会对堆进行一次彻底的垃圾收集。

使用-XX:MaxPerSize标志来增长永久域的大小。在WebLogic Server应用程序加载较多类时，常常须要增长永久域的最大值。当Sun JVM加载类时，永久域中的对象急剧增长，从而使Sun 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 Sun JVM的使用

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

Bea JRockit Sun 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 Sun JVM的话还可使用WLS自带的console（C:beajrockit81sp1_141_03bin下）来监控一些数据，如cpu，memery等。要想可以监控必须在启动服务时startWeblogic.cmd中加入－Xmanagement参数。

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

-verbose.GC开关可显示GC的操做内容。打开它，能够显示最忙和最空闲收集行为发生的时间、收集先后的内存大小、收集须要的时间等。打开-xx:+ printGCdetails开关，能够详细了解GC中的变化。打开-XX: + PrintGCTimeStamps开关，能够了解这些垃圾收集发生的时间，自Sun JVM启动之后以秒计量。最后，经过-xx: + PrintHeapAtGC开关了解堆的更详细的信息。为了了解新域的状况，能够经过-XX:=PrintTenuringDistribution开关了解得到使用期的对象权。

6.Pdm系统Sun 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文件中设置参数来调整客户端Sun JVM

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

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

在设置了上述参数后能够经过VisualGC 来观察垃圾回收的一些参数状态，再作相应的调整来改善性能。通常的标准是减小fullGC的次数，最好硬件支持使用并行垃圾回收（要求多CPU）