JVM垃圾回收机制

垃圾收集(Garbage Collection,GC),要设计一个GC,需要考虑解决下面三件事情:

(1)哪些内存需要回收?
(2)什么时候回收?
(3)如何回收?
 
1.哪些内存需要回收?
根据《Java内存区域模型、对象创建过程、常见OOM》中介绍的java内存模型,其中,程序计数器、虚拟机栈、本地方法栈3个区域随线程而生,随线程而灭;栈中的栈帧随着方法的进入和退出有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的,因此这几个区域的内存分配和回收都具备确定性,故这几个区域就不需要过多考虑回收的问题,因为方法结束或者线程结束时,内存自然就跟着回收了。
对于java堆和方法区则不一样,java堆是存放实例对象的地方,我们只有在程序运行期间才能知道会创建哪些对象,这部分内存的分配和回收是动态的,因此,垃圾收集器所关注的就是这一部分。
对于方法区(或者说HotSpot虚拟机中的永久代),垃圾回收主要是回收这两部分内容:废弃常量和无用的类。对于废弃常量,主要是判断当前系统中有没有对象引用这个常量;对于无用类则比较严格,需要满足下面三个条件:
(1)该类的所有实例都已经被回收,即堆中不存在该类任何势力;
(2)加载该类的ClassLoader已经被回收;
(3)对类对应的java.lang.Class对象没有在任何地方被引用,无法再任何地方通过反射访问该类的方法;
满足了上面三个条件也仅仅是“可以”进行回收了,还要根据HotSpot的一些配置参数综合考虑。
 
2.什么时候回收?
垃圾收集器在对堆进行回收前,第一件事就是要确定这些对象之中哪些还“存活”着,哪些已经“死去”,对于这些已经“死去”的对象我们需要进行回收。判断对象是否存活的算法:
(1)引用计数算法
算法过程如下:
【给每一个对象都添加一个引用计数器,每当有一个地方引用它时,计数器值就加1;当引用失效时,计数器值就减1;任何时刻计数器为0的对象就是不可能再被使用的,也就是可以被回收了。】
引用计数算法实现简单,判定效率也很高,大部分情况下是一个不错的算法。但有一个比较重要的缺点:很难解决对象之间相互循环引用的问题。
比如:
public class ReferenceCountingGC
{
    private Object instance = null;
    
    public static void main(String[] args)
    {
        ReferenceCountingGC objectA = new ReferenceCountingGC();
        ReferenceCountingGC objectB = new ReferenceCountingGC();
        objectA.instance = objectB;
        objectB.instance = objectA;
        objectA = null;
        objectB = null;
        
        System.gc();
    }
}

 

虽然,即使把objectA、objectB都置为null,此时两个对象都不能被回收,因为这两个对象虽然为null了,但是它们的引用计数值都还为1。

但是,上面程序运行结果是:

[GC 4417K->288K(61440K), 0.0013498 secs]
[Full GC 288K->194K(61440K), 0.0094790 secs]
虚拟机还是把这两个对象回收掉了,这也说明虚拟机并不是通过引用计数法来判定对象是否存活的,因为它用的是下面的可达性分析算法。
 
(2)可达性分析算法
目前主流的虚拟机,如java默认虚拟机HotSpot就是用的这种方式。算法基本思路为:
【通过一系列的称为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用链,当一个对象到GC Roots没有任何引用链相连时(或者说从GC Roots到这个对象不可达),则证明此对象是不可用的】。
可作为GC Roots的对象包括:
1)虚拟机栈(栈帧中的本地变量表)中引用的对象;
2)方法区中类静态static属性引用的对象;
3)方法区中常量final引用的对象;
4)本地方法栈中JNI(即一般说的Native方法)引用的对象;
 
    需要注意的是,即使在可达性分析算法中不可达的对象,也并非是“非死不可”的,要真正宣告一个对象死亡,至少要经历两次标记过程:如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链,那它将会被第一次标记并且进行一次筛选,筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法,或者finalize()方法已经被虚拟机调用过(也就是说对象的finalize()方法只能被调用一次),虚拟机将这两种情况都视为“没有必要执行”,基本在下一次gc时,对象就会被回收。
    如果这个对象被判定为有必要执行finalize()方法,那么这个对象将会放置在一个叫做F-Queue的队列中,并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它(即去执行对象的finalize()方法,这里所谓的“执行”是指虚拟机会触发这个方法,但并不承诺会等待它运行结束,主要是为了防止对象的finalize方法执行缓慢或发生死循环,导致其他对象不能被执行的,从而引起内存回收系统崩溃)。finalize()方法是对象逃脱死亡命运的最后一次机会,稍后GC将对F-Queue中的对象进行第二次小规模的标记,判断执行过finalize()方法的对象,有没有在finalize()中拯救自己,如果对象要在finalize()中成功拯救自己——只需要重新与引用链上的任何一个对象建立关联即可,譬如把自己(this)赋值给某个类变量或者对象的成员变量,那在第二次标记时它将被移除出“即将回收”的集合;如果对象这时候还没有逃脱,那基本上它就真的被回收了。
 举例如何在finalize()中拯救自己 :
public class Main{
    private static Object Save_Help = null;
    
    @Override
    public void finalize() throws Throwable {
        super.finalize();
        Main.Save_Help = this;//重新与gc roots连接上
    }
}

 

因此对于不可达对象判定真正死亡的过程小结如下:
(1)GC进行第一次标记并进行一次筛选(筛选那些覆盖了finalize方法并且finalize方法是第一次调用的对象)
(2)另一个低优先级的线程去调用那些被筛选出来的对象的finalize方法;
(3)GC进行第二次标记,如果在前一步中那些筛选出来的对象没有在finalize拯救自己,此时,那些没有覆盖finalize()方法或者finalize()方法已经被虚拟机调用过和这些这些筛选到的但是没有拯救自己的对象都将会回收。
 
 
3.如何回收呢?
此时我们就不得不提一下,回收垃圾所使用的算法。
 
先来说一下JVM的垃圾分代收集(Generational Collection)算法:

  分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区(Heap space)划分为新生代(Young Generation)和 老年代(Tenured Generation),新生代的特点是每次垃圾回收时都有大量的对象需要被回收,而老年代的特点是每次垃圾收集时只有少量对象需要被回收,那么就可以根据不同代的特点采取最适合的收集算法。

  目前大部分垃圾收集器对于新生代都采取复制算法(下面会讲),因为新生代中每次垃圾回收都要回收大部分对象,也就是说需要复制的操作次数较少,但是实际中并不是按照1:1的比例来划分新生代的空间,一般来说是将新生代划分为一块较大的Eden空间和两块较小的Survivor空间,每次使用Eden空间和其中的一块Survivor空间,当进行回收时,将Eden和Survivor中还存活的对象复制到另一块Survivor空间中,然后清理掉Eden和刚才使用过的Survivor空间。

  而由于老年代的特点是每次回收都只回收少量对象,一般使用的是标记-整理(Mark-Compact)算法。

  注意,我们称方法区为永久代(Permanet Generation),一般很少对其进行垃圾回收,所以对象生存都比较持久,它用来存储class类、常量、方法描述等。对永久代的回收主要回收两部分内容:废弃常量和无用的类。

 

 
3.1 标记-清除(Mark-Sweep)算法

这是最基础的算法,标记-清除算法就如同它的名字样,分为“标记”和“清除”两个阶段:首先标记出所有需要回收的对象,标记完成后统一回收所有被标记的对象。

这种算法的不足主要体现在效率和空间:

(1)从效率的角度讲,标记和清除两个过程的效率都不高;

(2)从空间的角度讲,标记清除后会产生大量不连续的内存碎片, 内存碎片太多可能会导致以后程序运行过程中在需要分配较大对象时,无法找到足够的连续内存而不得不提前触发一次垃圾收集动作。

标记-清除算法执行过程如图:

 

3.2 复制算法

为了解决上面算法的效率问题,复制算法出现。它将可用内存按容量划分为大小相等的两块,每次只使用其中的一块。当这一块的内存使用完了,就将还存活的对象复制到另外一块上面,然后再把已使用过的内存空间一次清理掉。
复制算法的优点:
(1)每次都是对整个半区进行内存回收,实现简单、运行也高效;
(2)在那块使用的内存上进行内存分配时,不用考虑内存碎片的问题,只要移动堆顶指针,按顺序分配内存即可;
缺点:
将内存缩小为原来的一半,代价较高。

说一下新生代的GC流程:

在GC开始的时候,对象只会存在于Eden区和名为“From”的Survivor区,Survivor区“To”是空的。紧接着进行GC,Eden区中所有存活的对象都会被复制到“To”,而在“From”区中,仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值,可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中,没有达到阈值的对象会被复制到“To”区域。经过这次GC后,Eden区和From区已经被清空。这个时候,“From”和“To”会交换他们的角色,也就是新的“To”就是上次GC前的“From”,新的“From”就是上次GC前的“To”。不管怎样,都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程,直到“To”区被填满,“To”区被填满之后,会将所有对象移动到年老代中。默认情况下,如果对象年龄达到15岁,就会移动到老年代中。

一般来说,大对象会被直接分配到老年代,所谓的大对象是指需要大量连续存储空间的对象,最常见的一种大对象就是大数组,比如:

  byte[] data = new byte[4*1024*1024]

  这种一般会直接在老年代分配存储空间。

 

3.3 标记-整理算法

复制算法如果在对象存活率较高时,就需要进行较多次的复制操作,效率也会变低。而对于老年代中的对象,一般存活率都较高,因此需要选用其他收集算法:标记 - 整理算法。标记过程仍然与“标记-清除”算法中一样,但是在标记完成后并不直接对可回收对象进行清理,而是让所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存。算法示意图如下:

 

4. 垃圾收集器

如果说上面介绍的收集算法是内存回收的方法论,那么垃圾收集器就是内存回收的具体实现,按照上面的介绍,目前垃圾收集器基本都采用分代收集,因此一个垃圾收集器中一般都存在多种垃圾回收算法。不同的虚拟机提供的垃圾收集器也有很大差异,如下是HotSpot虚拟机基于JDK1.7版本所包含的所有垃圾收集器:

 

HotSpot中共有7中不同的垃圾收集器,如果两个收集器之间存在连线,说明它们之间可以搭配使用,其中,Serial、ParNew、Parallel Scavenge属于新生代收集器,CMS、Serial Old、Parallel Old属于老年代收集器,G1是最新的一种收集器,在新生代和老年代中都可使用。

 

新生代收集器:

1、Serial收集器(复制算法)

最基本、发展历史最久的收集器,这个收集器是一个采用复制算法的单线程的收集器,单线程一方面意味着它只会使用一个CPU或一条线程去完成垃圾收集工作,另一方面也意味着它进行垃圾收集时必须暂停其他线程的所有工作,直到它收集结束为止。后者意味着,在用户不可见的情况下要把用户正常工作的线程全部停掉,这对很多应用是难以接受的。不过实际上到目前为止,Serial收集器依然是虚拟机运行在Client模式下的默认新生代收集器因为它简单而高效。用户桌面应用场景中,分配给虚拟机管理的内存一般来说不会很大,收集几十兆甚至一两百兆的新生代停顿时间在几十毫秒最多一百毫秒,只要不是频繁发生,这点停顿是完全可以接受的。

 

2、ParNew收集器(复制算法)

ParNew收集器其实就是Serial收集器的多线程版本,除了使用多条线程进行垃圾收集外,其余行为和Serial收集器完全一样,包括使用的也是复制算法。ParNew收集器除了多线程以外和Serial收集器并没有太多创新的地方,但是它却是Server模式下的虚拟机首选的新生代收集器,其中有一个很重要的和性能无关的原因是,除了Serial收集器外,目前只有它能与CMS收集器配合工作(看图)。CMS收集器是一款几乎可以认为有划时代意义的垃圾收集器,因为它第一次实现了让垃圾收集线程与用户线程基本上同时工作。ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果,甚至由于线程交互的开销,该收集器在两个CPU的环境中都不能百分之百保证可以超越Serial收集器。当然,随着可用CPU数量的增加,它对于GC时系统资源的有效利用还是很有好处的。它默认开启的收集线程数与CPU数量相同,在CPU数量非常多的情况下,可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

3、Parallel Scavenge收集器(复制算法)

Parallel Scavenge收集器也是一个新生代收集器,也是用复制算法的收集器,也是并行的多线程收集器,但是它的特点是它的关注点和其他收集器不同。介绍这个收集器主要还是介绍吞吐量的概念。CMS等收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间,而Parallel收集器的目标则是达到一个可控制的吞吐量。所谓吞吐量的意思就是CPU用于运行用户代码时间与CPU总消耗时间的比值,即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间),虚拟机总运行100分钟,垃圾收集1分钟,那吞吐量就是99%。另外,Parallel收集器是虚拟机运行在Server模式下的默认垃圾收集器

停顿时间短适合需要与用户交互的程序,良好的响应速度能提升用户体验;高吞吐量则可以高效率利用CPU时间,尽快完成运算任务,主要适合在后台运算而不需要太多交互的任务。

虚拟机提供了-XX:MaxGCPauseMillis和-XX:GCTimeRatio两个参数来精确控制最大垃圾收集停顿时间和吞吐量大小。不过不要以为前者越小越好,GC停顿时间的缩短是以牺牲吞吐量和新生代空间换取的。由于与吞吐量关系密切,Parallel收集器也被称为“吞吐量优先收集器”。Parallel收集器有一个-XX:+UseAdaptiveSizePolicy参数,这是一个开关参数,这个参数打开之后,就不需要手动指定新生代大小、Eden区和Survivor参数等细节参数了,虚拟机会根据当亲系统的运行情况手机性能监控信息,动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。如果对于垃圾收集器运作原理不太了解,以至于在优化比较困难的时候,使用Parallel收集器配合自适应调节策略,把内存管理的调优任务交给虚拟机去完成将是一个不错的选择

 

老年代收集器:

4、Serial Old收集器(标记-整理算法)

Serial收集器的老年代版本,同样是一个单线程收集器,使用“标记-整理算法”,这个收集器的主要意义也是在于给Client模式下的虚拟机使用。

5、Parallel Old收集器(标记-整理算法)

Parallel收集器的老年代版本,使用多线程和“标记-整理”算法。这个收集器在JDK 1.6之后的出现,“吞吐量优先收集器”终于有了比较名副其实的应用组合,在注重吞吐量以及CPU资源敏感的场合,都可以优先考虑Parallel收集器+Parallel Old收集器的组合。

 

6、CMS收集器(标记-清除算法

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的老年代收集器。目前很大一部分Java应用集中在互联网站或者B/S系统的服务端上,这类应用尤其注重服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验,CMS收集器就非常符合这类应用的需求。CMS收集器从名字就能看出是基于“标记-清除”算法实现的

CMS是基于“标记-清除”算法实现的,分为四个步骤:
(1)初始标记(CMS initial mark):仅仅标记GC Roots能直接关联到的对象,(简洁关联的对象下一阶段标记)这个步骤需要“stop the world”;
(2)并发标记(CMS concurrent mark):上一阶段标记过的对象出发,由他们所有可到达的间接对象都在本阶段中标记可并发执行;
(3)重新标记(CMS remark):修正并发标记期间发生变动的那一部分对象,这个步骤需要“stop the world”;
(4)并发清除(CMS concurrent sweep):执行清除阶段。
执行过程如下:
可以看到,初始标记和重新标记阶段都是并行的,需要暂停用户线程(过程比较短);在并发标记和并发清除阶段是并发的,可以和用户线程一起工作。
 
CMS的优点:并发收集、低停顿
CMS的缺点:
(1)对CPU资源非常敏感,面向并发设计程序的通病,虽然不至于导致用户线程停顿,但是会降低吞吐率;
(2)无法清理“浮动垃圾”,由于CMS并发清理阶段用户线程还在运行着,伴随程序运行自然就还会有新的垃圾不断出现,这一部分垃圾出现在标记过程之后,CMS无法在当次收集中处理掉它们,只好留待下一次的GC;
(3)会产生大量空间碎片,因为CMS是基于“标记-清除”算法,这种算法的最大缺点就是会产生大量空间碎片,给分配大对象带来麻烦,不得不提前触发Full GC。为了解决这个问题,CMS提供了一个“-XX:+UseCMSCompaceAtFullCollection”的开关参数(默认开启),用于在CMS收集器顶不住要进行Full GC时开启内存碎片的合并整理过程。

 

7、G1收集器

G1(Garbage-First)收集器是当今收集器技术发展的最前沿成果之一,JDK 7 Update 4后开始进入商用。在G1收集器之前的其他收集器进行收集的范围都是整个新生代或者老年代,而G1收集器不再是这样,使用G1收集器时,Java堆的内存布局就与其他收集器有很大差别,它将整个Java堆分为多个大小相等的独立区域(Region),虽然还保留有新生代和老年代的概念,但新生代和老年代不再是物理隔离的了,它们都是一部分Region的集合。G1收集器跟踪各个Region里面的垃圾堆积的价值大小,在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的Region(这也是Garbage-First名称的由来)。这种使用Region划分内存空间以及有优先级的区域回收方式,保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。

与CMS的“标记-清理”算法不同,G1从整体看来是基于“标记-整理”算法实现的收集器,从局部(两个Region之间)上看是基于“复制”算法实现,无论如何,这两种算法都意味着G1运作期间不会产生内存空间碎片,收集后能提供规整的可用内存;

 

G1的收集过程分为以下几个步骤:
(1)初始标记(Initial Marking)
(2)并发标记(Concurrent Marking)
(3)最终标记(Final Marking)
(4)筛选回收(Live Data Counting and Evacuation)
前几个步骤和CMS有很多相似之处。运行示意图如下:

 

它与CMS回收的执行流程区别就是,CMS的清理过程是并发执行的,而G1回收阶段是并行执行的,也就是只允许回收进程执行,stop the world。

 

说一下Minor GC和Full GC/Major GC

Minor GC:只用于年轻代垃圾回收,当 JVM 无法为一个新的对象分配空间时会触发 Minor GC,比如当 Eden 区满了。所以分配率越高,越频繁执行 Minor GC。

Full GC/Major GC:只针对老年代/永久代进行GC,因为取名叫Full就会让人疑惑,到底会不会先Minor GC。事实上Full GC本身不会先进行Minor GC,我们可以配置,让Full GC之前先进行一次Minor GC,因为老年代很多对象都会引用到新生代的对象,先进行一次Minor GC可以提高老年代GC的速度。比如老年代使用CMS时,设置CMSScavengeBeforeRemark优化,让CMS remark之前先进行一次Minor GC。

 

参考文献:

深入理解Java虚拟机】垃圾回收机制

Java虚拟机5:Java垃圾回收(GC)机制详解

Java垃圾回收机制

 

 

 

 

 

posted @ 2017-09-15 10:01  傍晚的羔羊  阅读(531)  评论(0编辑  收藏  举报