JVM-GC工做原理

  配置Garbage Collection  2012-09-17 14:53:18

分类： Java

 

 

        上面这幅图是我从网络上摘到的，它展示了在一个的理想系统的模型下GC对系统的影响。图的最顶上红色线条显示出一个应用程序在单处理器环境下花费1%的时间作GC的状况。而其转换到32个处理器的设备上将致使损失超过20%的吞吐率。作10%的GC将损失超过70%的吞吐率。所以能够看出对GC稍稍的调整能够带了性能巨大的变化。

        1、概述

        Java 2 平台的一个最大好处在于将开发者从大量错综复杂的内存分配和回收中解放出来。可是，一次GC也可能成为一个主要的瓶颈问题，所以它变成有价值和必要去理解那些隐藏的实现部分。GC老是假设应用程序使用对象的策略，GC的这些行为能够经过可调的参数来进行调整以提升性能。

        在运行的程序中再也不被任何一个指针所引用，则它就成为垃圾。许多简单的垃圾回收算法仅仅是简单的迭代每个可到达的对象，一些残留的不可到达的对象就成为垃圾。这种方式会依据存活对象的数量而成比例的影响时间的消耗，当一个庞大的应用有许多存活的对象时，这个代价是巨大的。

        从JVM1.3版开始已经加入一些不一样的垃圾回收算法用于GC。当简单的垃圾回收器检查每个在堆中存活的对象时，垃圾回收器利用凭经验获取的许多应用程序的属性设置去回避额外的工做。

        这些属性中最重要的是infant mortality。

         上图中蓝色区域是一个典型的对象生存时间的分布。在图中左边描述的对象呈现山峰形状，它们能够在分配后马上回收利用。迭代器对象，如单循环中是存活的。有些对象存活期很长，所以它一直延伸到图的右边。例如，一些典型的对象从初始化开始一直到程序退出都一直存活着。在两端中间存活的对象都存在于一些中间计算过程当中，在图中表如今infant mortality峰顶的右边这么一团蓝色区域。一些应用程序的图看上去会很是的不一样，但它们会和此图类似。有效收集可能被高度关注，大部分对象在Young中就死亡了。

         为此，内存在代（Generations）中被管理：内存池控制着不一样年龄的对象。当Generation被添满时，GC在就被开始工做，每一个代都会独自发生这种状况。对象在Eden中被分配，由于初期不少对象都在这里死亡。当Eden被填满时就会发生minor collection，其中一些幸存的对象被移动到Old Generation中，当Old Generation须要被回收，这就是一个major collection ，它的运行经常很是慢，由于它要涉及全部存活着的类。

       许多收集器都会去容忍长时间幸存的对象，并减小GC的发生。默认的GC参数设置是被用于许多小应用程序的。它们不是去优化许多服务器应用的，记住：

       若是GC成为瓶颈，你应该去配置Generation的大小；检查GC的输出，而且尝试改变配置适合你独特状况的配置。

       2、收集类型

       每种不一样的收集类型都对系统产生不一样影响，从JDK 1.3版本以后系统提供了3类彻底不一样三种GC：

       Copying：有时又被称为Scavenge，这个收集器在两个或多个代中移动对象很是高效，原代被清空，容许残留的死亡对象被快速回收，然而，Coping要求更多的轨迹，所以它将请求一个空闲内存去工做。在1.3.1版本后Copying收集被应用于全部的minor collections。

        Mark-compact：这个收集器容许代在不增长额外内存的状况下在本地回收。可是很明显它要慢于Copying方式。在1.3.1版本后mark-compact 收集被应用于全部的major collections。

        Incremental：有时又被称为train。此收集器只在当在命令行中指定-Xincgc 才生效。但通过仔细的簿记，Incremental GC在同一个时间仅仅回收old generation 中的一部分，并引发major collection 一个长时间暂停，甚至超过许多minor collections。可是考虑到所有性能，它一般比Mark-compact收集慢。

        所以copying收集是最快的，使用copying尽量收集许多对象是咱们的目标，而不是使用Mark-compact和Incremental收集。

        默认的代的排列以下图所示：

       在最开始的时候，最大的地址空间其实是被保留的，除非必要它才被分配。全部的地址空间被做为对象保留，内存能够被分配到一个Young和Old代中。

       一个Young代包含一个Eden和二个survivor空间，对象最开始是被分配在Eden中的，一个Survivor空间在任什么时候间都是空的，服务于在Eden和另外一个Survivor空间中下一个Copying收集后仍然存活的对象。对象以这种方式在Survivor空间之间进行拷贝，直到它们的年龄达到持久化（此时被拷贝到Old代中）。

      （其余虚拟机，包括1.2版JVM，为Copying使用两个大小相等的空间，而不是一个大的Eden和二个小的空间。这意味者Young代的大小不是直接能够比较的。）

        Old代在这里是采用mark-compact进行收集的。

        Permanent代的调用是很特殊的部分，它掌握着JVM本身映射的数据如类和对象方法。

        3、性能注意事项

       GC性能有两个重要的方面：

       吞吐率：在GC中在长时间运行状况下有效利用时间占总时间的百分比。吞吐率包括了在分配中浪费的时间（但不包括分配速度的调整是不包括的）。

       暂停时间：当一个应用程序出现由于GC工做而中止工做的时间。

       用户能够有不一样的关于GC的需求。例如，一些优先考虑Web 服务的吞吐率，所以能够忍受暂停，或被网络因素所掩盖。单一个交互的图像程序，即时短暂的暂停都是让用户没法满意的。

       一些用户对其它的东西敏感。

      轨迹是一个进程的做业集，用于权衡在页和缓存中的行数。一个在物理内存或多处理器方面受限的系统，轨迹能够有不少伸缩性。

      敏捷度是从一个对象死亡到这个内存变成可用之间的时间跨度。一个重要的考虑就是分布式系统的RMI。

      通常的，代的大小选择就是基于这些考虑进行的。例如，一个很是巨大的Young代能够提供最大的吞吐率，但要付出轨迹和敏捷度的代价。使用一个小的Young带，采用incremental收集方式暂停时间能够最小化，但要付出吞吐率的代价。

       这里不存在惟一正确的方法来配置代的大小，最好的方法是应用程序使用的内存和用户需求一致。由于这个理由JVM是没有选择优化的，用户能够经过命令行的方式对其进行修改。

       4、测量方法

      对于一个应用程序吞吐率和轨迹能够经过指标来测量，例如，Web服务的吞吐率能够经过在客户端装载发生器来进行测试，轨迹在Solaris操做系统中经过pmap命令来获取。暂停时间能够经过GC的输出预估出来。

   经过在命令行中加入-verbose:gc 能够打印出每个收集器的信息，例如，下面的例子给出了一个大型服务应用的输出：

  [GC 325407K->83000K(776768K), 0.2300771 secs]
  [GC 325816K->83372K(776768K), 0.2454258 secs]
  [Full GC 267628K->83769K(776768K), 1.8479984 secs]

  经过这个输出咱们能够看到有二个minor collections工做和一个major collections工做。经过箭头先后数据咱们能够看到GC前和后活着的对象占用内存大小。minor collections 后包括对象的数量不表示他们还活着，只是表示他们没有被回收。这是由于他们可能确实活着，也可能他们在Old代中。圆括号中间的数字表示能够内存大小，它是总堆大小减去一个survivor空间大小。

   5、代的大小

  下图中给出了一些能够改变代大小的参数。

        6、所有堆

       当代被填满后发生收集，吞吐率和可用内存数量成反比例，总的可用内存大小很是影响GC的性能。每次收集时无论是增减，JVM都会努力按照必定的比率为存活的对象保留自由空间。这个目标比例是一个用百分数表示的参数-XX:MinHeapFreeRatio=<minimum> 和 -XX:MaxHeapFreeRatio=<maximum> 的集合，而且总的堆的大小界定于-Xms 和-Xmx 指定的范围内，大小值大于-Xms 指定的值，但小于-Xmx 指定的值。

      在Solaris操做系统中默认的值以下：

      -XX:MinFreeHeapRatio= 40

   -XX:MaxHeapFreeRatio= 70

   -Xms                = 3584k

   -Xmx                = 64m
   大型的服务器应用系统应用这个默认配置有两个方面的问题，一是启动很慢，由于初始堆很是小必须使用屡次major collections来调整堆的大小。一个更紧迫的问题是默认的最大堆的大小对于大多少服务应用来讲过度的小，对于服务应用程序的经验法则是：

   除非暂停时间对你是不容忽视的问题，不然分配可能的足够大的内存给JVM，默认的64M内存过小。设置-Xms 和-Xmx 到相同的值，以增长JVM作重要的大小调整时被进行内存清理的可能性。另外一方面，若是你的配置不恰当，JVM是不能对此进行补偿和优化的。

   必定要增长内存就如同你增长处理器同样，由于内存分配是能够并行的，但GC是不能并行工做的。

   7、Young代

   第二个有影响的突出问题是堆的一部分被划归Young代专用。 一个更大的Young代常不多发生minor collections。在一个有限的堆中，较大的Young代意味着有很小的Old代，这将增长major collections发生的频率。优化的选择来源于应用中生命周期的分布。

   默认的Young代的大小由NewRatio参数控制，例如，设置-XX:NewRatio=3意味着Young代和Old代的比率是1:3。换句话说，Eden和Survivor空间总和是整个堆大小的四分之一。

   NewSize和MaxNewSize两个参数指定了Young代的下限和上限值。设定他们相等的值就固定了Young代大小，就如同设置-Xms和-Xmx 两个值相等就固定整个堆大小同样。这种方式比经过NewRatio参数调整总体倍数要处理的更加精细。

   由于Young代采用的是copying收集，在Old代中必须有充足的空闲内存被保留这样才能保障minor collection 能够正常完成。最坏的状况，这个被保留的内存大小会等于Eden空间大小加上Survivor中非空空间大小之和。在最糟糕的状况下，若是Old代中没有足够可用的空间，一个major collection 将被代替发生。这个策略对于小应用系统是很是好的，由于在Old代中保留的内存其实是被提交但没有被使用。除非应用程序须要一个最大的堆，Eden空间超过堆中实际提交内存大小的一半是没有意义的，此时major collections将发生。

   若是指望SurvivorRatio参数能够用来调整Survivor空间大小，但它经常不是最重要的。例如，-XX:SurvivorRatio=6设置Survivor和Eden空间的比例为1：6，换句话朔，每个Survivor空间将是Young代大小的八分之一（为何不是七分之一？由于Young带中有二个Survivor空间）。

   若是Survivor空间过小，Copying收集将直接将其转移到Old代中。若是Survivor空间太大，他们将无有的空闲。每个JVM的GC都会选择一个对象生存时间的阀值，低于这个阀值的将作Copying收集，高于这个阀值的将被转入Tenured。这个门槛值被设置为Survivor空间一半满。（在1.3.1版本后可使用-XX:+PrintTenuringDistribution 来显示这个门槛值和对象在新代中的年龄，这对于观察应用程序生命周期的分布是有益的）

   下面列出了在Solaris操做系统中的默认值：

   NewRatio       =  2   (client JVM: 8)

   NewSize        =  2172k

   MaxNewSize     =  32m

   SurvivorRatio  =  25

   服务应用系统的一些遵循的准则以下：

   首先肯定能够给予JVM的总的内存值，描绘你本身的性能指标，而后依靠Young代的大小去发现最好的设置。

   除非你发现有过多的major collection 或 暂停时间过长，你应该分配大量的内存到Young代，默认的MaxNewSize 为32MB，这过小了。

   增长Young代大小到总堆大小的一半或少些将是无效果的。

   增长Young代大小就如同你增长处理器数量同样，由于内存分配是并行的，但GC不能并行。

   8、其它考虑
   许多应用程序的permanent代大小设置对于GC来讲是不合适的。一些应用程序动态的产生和装载不少类，例如，一些JSP的实现就是这么作的。若是必要的话，经过MaxPermSize参数能够设置最大的permanent代的大小。

   一些使用finalization和weak/soft/phantom 引用的应用程序的GC是相互影响的。这些因素能够致使在JAVA程序语言级别的进行优化的问题，一个依赖finalization关闭文件描述的例子，这就产生一个外部资源依赖GC的敏捷度来完成工做，利用GC来管理资源这是一个十分糟糕的想法。

   另外一种应用程序经过明显的调用GC来实现和GC的互动，例如经过System.gc() 来调用。这些调用强制执行major collection，在大系统上抑制了其可伸缩性。显示调用GC会受到-XX:+DisableExplicitGC标志的影响。

   通常显示使用GC的地方发生在RMI的分布式GC时，应用程序使用RMI涉及到对象在另外一个JVM中，除偶然本地分配的对象外，这些分布式应用的垃圾是不能被回收的，如有RMI周期性的强制进行彻底的收集。这些强制收集的频率是能够被一些属性控制的，例如：

   java -Dsun.rmi.dgc.client.gcInterval=3600000
       -Dsun.rmi.dgc.server.gcInterval=3600000 ...

   这代表原来默认每分钟进行一次的频率被替换成每小时进行一次。它可能由于其它对象的缘由花费更长的时间才被收集。这些属性能够被设置成很是高很是长，MAX_VALUE 能够设置时间介于无限大时间之间，若是没有特别说明这个值能够是DGC（分布式GC）时间线的上面。

      在服务器上的JVM对软件引用的清除比在客户机上较积极。经过增长-XX:SoftRefLRUPolicyMSPerMB=10000这样一个参数能够将清除率减慢，默认值是1000，或每兆字节一秒。

   对于巨大系统他们还有其它参数能够去改善性能。

   9、结论

   GC在高度并行的系统里会成为瓶颈。理解GC是如何工做的，再经过命令行参数去下降影响。