Java虚拟机-3----垃圾收集器及GC参数

本文主要内容:

-》堆的回顾

-》各种垃圾收集器的介绍

1.  串行收集器
2.  并行收集器
3.  CMS收集器
4.  G1收集器

堆的回顾:

新生代中的98%对象都是“朝生夕死”的,所以并不需要按照1:1的比例来划分内存空间,而是将内存分为一块比较大的Eden空间和两块较小的Survivor空间,每次使用Eden和其中一块Survivor。当回收时,将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上,最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1,也就是说,每次新生代中可用内存空间为整个新生代容量的90%(80%+10%),只有10%的空间会被浪费。

当然,98%的对象可回收只是一般场景下的数据,我们没有办法保证每次回收都只有不多于10%的对象存活,当Survivor空间不够用时,需要依赖于老年代进行分配担保,所以大对象直接进入老年代。

堆的结构如下图所示:

垃圾收集器:

如果说收集算法是内存回收的方法论,那么垃圾收集器就是内存回收的具体实现。

虽然我们在对各种收集器进行比较,但并非为了挑出一个最好的收集器。因为直到现在位置还没有最好的收集器出现,更加没有万能的收集器,所以我们选择的只是对具体应用最合适的收集器

 上图为各种垃圾收集器,我们一一介绍

名词概念解释:

垃圾收集器里,

并行:多个GC线程同时运行

并发:GC线程和用户线程同时运行

一、串行收集器:Serial收集器 + SerialOld收集器

  • 最古老,最稳定
  • 简单而高效(暂停了用户线程)
  • 可能会产生较长的停顿
  • -XX:+UseSerialGC

    新生代、老年代都会使用串行回收

      新生代复制算法

    老年代标记-整理

这个收集器是一个单线程的收集器,但它的单线程的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作,更重要的是在它进行垃圾收集时,必须暂停其他所有的工作线程,直到它收集结束。收集器的运行过程如下图所

二、并行收集器:

1、ParNew收集器(新生代):

  • ParNew收集器其实就是Serial收集器新生代的并行版本(唯一区别支持多线程收集)
  • 多线程,需要多核支持。
  • -XX:+UseParNewGC

新生代并行

老年代串行

  • -XX:ParallelGCThreads 限制线程数量

 

2、Parallel Scanvenge收集器(新生代):

  • 类似ParNew,但更加关注吞吐量
  • -XX:+UseParallelGC  使用Parallel Scanvenge收集器:新生代并行,老年代串行

3、Parallel Old收集器(老年代):

  • Parallel Old收集器是Parallel Scanvenge收集器的老年代版本
  • -XX:+UseParallelGC  使用Parallel Old收集器:新生代并行,老年代并行

各种参数设置:

  • -XX:MaxGCPauseMills

    最大停顿时间,单位毫秒

    GC尽力保证回收时间不超过设定值

  • -XX:GCTimeRatio

    0-100的取值范围

    垃圾收集时间占总时间的比

    默认99,即最大允许1%时间做GC

注:这两个参数是矛盾的。因为停顿时间和吞吐量不可能同时调优。我们一方买希望停顿时间少,另外一方面希望吞吐量高,其实这是矛盾的。因为:在GC的时候,垃圾回收的工作总量是不变的,如果将停顿时间减少,那频率就会提高;既然频率提高了,说明就会频繁的进行GC,那吞吐量就会减少,性能就会降低。

吞吐量:CPU用于用户代码的时间/CPU总消耗时间的比值,即=运行用户代码的时间/(运行用户代码时间+垃圾收集时间)。比如,虚拟机总共运行了100分钟,其中垃圾收集花掉1分钟,那吞吐量就是99%。

三、CMS收集器:

CMS收集器(Concurrent Mark Sweep:并发标记清除)是一种以获取最短回收停顿时间为目标的收集器。适合应用在互联网站或者B/S系统的服务器上,这类应用尤其重视服务器的响应速度,希望系统停顿时间最短。更关注用户体验的,推荐用这种收集器。

  • Concurrent Mark Sweep 并发标记清除,并发低停顿
  • 标记-清除算法
  • 并发阶段会降低吞吐量(因为停顿时间减少了,于是GC的频率会变高)
  • 老年代收集器(新生代使用ParNew)
  • -XX:+UseConcMarkSweepGC   打开这收集器

注:这里的并发指的是与用户线程一起执行。

2、CMS收集器运行过程:(着重实现了标记的过程)

(1)初始标记

根可以直接关联到的对象

速度快

(2)并发标记(和用户线程一起)

主要标记过程,标记全部对象

(3)重新标记

由于并发标记时,用户线程依然运行,因此在正式清理前,再做修正

(4)并发清除(和用户线程一起)

基于标记结果,直接清理对象

整个过程如下图所示:

 其中,初始标记和重新标记时,需要stop the world。

整个过程中耗时最长的是并发标记和并发清除,这两个过程都可以和用户线程一起工作。

3、CMS收集器特点:

(1)尽可能降低停顿

(2)会影响系统整体吞吐量和性能

比如,在用户线程运行过程中,分一半CPU去做GC,系统性能在GC阶段,反应速度就下降一半

(3)清理不彻底

因为在清理阶段,用户线程还在运行,会产生新的垃圾,无法清理

(4)因为和用户线程一起运行,不能在空间快满时再清理

-XX:CMSInitiatingOccupancyFraction设置触发GC的阈值

如果不幸内存预留空间不够,就会引起concurrent mode failure

我们来看一下concurrent mode failure的日志:

ae662550-f927-4299-a64b-2b1fba3e4c81

碰到上图中的情况,我们需要使用串行收集器作为后备。

4、既然标记清除算法会造成内存空间的碎片化,CMS收集器为什么使用标记清除算法而不是使用标记整理算法:

答案:

    CMS收集器更加关注停顿,它在做GC的时候是和用户线程一起工作的(并发执行),如果使用标记整理算法的话,那么在清理的时候就会去移动可用对象的内存空间,那么应用程序的线程就很有可能找不到应用对象在哪里。

为了解决碎片的问题,CMS收集器会有一些整理上的参数,接下来就来讲这个。

5、整理时的各种参数:

  • -XX:+ UseCMSCompactAtFullCollection     

Full GC后,进行一次整理。整理过程是独占的,会引起停顿时间变长

  • -XX:+CMSFullGCsBeforeCompaction

设置进行几次Full GC后,进行一次碎片整理

  • -XX:ParallelCMSThreads

设定CMS的线程数量

四 G1收集器

用来替代CMS

这种GC 不再很明显的把堆内存划分为 新生代和老年代两大块内存了,而是把内存分成很多小块

 此处的1块内存,是可以放很多对象的内存,

GC后,剩余内存是比较干净的,(多于出来的O,是新生代晋升过来的)

并行与并发:G1能充分利用多CPU、多核环境下的硬件优势,使用多个CPU(CPU或者CPU核心)来缩短Stop-The-World停顿的时间,部分其他收集器原本需要停顿Java线程执行的GC动作,G1收集器仍然可以通过并发的方式让Java程序继续执行。

分代收集:与其他收集器一样,分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆,但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。

空间整合:与CMS的“标记—清理”算法不同,G1从整体来看是基于“标记—整理”算法实现的收集器,从局部(两个Region之间)上来看是基于“复制”算法实现的,但无论如何,这两种算法都意味着G1运作期间不会产生内存空间碎片,收集后能提供规整的可用内存。这种特性有利于程序长时间运行,分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。

内存布局:在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代,而G1不再是这样。使用G1收集器时,Java堆的内存布局就与其他收集器有很大差别,它将整个Java堆划分为多个大小相等的独立区域(Region),虽然还保留有新生代和老年代的概念,但新生代和老年代不再是物理隔离的了,它们都是一部分Region(不需要连续)的集合。

新生代GC

     回收Eden区和survivor区,回收后,所有eden区被清空,存在一个survivor区保存了部分数据。老年代区域会增多,因为部分新生代的对象会晋升到老年代。

初始标记:短暂,仅仅只是标记一下GC Roots能直接关联到的对象,速度很快,产生一个全局停顿,都伴随有一次新生代的GC。

根区域扫描:扫描survivor区可以直接到达的老年代区域。

并发标记阶段:扫描和查找整个堆的存活对象,并标记。

重新标记:会产生全局停顿,对并发标记阶段的结果进行修正。

独占清理:会产生全局停顿,对GC回收比例进行排序,供混合收集阶段使用

并发清理:识别并清理完全空闲的区域,并发进行

混合收集

对含有垃圾比例较高的Region进行回收。

G1当出现内存不足的的情况,也可能进行的FullGC回收(暂停所有工作线程,全局回收 包括新生代,老年代,永久代)

G1中重要的参数:

-XX:MaxGCPauseMillis 指定目标的最大停顿时间,G1尝试调整新生代和老年代的比例,堆大小,晋升年龄来达到这个目标时间。

-XX:ParallerGCThreads:设置GC的工作线程数量

五 GC参数的整理:

-XX:+UseSerialGC:在新生代和老年代使用串行收集器

-XX:SurvivorRatio:设置eden区大小和survivior区大小的比例

-XX:NewRatio:新生代和老年代的比

-XX:+UseParNewGC:在新生代使用并行收集器

-XX:+UseParallelGC :新生代使用并行回收收集器

-XX:+UseParallelOldGC:老年代使用并行回收收集器

-XX:ParallelGCThreads:设置用于垃圾回收的线程数

-XX:+UseConcMarkSweepGC:新生代使用并行收集器,老年代使用CMS+串行收集器

-XX:ParallelCMSThreads:设定CMS的线程数量

-XX:CMSInitiatingOccupancyFraction:设置CMS收集器在老年代空间被使用多少后触发

-XX:+UseCMSCompactAtFullCollection:设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片的整理

-XX:CMSFullGCsBeforeCompaction:设定进行多少次CMS垃圾回收后,进行一次内存压缩

-XX:+CMSClassUnloadingEnabled:允许对类元数据进行回收

-XX:CMSInitiatingPermOccupancyFraction:当永久区占用率达到这一百分比时,启动CMS回收

-XX:UseCMSInitiatingOccupancyOnly:表示只在到达阀值的时候,才进行CMS回收

六 内存分配与回收策略

1  对象优先在Eden分配,如果说Eden内存空间不足,就会发生Minor GC

2  大对象直接进入老年代,大对象:需要大量连续内存空间的Java对象,比如很长的字符串和大型数组,

    1、导致内存有空间,还是需要提前进行垃圾回收获取连续空间来放他们,

    2、会进行大量的内存复制。

-XX:PretenureSizeThreshold 参数 ,大于这个数量直接在老年代分配,缺省为0 ,表示绝不会直接分配在老年代。

3 长期存活的对象将进入老年代,默认15岁,-XX:MaxTenuringThreshold调整

    虚拟机给每个对象定义了年龄,在对象头里,每活过1次GC,年龄+1 

4  动态对象年龄判定,为了能更好地适应不同程序的内存状况,虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代,如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代,无须等到MaxTenuringThreshold中要求的年龄

5  空间分配担保:新生代中有大量的对象存活,survivor空间不够,当出现大量对象在MinorGC后仍然存活的情况(最极端的情况就是内存回收后新生代中所有对象都存活),就需要老年代进行分配担保,把Survivor无法容纳的对象直接进入老年代.只要老年代的连续空间大于新生代对象的总大小或者历次晋升的平均大小,就进行Minor GC,否则FullGC。

七   Minor GC、Major GC和Full GC之间的区别

      JVM在进行GC时,并非每次对三个内存(新生代、老年代、方法区)区域一起回收,大部分时候回收的都是新生代。

针对Hotspot VM 的实现,它里面的GC按照回收区域分为两种大类:一种是部分收集(Partial GC),另一种是整堆收集(Full GC)

部分收集(Partial GC):只针对部分区域进行垃圾收集。其中又分为:

   1  新生代收集(Minor GC/Young GC):只针对新生代的垃圾收集。具体点的是Eden区满时触发Minor GCSurvivor满不会触发Minor GC

   2  老年代收集(Major GC/Old GC):只针对 老年代的垃圾收集。 目前,只有CMS收集器会有单独收集老年代的行为(Major GC)。 注意,很多时候,Major              GC 会和Full GC混淆使用,需要具体分辨是老年代的回收还是整堆回收。

  3  混合收集(Mixed GC):指目标是收集整个新生代以及部分老年代的垃圾收集。 目前只有G1收集器会有这种行为。

整堆收集(Full GC):收集整个Java堆和方法区的垃圾收集。

7.1  Minor GC

    当年轻代(Eden区)满时就会触发 Minor GC,这里的年轻代满指的是 Eden区满。Survivor 满不会触发 Minor GC 。

从年轻代空间(主要是 Eden区)回收内存被称为 Minor GC。

     Minor GC是发生在新生代中的垃圾收集动作,采用的是复制算法。

对象在Eden和From区出生后,在经过一次Minor GC后,如果对象还存活,并且能够被to区所容纳,那么在使用复制算法时这些存活对象就会被复制到to区域,然后清理掉Eden区和from区,并将这些对象的年龄设置为1,以后对象在Survivor区每熬过一次Minor GC,就将对象的年龄+1,当对象的年龄达到某个值时(默认是15岁,可以通过参数 --XX:MaxTenuringThreshold设置),这些对象就会成为老年代。

但这也是不一定的,对于一些较大的对象(即需要分配一块较大的连续内存空间  如大数组)则是直接进入老年代

Minor GC 会stop the world 

发生Minor GC事件需要注意:

  1. 当 JVM 无法为一个新的对象分配空间时会触发 Minor GC,比如当 Eden 区满了。所以分配率越高,越频繁执行 Minor GC。

  2. 内存池被填满的时候,其中的内容全部会被复制,指针会从0开始跟踪空闲内存。Eden 和 Survivor 区进行了标记和复制操作,取代了经典的标记、扫描、压缩、清理操作。所以 Eden 和 Survivor 区不存在内存碎片。写指针总是停留在所使用内存池的顶部。

  3. 执行 Minor GC 操作时,不会影响到永久代。从永久代到年轻代的引用被当成 GC roots,从年轻代到永久代的引用在标记阶段被直接忽略掉。

  4. 对于大部分应用程序,Minor GC 操作时应用程序停顿导致的延迟都是可以忽略不计的。因为,大部分 Eden 区中的对象都能被认为是垃圾,永远也不会被复制到 Survivor 区或者老年代空间。如果正好相反,Eden 区大部分新生对象不符合 GC 条件,Minor GC 执行时暂停的时间将会长很多。

7.2、Major GC

CMS收集器中,当老年代满时会触发 Major GC。

目前,只有CMS收集器会有单独收集老年代的行为。其他收集器均无此行为。

针对新生代(主要指Eden区)的Minor GC 比较常见,各个收集器均支持。

7.3、Full GC(标记清除算法)

Full GC 对收集整堆(新生代、老年代)和方法区的垃圾进行收集。

当年老代满时引发Full GC,Full GC将会同时回收新生代、年老代 ;
永久代(方法区)满时也会引发Full GC,会导致Class、Method元信息的卸载 。

(1)调用System.gc时,系统建议执行Full GC,但是不一定会执行 。
(2)老年代空间不足
(3)永久代(方法区)空间不足
(4)通过 Minor GC 后进入老年代的空间大于老年代的可用内存
(5)由Eden区、survivor space1(From Space)区向survivor space2(To Space)区复制时,对象大小大于To Space可用内存,则把该对象转存到老年代,且老年代的可用内存小于该对象大小 。

方法区也会进行内存回收?

      很多人认为方法区(或者HotSpot虚拟机中的永久代)是没有垃圾收集的,Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集,而且在方法区进行垃圾收集的“性价比”一般比较低:在堆中,尤其是在新生代中,常规应用进行一次垃圾收集一般可以回收70%~95%的空间,而永久代的垃圾收集效率远低于此。

       永久代的垃圾收集主要回收两部分内容:废弃常量无用的类。回收废弃常量与回收Java堆中的对象非常类似。

可以回收的字面量:

      以常量池中字面量的回收为例,假如一个字符串“abc”已经进入了常量池中,但是当前系统没有任何一个String对象是叫做“abc”的,换句话说是没有任何String对象引用常量池中的“abc”常量,也没有其他地方引用了这个字面量,如果在这时候发生内存回收,而且必要的话,这个“abc”常量就会被系统“请”出常量池。常量池中的其他类(接口)、方法、字段的符号引用也与此类似。

判定一个常量是否是“废弃常量”比较简单。而要判定一个类是否是“无用的类”的条件则相对苛刻许多。类需要同时满足下面3个条件才能算是“无用的类”:

1  该类所有的实例都已经被回收,也就是Java堆中不存在该类的任何实例。

2   加载该类的ClassLoader已经被回收。

3   该类对应的java.lang.Class 对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法。

在大量使用反射、动态代理、CGLib等bytecode框架的场景,以及动态生成JSP和OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能,以保证永久代不会溢出。

7.4   总结

  • Minor GC 是 清理 新生代中的Eden区,Survivor区满时不会触发 ;
  • Major GC 是 清理 老年代 ;
  • Full GC 是 清理整个堆和方法区,包括 年轻代、老年代和方法区。

欢迎转载,但请保留文章原始出处→_→ 

生命壹号:http://www.cnblogs.com/smyhvae/

文章来源:http://www.cnblogs.com/smyhvae/p/4748313.html

原文地址:https://www.cnblogs.com/hup666/p/13096421.html