九卅娱乐登录九卅娱乐登录


九卅体育官网

GC调优入门笔记

想给项目代码做做调优但有许多疑惑,比如有哪些参数要调、怎么调、使用什么工具、调优的效果如何定量测量等。发现Oracle的这份资料不错,简洁直接,回答了我的许多问题,给了许多很实用的大方向上的指导。将其中精华记录下来,希望能给同样入门的朋友一些启示。

Garbage Collectors

垃圾收集器 (Garbage Collectors)是JVM中的内存管理工具。它的职责包括:

在年轻代为对象分配空间,并将存活比较久的对象移动到年老代;在堆占用率超过某阈值时触发concurrent marking phase,在年老代找到存活的对象;触发parallel copying,压缩活着的对象,释放垃圾空间。

看起来有点抽象,并且貌似没提到年轻代的垃圾收集,其实已经在第一条中提到了:“将存活比较久的对象移动到年老代”,这里隐含了对年轻代进行存活对象登记和收集的过程。简而言之,垃圾收集器的职责是:给对象分配内存;收集年轻代垃圾;收集年老代垃圾

串/并行Garbage Collector的选择

一般来说,JVM会根据系统的物理配置等因素选择一个默认的垃圾处理器。但显然,不同的应用程序有不同的行为(如使用内存的频率、对象的平均存活时间);也有不同的要求(如有界面的程序要求响应快速,而服务器端程序要求吞吐量高,能处理更多的请求)。所以,根据不同程序的特点,可能需要不同的垃圾处理器来管理。在此处,我们先从串/并行的角度浅浅地了解一下这个问题。

垃圾处理器可以粗略地分为串行进行和并行进行的,即垃圾处理这个过程在单线程还是多线程中进行;在Java SE 1.4之前的版本不支持并行。根据Amdahl"s law (程序能够通过并行来加速的程度取决于程序中必须串行运行的部分),如果GC是串行进行的,则一个并行的应用程序的加速程度会受到GC的影响。假设我们通过增加处理器个数的方式来加速一个应用程序,那么随着处理器个数的增多,GC拖后腿的程度也越来越厉害,看下图:

GC时间所占的百分比随处理器个数的变化

这是一个数学模拟图,模拟了一个理想(完全并行)的应用程序的吞吐量受GC时间的影响。横轴代表处理器个数,纵轴代表吞吐量,不同颜色的曲线代表GC百分比不同的程序。红色曲线表示一条在单CPU下GC时间占1%的程序,在处理器个数增加到32个时,GC占整个程序运行时间的百分比竟超过了20%。

可以看到GC所占的时间百分比越大,拖后腿的程度就越厉害。这是一个很好理解的现象,因为GC是串行的,所以其运行时间不受处理器数量的影响。随着处理器的增多,应用程序本身的运行时间下降了,所以显得GC所占的时间百分比越来越大。

因此,在小系统上开发应用时可以忽略的一些GC小问题,当扩展到大型系统上时就会变得十分可观,甚至成为性能瓶颈。但是,此时在垃圾处理器上做一些小文章就有可能极大地增加性能。比如考虑到上图反映的现象,或许我们可以考虑换一个并行的垃圾处理器以提高吞吐量。

另一方面,小型应用如果不需要其他特殊的GC行为,通常使用串行垃圾处理器就够了,选择其他垃圾处理器可能反而会引入额外的复杂性和开销。

分代模型

在处理垃圾时,需要先找到所有活着的对象,然后将剩下的作为垃圾进行处理。“找到所有活着的对象”这个过程需要耗费的时间与活着的对象数量成正比,这样的话,如果应用中本来就维护了大量的存活对象,那么找到活着的对象需要耗费大量的时间。为了优化这个过程,JVM程序员们基于一些经验提出了分代收集的思想。在这些经验中,最重要的是分代假设,即大部分对象都只存活很短的时间。

对象寿命的典型分布图

上图中,横轴代表总的字节分配数,即时间轴;纵轴代表不同时间下存活的对象所占字节数。左边的尖峰代表分配空间没多久就可以回收的对象,比如在某个loop中临时分配的对象,它们的寿命只有一个loop的时间;最右边代表存活很久的那些对象,比如初始化时就存在且一直活到程序结束的对象;在这两极之间,有一些用于中间计算的对象,即左边的尖峰右边的这个包。

不同应用程序的对象寿命分布图是不一样的,但是许多应用的大致分布都符合上面这个图,这为分代收集奠定了一个很好的事实基础:大部分对象都在年轻时死去。

比如在一个公园里扫落叶,腾出空地让行人行走。有一些树掉叶子特别厉害,一小会儿地上就掉满了;而另外一些树每小时只掉一两片叶子。假设清洁工为了省力,每过一段时间就清扫一次,扫完了则回到椅子上休息。如果我是清洁工,肯定会选择集中打扫那些掉得厉害的树,而且可能会以比较高的频率打扫;至于那些掉得不厉害的树,只要偶尔看一下,等落满的时候再打扫就好了。如果每次都要把所有的树下打扫一遍,为了照顾那些掉得厉害的树我的打扫频率需要很高,我会很累,而且打扫时间也会变长,效率降低。

除了串行收集器和G1之外,其他收集器默认使用以下分代模型:

默认分代模型

模型分为年轻代和年老代,年轻代分为eden和两个survivor,virtual空间代表JVM向操作系统预订但还未实际分配的空间。

调优指标

maximum pause time

pause time是指垃圾处理器停止应用程序的运行,专注于空间释放时所花的时间。如果使用的是并行垃圾处理器,可以通过-XX:MaxGCPauseMillis=<nnn>这个命令行参数设定期望的最大pause time。(如果未设置,默认没有最大时间要求)

垃圾处理器会维护每次垃圾收集pause time的均值和方差,当均值与方差的和大于设置的MaxGCPauseMillis参数时,垃圾处理器会认为停留时间目标未达到,然后调整堆的大小和其它的有关参数来试图达到目标。

此处的maximum pause time和下面即将提到的throughput是一对相爱相杀的姐妹。通常减小堆size会优化pause time(扫描、处理时间减少),但是堆变小造成GC频率升高,从而导致throughput下降。对于这两者,垃圾处理器的处理方式是优先达到设置的pause time目标,其次再达到throughput目标。

throughput

吞吐量通过GC时间比例测量。 GC时间比例 = GC时间 / (GC时间 + 应用运行时间),其中的GC时间包括所有代的GC时间。如果使用的是并行垃圾处理器,吞吐量可以通过-XX:GCTimeRatio=<nnn>设置,若<nnn>为19,则GC时间比例为1/(1+19)=5%,即垃圾处理的时间占总时间的5%。

如果GCTimeRatio未达到要求,垃圾收集器会增加年轻代和年老代的大小来降低GCTimeRatio

footprint

内存占用(memory footprint)指程序运行时占用和引用的内存大小。

如果前面两个目标达到了,垃圾处理器会自动收缩堆,直至其中一个目标不再满足(一定是throughput,因为堆变小会使停留时间变短),然后再试图满足这个目标。

promptness

及时性 (promptness)定义为对象死去之后到对象所占用的内存可以使用之前的时间。这个指标对分布式系统通常比较重要。

一般调优策略

    如果堆已经达到maximum heap size但throughput目标还未达到,说明设置的maximum heap size太小,可以尝试将其设为接近物理内存但还不至于导致内存交换的值。如果还是达不到throughput目标,说明这个throughput目标对于当前平台上的内存大小来说过高了。如果throughput目标已经满足,但停留时间过长,则可以增加maximum pause time目标。但这样throughput目标有可能又得不到满足了,此时需要根据自己的判断作一个折中。如上文所说,throughput与pause time对堆大小的要求相反,是一对相互竞争的指标。它们之间的相互竞争可能造成的结果是:即使应用程序已经在稳定运行了,堆大小仍然在上下振动。这表明垃圾处理器努力在两者之间寻找一个平衡。

度量

以上所说的throughput等指标需要根据应用的不同特性去测量。比如要测一个web server的throughput,可以用一个自己写的client load generator;测试Solaris系统上服务器的内存占用,可以用pmap这个命令;若要测GC的停留时间,则可以通过命令行参数-verbose:gc直接观察JVM的诊断输出。

总结

本文定性介绍了GC调优的一些初级概念,为实际调优奠定基础。但仅有这些模糊概念是远远不够的,在理论和实践上还会作出其它总结,欢迎关注。

参考资料/推荐阅读

Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide 文中提到的资料,Oracle写的,具有官方指导意义

深入理解Java虚拟机 推荐看第4-5章,详细讲解了调优工具的使用以及几个调优实例

高质量Java程序设计 推荐看第3章,作者用一个xml parser的例子给出了调优实战讲解,可惜本书不再再版,也未找到电子版

欢迎阅读本文章: 封华

bet9官网

九卅体育官网