《深入理解Java虚拟机:JVM高级特性与最佳实践》 第三章 垃圾收集器与内存分配策略 读书笔记

第三章 垃圾收集器与内存分配策略

一、对象已死吗

1.引用计数算法

  • 定义:每当有一个地方引用它时,计数器+1,;引用失效时,计数器-1。
  • 缺点:虽然说大部分情况下它是个不错的算法,但是有个致命的缺点:无法解决循环引用的问题。HotSpot并未采用引用计数算法。

2.可达性分析算法

  • 定义:通过一系列的成为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径成为引用链,当一个对象到GC Roots没有任何引用链时,证明此对象为不可用。
  • 在Java语言中,可作为GC Roots的对象有

    • ①虚拟机栈(栈帧中的本地变量表)中引用的对象
    • ②方法区中类静态属性引用的对象
    • ③方法区中常量引用的对象
    • ④本地方法栈中JNI(一般说Native方法)引用的对象

3.谈谈引用

  • 两种算法判断对象是否存活都与“引用”有关,在JDK1.2之前,如果reference类型的数据中存储的数值代表是另外一块内存的起始地址,就称这块内存代表着一个引用,不过太过狭隘。其实还需要描述这样的对象:空间足够,保留内存中;GC后还是非常紧张,则清除此类对象;例如:缓存。
  • JDK1.2之后,Java对引用进行了扩充

    • ①强引用:Object object = new Object(); 只要这类引用存在,垃圾回收器永远不会回收掉被引用的对象。
    • ②软引用:发生OOM之前,把这些对象纳入回收范围进行二次回收。SoftReference实现软引用。
    • ③弱引用:被弱引用关联的对象只能生存到下一次垃圾收集发生之前。GC开始时,无论内存是否足够,都会回收掉只被弱引用关联的对象。WeakReference实现弱引用。
    • ④虚引用:完全不会应该一个对象的生存时间,也无法通过虚引用来获得对象的实例。唯一目的:在这个对象被收集器回收时收到一个系统通知。PhantomReference实现虚引用。

4.finalize()与对象的生存死亡

finalize()方法作用?为什么要有这个方法?

  • 为什么:要真正宣告一个对象死亡,至少要经历两次标记过程,对象在进行可达性分析之后发现没有与GC Roots相连接的引用链,进行第一次标记并进行筛选(条件是:[1].这个对象有没有覆盖finalize()方法[2].finalize()方法已经被虚拟机执行过;这两个都被虚拟机视为“没有必要执行”finalize()方法)。
  • 作用:如果要执行finalize()方法,这个对象会被放在F-Queue队列中(稍后由虚拟机建立的、低优先级的Finalizer线程执行它,所谓“执行”就是指虚拟机会触发这个方法,并不承诺等待它执行结束)。
  • finalize()方法是对象逃脱死亡命运的最后一次机会,稍后GC将对F-Queue中的对象进行第二次小规模标记,如果要“拯救自己”,只要重新与引用链的任何一个对象建立关联即可。
  • 不要覆盖finalize()方法,他能做的try,catch都能做的更好。

5.回收方法区

  • 虚拟机规范中提到:可以不要求虚拟机在方法区实现垃圾收集。
  • 永久代收集主要回收两部分内容:

    • ①废弃常量:如现在有一个字符串“abc”放入常量池中,没有任何String对象应用常量池中的“abc”常量,也没有其他任何地方引用这个字面量。
    • ②无用的类:该类所有的实例都已经被回收,Java堆中不存在该类的任何实例;加载该类的ClassLoader已经被回收;该类对应的java.lang.Class对象没有在任何地方被引用,无法在任何地方用过反射访问该方法。

二、垃圾收集算法

1.标记-清除算法

  • 定义:分为“标记”和“清除”两个阶段;首先标记处所有需要回收的对象,在标记完成后统一回收所有被标记对象。
  • 缺点:①效率问题,这两个过程效率都不高;②空间问题:标记清除之后会产生大量不连续的内存碎片,碎片太多可能会导致以后在程序运行过程中需要分配较大的对象时,无法找到足够的连续内存而不得不提前出发另一次垃圾收集动作。

2.复制算法

  • 定义:将可用内存容量划分为大小相等的两块,每次只使用其中的一块。这一块内存用完了,就将还存活着的对象复制到另外一块上面,然后再把已使用过的内存空间一次清理掉。
  • 好处:内存分配时也就不用考虑内存碎片等复杂情况。
  • 代价:将内存缩小为原来的一般,未免太高了。
  • 实际中的商业虚拟机:研究表明,新生代中的对象有98%都是“朝生夕死的”,所以不需要1:1分配,将内存分为一块较大的Eden和两块较小的Survivor空间,每次使用Eden和其中一块Survivor。在回收时,将Eden和Survivor中还存活的对象一次性地复制到另外一块Survivor空间上,然后清理这两块内存。
    Eden:Survivor:Survivor = 8:1:1
    当另外一块Survivor空间不够用时,这些对象将通过分配担保机制进入老年代。

3.标记-整理算法

  • 复制收集算法在对象生存率较高时就需要进行较多的复制操作,效率将会变低。老年代一般不能直接选用这个算法。
  • 前面的标记清除过程的标记过程一样(不做清除),后续的过程让所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存。

三、HotSpot算法实现

1.枚举根节点(对时间敏感)

  • ①从可达性分析中从GC Roots节点找引用链这个操作为例,可作为GC Roots的节点主要在全局性的引用(如:常量类或静态属性)与执行上下文(如:栈帧中的本地变量表)中,现在很多应用的方法区就有数百兆,如果要逐个检查这里面的引用,那么必然会消耗很多的时间。
  • ②GC停顿。这项分析工作必须在一个能确保一致性的快照中进行,这里“一致性”表示在整个分析期间整个执行系统看起来就像被冻结在某个时间节点上,不可出现分析过程中对象引用关系还在不断变化的情况,否则分析结果准确性无法保证。(Sun将会这个事件成为“Stop The World”,简称STW)。
  • ③由于现在主流的Java虚拟机使用的都是准确是GC,所以当执行系统停顿下来后,不需要一个不漏地检查完所有执行上下文和全局的引用位置,虚拟机应当是有办法知道哪些地方存放着对象的引用。HotSpot是用一组成为OopMap的数据结构来达到这个目的的,在类加载完的时候,HotSpot就把对象内什么偏移量上是什么类型的数据计算出来,在JIT编译过程中,也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样,GC在扫描的时候就可以直接得到这些信息了。

2.安全点

  • 在OopMap的协助下,HotSpot可以快速准确的完成GC Roots枚举,一个值得关注的问题是,都在什么时候生成这个OopMap。
  • 生成OopMap的这些特定的位置成为安全点。选用标准:是否具有让程序长时间执行的特征。如:方法调用、循环跳转、异常跳转等。
  • 如何让程序执行到安全点停顿?

    • ①抢先式中断:GC发生时,首先把所有线程中断,如果发现线程中断的地方不在安全上,就恢复线程,让它”跑“到安全点上。几乎没有虚拟机采用这个方法。
    • ②主动式中断:设置一个标志(与安全点重合),各个线程执行时主动去轮循这个标志,发现中断标志为真时就自己中断挂起。

3.安全区域

  • 作用:若线程处于Sleep状态或者Block状态,此时线程无法响应JVM的中断请求,去安全的地方中断挂起,JVM也不可能等待线程重新被分配CPU时间。此时,就需要安全区域来解决。
  • 定义:在一段代码片段中,引用关系不会发生变化。在这个区域中的任意地方开始GC都是安全的,可以把安全区域看成是扩展了的安全点。
  • 离开:检查系统是否已经完成了根节点枚举(或者是整个GC),完成了,线程继续执行,否则必须等待知道收到可以安全离开安全区域的信号为止。

四、垃圾收集器

《《深入理解Java虚拟机:JVM高级特性与最佳实践》 第三章 垃圾收集器与内存分配策略 读书笔记》

如果两个收集器之间存在连线,那么他们就可以连线使用。

1.Serial

  • 作用:新生代收集器唯一选择(JDK1.3.1之前),使用复制算法。
  • 特点:在进行垃圾收集时,必须暂停其他所有线程,直到它收集结束。
  • 使用场景:直到现在,它依然是虚拟机运行在Client模式下的默认的新生代收集器。对于限定单个CPU的环境来说,Serial没有线程交互的开销,专心做垃圾收集自然可以获得最高的但线程收集效率。例如:GUI。

2.ParNew

  • 作用:Serial收集器的多线程版本,其余行为包括Serial的所有控制参数、收集算法、STW、对象分配原则、回收策略等都与Serial一样。
  • 使用场景:它是许多运行在Server模式下虚拟机首选的的新生代收集器,有一个与性能无关但是很重要的原因是,除了Serial之外,目前只有它能与CMS收集器配合工作。
  • 此收集器是使用-XX:UseConcMarkSweepGC(CMS)的默认新生代收集器,也可使用-XX:UseParNewGC来强制指定。
  • 缺点:在单CPU环境下,不会比Serial更好。
    优点:随着CPU数量的增加,对系统资源的有效利用还是很有好处的。
    可使用-XX:ParallelGCThreads限制垃圾收集的线程数。

3.Parallel Scavenge

  • 作用:新生代收集器,使用复制算法。常被称为“吞吐量优先”的收集器。
  • 特点:CMS等收集器的关注点是尽可能缩短在垃圾收集时用户线程的停顿时间,而Parallel Scavenge的目标则是达到一个可控制的吞吐量。(吞吐量=运行用户代码时间/[运行用户代码时间+垃圾收集时间])。

停顿时间短适合需要与用户交互的程序,高吞吐量则可以高效率的利用CPU时间,主要用于运算。

  • 虚拟机参数

    • ①控制最大垃圾收集停顿时间的-XX:+MaxGCPauseMillis:值为一个大于0的毫秒数,收集器尽可能保证内存回收花费时间不超过设定值。
      但是过短的内存回收花费时间是牺牲吞吐量和新生代空间来保证的。(例:收集300M肯定比收集500M快)。
    • ②设置吞吐量大小的-XX:+GCTimeRatio:值为大于0且小于100的整数,也就是垃圾收集时间占总时间的比率,相当于吞吐量的倒数(默认值为99,1/[1+99],允许最大1%的垃圾收集时间)。
    • ③一个开关参数-XX:+UseAdaptiveSizePoilcy:打开后,不需要手工指定新生代(-Xmn)大小,Eden与survivor比例(-XX:SurvivorRatio),晋升老年代对象大小(-XX:PretenureSizeThreshold)等细节参数了,虚拟机会根据当前系统的运行情况收集性能监控,动态调整以提供最合适的停顿时间或最大吞吐量,称为GC的自适应调节策略。只需要设置上面两个之一(虚拟机关注的优化目标)和基本内存数据设置好(如-Xmx设置最大堆)。
      注:自适应调节策略也是Parallel Scavenge与ParNew收集器的一个重要区别。

4.Serial Old

  • 作用:Serial的老年代版本,单线程收集器,使用标记-整理算法。
  • 使用场景:①JDK1.5之前与Parallel Scavenge配合使用②CMS收集器的后备预案,在Concurrent Mode Failure时使用。

5.Parallel Old

  • 作用:Parallel Scavenge的老年代版本,使用多线程和标记-整理算法,JDK1.6开始提供。
  • 出现的历史条件:在JDK1.6之前,如果新生代使用Parallel Scavenge收集器,老年代除了Serial Old没有别的选择。

6.CMS(Concurrent Mark Sweep)

  • 作用:老年代(JDK1.5发布)。基于标记-清除算法。
  • 运作过程

    • 初始标记:仅仅标记一下GC Roots能直接关联到的对象,速度很快。
    • 并发标记:进行GC Tracing的过程。
    • 重新标记:修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。在时间上比初始标记长,远比并发标记短。
    • 并发清除
      注:初始标记与重新标记仍然需要STW。
      整个过程中耗时最长的并发标记与并发清除过程收集器线程都可以与用户线程一起工作。总体上来说,CMS内存回收过程和用户线程一起并发执行。
    • 缺点

      • 1.对CPU资源非常敏感。
        CMS默认启动回收线程数量为 (CPU数量+3)/4 ,也就是CPU在4个以上时,并发回收线程不少于25%,并且随着CPU数量增加而下降;但是CPU不足两个时,对用户程序影响就很大。
        为此还提出了“增量式并发收集器”(Increamental Concurrent Mark Sweep/i-CMS),就是在并发标记清理时,让GC线程、用户线程交替运行,结果是垃圾收集时间更长,但是结果很一般,现已经标记为“deprecated”。
      • 2.无法处理浮动垃圾。
        由于CMS在并发清理阶段用户线程还在进行着,新的垃圾不断产生,这一部分垃圾在标记过程之后,CMS无法在当次收集中处理它们,只能下一次GC清理。成为“浮动垃圾”。
        正是由于垃圾收集阶段用户线程还在不断运行,所以必须预留必要的内从空间给用户线程使用,所以CMS不能像其他垃圾收集器一样等老年代几乎被占满了之后再进行垃圾收集。
        JDK1.5默认设置老年代使用了68%(相当保守的设置)就会被激活,如果老年代增长不是很快,可以使用-XX:CMSInitiatingOccupancyFraction的值来提高百分比,通过降低内存回收次数来获取更好的性能。
        JDK1.6中阈值提升至92%。
        如果运行期间预留内存无法满足需要,出现一次“Concurrent Mode Failure”,启动后备预案,使用Serial Old来进行垃圾收集,这样停顿时间就会很长,这个参数设置太高可能会导致大量上述现象,性能反而降低。
      • 3.因为基于标记-清除算法实现,收集结束时会有大量空间碎片。
        CMS提供-XX:+UseCMSCompactAtFullCollection开关参数(默认开启),在CMS进行FullGC时开启内存碎片的合并整理过程。碎片整理无法并发,空间碎片问题解决,但是停顿时间变长。
        -XX:CMSFullGCsBeforeCompaction设置执行多少次不压缩的Full GC后,跟着一次碎片整理(默认为0)。

7.G1(Garbage-First)

  • 作用:JDK1.7u4正式发布(去掉experimental)。可不与其他垃圾收集器配合,独立使用。
  • 特点:

    • ①并行与并发:G1能充分利用多CPU,多核环境下的硬件优势,缩短STW。原本需要停顿Java线程执行其他的GC动作,G1收集器仍然可以通过并发的方式让Java线程继续执行。
    • ②分代收集:保留分代概念,能独立管理GC堆,采用不同的方式应对新创建的对象和已经存活了一段时间、熬过多次GC的对象。
    • ③空间整合:整体基于标记-整理算法,局部(从两个Region之间)基于复制算法实现。这两种算法不会产生空间碎片,有利于程序长久运行。
    • ④可预测的停顿:降低停顿时间是CMS与G1的共同关注点,G1除了追求低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为M毫秒的时间片段内。
      之所以能建立可预测的停顿时间模型,是因为G1跟踪各个Region里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需要时间的经验值),维护一个优先列表,优先回收价值最大的Region。这种使用Region划分内存空间以及有优先级的区域回收方式,保证了G1在有限的时间内获取更高的垃圾收集效率。
  • Region的概念

    • 定义:G1将整个Java堆分为多个大小相等的独立区域,虽然保留新生代和老年代的概念,但新生代和老年代已经不是物理隔离的了,它们都是一部分Region(不需要连续)的集合。
    • 如何避免全堆扫描:G1使用Remembered Set避免全堆扫描。G1之中每个Region都有一个与之对应的Remembered Set,虚拟机发现程序在对Reference类型的数据进行写操作时,会产生一个Write Barrier暂时中断写操作,检查Reference引用的对象是否处于不同的Region之中(在分代的例子中就是检查是否老年代的对象引用了新生代的对象),若是,便通过CardTable把相关的引用信息记录到被引用对象所属的Region的Remembered Set之中。在进行内存回收时,在GC根节点的枚举范围中加入Remembered Set即可保证不扫描全堆也不会有遗漏。
    • 运作过程:
      ①初始标记:标记GC Roots能直接关联到的对象,并修改TANS(Next Top at Mark Start)的值,让下一阶段用户并发运行时,能在正确可用的Region中创建新对象。此阶段需要停顿线程,但时间很短。
      ②并发标记:从GC Roots开始对堆中对象进行可达性分析,找出存活对象。耗时较长,可与用户线程并发执行。
      ③最终标记:修正并发标记阶段由于用户程序执行而导致标记发生修改的那一部分标记记录,虚拟机将这段时间的变化全部记录在Remembered Set Logs中,最终标记阶段需要把Remembered Set Logs中的数据合并到Remembered Set中。这阶段需要停顿线程,但是可并行执行。
      ④筛选回收:首先对回收价值和成本进行排序,根据用户所期望的GC停顿时间来制定回收计划。可并发执行。

五、内存分配与回收策略

1.对象优先在Eden分配

新生代参数 -Xmn
新生代总可用空间为Eden+一个Survivor。

2.大对象直接进入老年代

-XX:PretenureSizeThreshold 大于这个设置值的对象直接在老年代分配。
目的:避免在Eden和两个Survivor区域发生大量的内存复制。

注:这个参数只对Serial和ParNew两款收集器有效。

3.长期存活的对象将进入老年代

“熬过”一次Minor GC,年龄增加一岁,对象年龄到一定的阈值,会晋升到老年代中。
通过-XX:MaxTenuringThreshold设置。

4.动态对象年龄判定

虚拟机不是永远要求对象年龄必须达到那个阈值才能晋升老年代,如果在Survivor空间中相同年龄所有对象大小的综合大于Survivor的一半,年龄大于或等于该年龄的对象就可以直接进入老年代,无需等到MaxTenuringThreshold中要求的年龄。

5.空间分配担保(主要针对JDK1.6u24之前版本)

发生Minor GC之前,虚拟机会:

  • ①检查老年代最大可用的连续空间是否大于新生代所有对象总空间。
  • ②查看HandlePromotionFailure设置值是否允许你担保失败。
  • ③检查老年代最大可用连续空间是否大于历次晋升到老年代对象的平均大小。

    • 1)大于,尝试一次有风险的Minor GC。
    • 2)小于或者不允许冒险,Full GC。

但是,在JDK1.6u24之后HandlePromotionFailure参数失效,规则变为只要老年代连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC,否则进行Full GC。

    原文作者:java虚拟机
    原文地址: https://segmentfault.com/a/1190000014602436
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞