图片 4

Java深入 – Java 内存分配和回收机制

jvm系列(九):如何优化Java GC「译」,jvm

本文由CrowHawk翻译,地址:如何优化Java GC「译」,是Java
GC调优的经典佳作。

Sangmin Lee发表在Cubrid上的”Become a Java GC
Expert”系列文章的第三篇《How to Tune Java Garbage
Collection》,本文的作者是韩国人,写在JDK
1.8发布之前,虽然有些地方有些许过时,但整体内容还是非常有价值的。译者此前也看到有人翻译了本文,发现其中有许多错漏生硬和语焉不详之处,因此决定自己翻译一份,供大家分享。

本文是“成为Java GC专家”系列文章的第三篇,在系列的第一篇文章《理解Java
GC》中,我们了解到了不同GC算法的执行过程、GC的工作原理、新生代和老年代的概念、JDK
7中你需要了解的5种GC类型以及每一种GC对性能的影响。

在系列的第二篇文章《如何监控Java
GC》中笔者已经解释了JVM进行实时GC的原理、监控GC的方法以及可以使这一过程更加迅速高效的工具。

在第三篇文章中,笔者将基于实际生产环境中的案例,介绍几个GC优化的最佳参数设置。在此我们假设你已经理解了本系列前两篇文章的内容,因此为了更深入的理解本文所讲内容,我建议你在阅读本篇文章之前先仔细阅读这两篇文章。

本文由CrowHawk翻译,地址:如何优化Java
GC「译」,是Java
GC调优的经典佳作。

Java的GC机制是自动进行的,和c语言有些区别需要程序员自己保证内存的使用和回收。

GC优化是必要的吗?

或者更准确地说,GC优化对Java基础服务来说是必要的吗?答案是否定的,事实上GC优化对Java基础服务来说在有些场合是可以省去的,但前提是这些正在运行的Java系统,必须包含以下参数或行为:

  • 内存大小已经通过-Xms-Xmx参数指定过
  • 运行在server模式下(使用-server参数)
  • 系统中没有残留超时日志之类的错误日志

换句话说,如果你在运行时没有手动设置内存大小并且打印出了过多的超时日志,那你就需要对系统进行GC优化。

不过你需要时刻谨记一句话:GC tuning is the last task to be done.

现在来想一想GC优化的最根本原因,垃圾收集器的工作就是清除Java创建的对象,垃圾收集器需要清理的对象数量以及要执行的GC数量均取决于已创建的对象数量。因此,为了使你的系统在GC上表现良好,首先需要减少创建对象的数量。

俗话说“冰冻三尺非一日之寒”,我们在编码时要首先要把下面这些小细节做好,否则一些琐碎的不良代码累积起来将让GC的工作变得繁重而难于管理:

  • 使用StringBuilderStringBuffer来代替String
  • 尽量少输出日志

尽管如此,仍然会有我们束手无策的情况。XML和JSON解析过程往往占用了最多的内存,即使我们已经尽可能地少用String、少输出日志,仍然会有大量的临时内存(大约10-100MB)被用来解析XML或JSON文件,但我们又很难弃用XML和JSON。在此,你只需要知道这一过程会占据大量内存即可。

如果在经过几次重复的优化后应用程序的内存用量情况有所改善,那么久可以启动GC优化了。

笔者总结了GC优化的两个目的:

  1. 将进入老年代的对象数量降到最低
  2. 减少Full GC的执行时间

Sangmin Lee发表在Cubrid上的”Become a Java
GC Expert”系列文章的第三篇《How to Tune Java Garbage
Collection》,本文的作者是韩国人,写在JDK
1.8发布之前,虽然有些地方有些许过时,但整体内容还是非常有价值的。译者此前也看到有人翻译了本文,发现其中有许多错漏生硬和语焉不详之处,因此决定自己翻译一份,供大家分享。

Java的内存分配和回收也主要在Java的堆上进行的,Java的堆中存储了大量的对象实例,所以Java的堆也叫GC堆。

将进入老年代的对象数量降到最低

除了可以在JDK 7及更高版本中使用的G1收集器以外,其他分代GC都是由Oracle
JVM提供的。关于分代GC,就是对象在Eden区被创建,随后被转移到Survivor区,在此之后剩余的对象会被转入老年代。也有一些对象由于占用内存过大,在Eden区被创建后会直接被传入老年代。老年代GC相对来说会比新生代GC更耗时,因此,减少进入老年代的对象数量可以显著降低Full
GC的频率。你可能会以为减少进入老年代的对象数量意味着把它们留在新生代,事实正好相反,新生代内存的大小是可以调节的。

本文是“成为Java GC专家”系列文章的第三篇,在系列的第一篇文章《理解Java
GC》中,我们了解到了不同GC算法的执行过程、GC的工作原理、新生代和老年代的概念、JDK
7中你需要了解的5种GC类型以及每一种GC对性能的影响。

Java在垃圾收集的过程中,主要用到了分代收集算法,我会先讲一下常用垃圾收集算法。

降低Full GC的时间

Full GC的执行时间比Minor GC要长很多,因此,如果在Full
GC上花费过多的时间(超过1s),将可能出现超时错误。

  • 如果通过减小老年代内存来减少Full
    GC时间
    ,可能会引起OutOfMemoryError或者导致Full GC的频率升高。
  • 另外,如果通过增加老年代内存来降低Full GC的频率,Full
    GC的时间可能因此增加。

因此,你需要把老年代的大小设置成一个“合适”的值

在系列的第二篇文章《如何监控Java
GC》中笔者已经解释了JVM进行实时GC的原理、监控GC的方法以及可以使这一过程更加迅速高效的工具。

常用垃圾收集算法

影响GC性能的参数

正如我在系列的第一篇文章《理解Java
GC》末尾提到的,不要幻想着“如果有人用他设置的GC参数获取了不错的性能,我们为什么不复制他的参数设置呢?”,因为对于不用的Web服务,它们创建的对象大小和生命周期都不相同。

举一个简单的例子,如果一个任务的执行条件是A,B,C,D和E,另一个完全相同的任务执行条件只有A和B,那么哪一个任务执行速度更快呢?作为常识来讲,答案很明显是后者。

Java
GC参数的设置也是这个道理,设置好几个参数并不会提升GC执行的速度,反而会使它变得更慢。GC优化的基本原则是将不同的GC参数应用到两个及以上的服务器上然后比较它们的性能,然后将那些被证明可以提高性能或减少GC执行时间的参数应用于最终的工作服务器上。

下面这张表展示了与内存大小相关且会影响GC性能的GC参数

表1:GC优化需要考虑的JVM参数

类型 参数 描述
堆内存大小 -Xms 启动JVM时堆内存的大小
-Xmx 堆内存最大限制
新生代空间大小 -XX:NewRatio 新生代和老年代的内存比
-XX:NewSize 新生代内存大小
-XX:SurvivorRatio Eden区和Survivor区的内存比

笔者在进行GC优化时最常用的参数是-Xms,-Xmx-XX:NewRatio-Xms-Xmx参数通常是必须的,所以NewRatio的值将对GC性能产生重要的影响。

有些人可能会问如何设置永久代内存大小,你可以用-XX:PermSize-XX:MaxPermSize参数来进行设置,但是要记住,只有当出现OutOfMemoryError错误时你才需要去设置永久代内存。

还有一个会影响GC性能的因素是垃圾收集器的类型,下表展示了关于GC类型的可选参数(基于JDK
6.0):

表2:GC类型可选参数

GC类型 参数 备注
Serial GC -XX:+UseSerialGC
Parallel GC -XX:+UseParallelGC-XX:ParallelGCThreads=value
Parallel Compacting GC -XX:+UseParallelOldGC
CMS GC -XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:+CMSParallelRemarkEnabled-XX:CMSInitiatingOccupancyFraction=value-XX:+UseCMSInitiatingOccupancyOnly
G1 -XX:+UnlockExperimentalVMOptions-XX:+UseG1GC 在JDK 6中这两个参数必须配合使用

除了G1收集器外,可以通过设置上表中每种类型第一行的参数来切换GC类型,最常见的非侵入式GC就是Serial
GC,它针对客户端系统进行了特别的优化。

会影响GC性能的参数还有很多,但是上述的参数会带来最显著的效果,请切记,设置太多的参数并不一定会提升GC的性能。

在第三篇文章中,笔者将基于实际生产环境中的案例,介绍几个GC优化的最佳参数设置。在此我们假设你已经理解了本系列前两篇文章的内容,因此为了更深入的理解本文所讲内容,我建议你在阅读本篇文章之前先仔细阅读这两篇文章。

1. 标记-清除算法

这种垃圾收集算法思路非常简单,主要是首先标记出所有需要回收的对象,然后回收所有需要回收的对象。

但是有一个明显的缺点,采用这种算法之后会发现内存块回收之后就不连续了,这就导致了在下一次想分配一个大内存块的时候无法分配。

图片 1

GC优化的过程

GC优化的过程和大多数常见的提升性能的过程相似,下面是笔者使用的流程:

GC优化是必要的吗?

或者更准确地说,GC优化对Java基础服务来说是必要的吗?答案是否定的,事实上GC优化对Java基础服务来说在有些场合是可以省去的,但前提是这些正在运行的Java系统,必须包含以下参数或行为:

  • 内存大小已经通过-Xms-Xmx参数指定过
  • 运行在server模式下(使用-server参数)
  • 系统中没有残留超时日志之类的错误日志

换句话说,如果你在运行时没有手动设置内存大小并且打印出了过多的超时日志,那你就需要对系统进行GC优化。

不过你需要时刻谨记一句话:GC tuning is the last task to be done.

现在来想一想GC优化的最根本原因,垃圾收集器的工作就是清除Java创建的对象,垃圾收集器需要清理的对象数量以及要执行的GC数量均取决于已创建的对象数量。因此,为了使你的系统在GC上表现良好,首先需要减少创建对象的数量。

俗话说“冰冻三尺非一日之寒”,我们在编码时要首先要把下面这些小细节做好,否则一些琐碎的不良代码累积起来将让GC的工作变得繁重而难于管理:

  • 使用StringBuilderStringBuffer来代替String
  • 尽量少输出日志

尽管如此,仍然会有我们束手无策的情况。XML和JSON解析过程往往占用了最多的内存,即使我们已经尽可能地少用String、少输出日志,仍然会有大量的临时内存(大约10-100MB)被用来解析XML或JSON文件,但我们又很难弃用XML和JSON。在此,你只需要知道这一过程会占据大量内存即可。

如果在经过几次重复的优化后应用程序的内存用量情况有所改善,那么久可以启动GC优化了。

笔者总结了GC优化的两个目的:

  1. 将进入老年代的对象数量降到最低
  2. 减少Full GC的执行时间

2. 标记-清除-压缩

这种垃圾收集算法主要是对上面的算法进行了优化,内存回收了对内存进行了一次优化压缩。这样回收后内存块的连续性又比较强了。

但是这种算法会涉及到不停的内存间的拷贝和复制,性能会非常差。

图片 2

1.监控GC状态

你需要监控GC从而检查系统中运行的GC的各种状态,具体方法请查看系列的第二篇文章《如何监控Java
GC》

将进入老年代的对象数量降到最低

除了可以在JDK 7及更高版本中使用的G1收集器以外,其他分代GC都是由Oracle
JVM提供的。关于分代GC,就是对象在Eden区被创建,随后被转移到Survivor区,在此之后剩余的对象会被转入老年代。也有一些对象由于占用内存过大,在Eden区被创建后会直接被传入老年代。老年代GC相对来说会比新生代GC更耗时,因此,减少进入老年代的对象数量可以显著降低Full
GC的频率。你可能会以为减少进入老年代的对象数量意味着把它们留在新生代,事实正好相反,新生代内存的大小是可以调节的。

3.标记-清除-复制

这种算法会将内存空间分配成两块相同的区域A和B。当内存回收的时候,将A中的内存块拷贝到B中,然后一次性清空A。

但是这种算法会对内存要求比较大一些,并且长期复制拷贝性能上也会受影响。

图片 3

2.分析监控结果后决定是否需要优化GC

在检查GC状态后,你需要分析监控结构并决定是否需要进行GC优化。如果分析结果显示运行GC的时间只有0.1-0.3秒,那么就不需要把时间浪费在GC优化上,但如果运行GC的时间达到1-3秒,甚至大于10秒,那么GC优化将是很有必要的。

但是,如果你已经分配了大约10GB内存给Java,并且这些内存无法省下,那么就无法进行GC优化了。在进行GC优化之前,你需要考虑为什么你需要分配这么大的内存空间,如果你分配了1GB或2GB大小的内存并且出现了OutOfMemoryError,那你就应该执行堆转储(heap
dump)
来消除导致异常的原因。

注意:

堆转储(heap
dump)
是一个用来检查Java内存中的对象和数据的内存文件。该文件可以通过执行JDK中的jmap命令来创建。在创建文件的过程中,所有Java程序都将暂停,因此,不要再系统执行过程中创建该文件。

你可以在互联网上搜索heap
dump的详细说明。对于韩国读者,可以直接参考我去年发布的书:《The story
of troubleshooting for Java developers and system operators》 (Sangmin
Lee, Hanbit Media, 2011, 416 pages)

降低Full GC的时间

Full GC的执行时间比Minor GC要长很多,因此,如果在Full
GC上花费过多的时间(超过1s),将可能出现超时错误。

  • 如果通过减小老年代内存来减少Full
    GC时间
    ,可能会引起OutOfMemoryError或者导致Full GC的频率升高。
  • 另外,如果通过增加老年代内存来降低Full GC的频率,Full
    GC的时间可能因此增加。

因此,你需要把老年代的大小设置成一个“合适”的值

Java分代收集算法

Java主要采用了分代收集算法。分代收集算法主要将对象存活期的长短将内存进行划分。

Java主要将内存划分为两部分:新生代老生代

Java的新生代中,对象的存活率低,存活期期会相对会比较短一些,所以可以选用复制算法来进行内存回收。

Java的老生代中,对象的存活率比较高,并且相对存活期比较长一些,可以采用标记-清除-压缩的算法来进行内存回收。

可以看图:

图片 4

通常新生代分为Eden和两个Survivor,其中可以通过-XX:SurvivorRatio=1来设置(这里要考虑两个Survivor,意味着二个S的大小是整个新生代的2/3)

前面已经说了,Java的内存分配和内存回收主要在Java的堆上进行的。而Java的方法区间和常量池我们一般称为永久代。永久代可以通过-XX:PermSize=512M
-XX:MaxPermSize=512M
设置

Java堆内存设置参数:-Xmx20m
-Xms20m

Java堆新生代内存分配设置:-Xmn10m
新生代分配了10M的内存,那么剩下的10M就是老生代上面分配了。也可以设置:-XX:NewRatio=4

通过设置参数,我们就可以在控制台中看到Java虚拟机在执行GC时候的日志:-XX:+PrintGCDetails  

也可以指定日志的位置:-Xloggc:gc.log  

永久代一般是指方法区和常量池,一般情况下永久代在虚拟机运行时就能确定大小的,但是一些框架可能动态生成一些类信息就会导致永久代越来越大。