java垃圾回收机制 你理解了嘛?
我们知道,在平时的开发当中,有时候我们需要建立大量的物件,如果我们动态建立的物件没有得到及时回收,持续堆积,最后会导致内存被占满,造成溢位。因此Java 提供了一种垃圾回收机制,在后台建立一个守护程序。该程序会在内存紧张的时候自动跳出来,把内存的垃圾全部进行回收,从而保证程式的正常执行。
在前面的文章中曾经分析了java8的内存结构和类的载入机制。这篇文章,我主要分析一下垃圾回收算法。为什么要安排这样的顺序去讲解,主要是根据类的生命周期来的。我们知道类的生命周期大体上包含了七个:
在《类的载入机制》一文中,曾经描述了前五个过程。垃圾回收机制就是描述的最后一个解除安装过程,也就是把垃圾如何从内存中回收的问题。
有了这个概念,就可以开始今天的文章了:
主要涉及下面几个问题:
首先,回顾一下jvm中的内存结构然后,确定那些物件是垃圾?其次,有哪些算法回收这些垃圾?接下来,jvm提供了哪些垃圾回收器最后,对垃圾回收机制进行一个总结一、jvm的内存结构
我们的垃圾回收都是基于内存去回收的,因此,先要对内存结构有一个大概的了解,下面这一张是java7的内存结构:
从上面我们可以看到,Java内存执行时区域大概分了三部分,
其中PC暂存器、java虚拟机器栈、本地方法栈3个区域是所有执行绪独有的一块区域,随执行绪而生,随执行绪而灭。栈中的栈帧随着方法的进入和退出而有条不紊地执行着入栈和出栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的,因此这几个区域的内存分配和回收都具备确定性,在这几个区域内就不需要过多考虑回收的问题,因为方法结束或者执行绪结束,内存自然就跟随着回收了。而Java堆和方法区则不一样,一个界面中的多个实现类需要的内存可能不一样,一个方法中的多个实现类需要的内存可能不一样,一个方法中的多个分支需要的内存也可能不一样,只有在程式处于执行期间时才能知道会建立哪些物件,这部分内存的分配和回收是动态的,垃圾收集关注的是这部分的内存。知道了我们要回收的这部分割槽域之后,下面就是确定那些物件是垃圾的问题了。
二、哪些物件是垃圾呢?
为了确定哪些物件是垃圾,jvm为我们提供了一些算法去判定。常见的判断是否存活有两种方法:引用计数法和可达性分析。
1、引用计数法
为每一个建立的物件分配一个引用计数器,用来储存该物件被引用的个数。当该个数为零,意味着没有人再使用这个物件,可以认为“物件死亡”。每当有一个地方去引用它时候,引用计数器就增加1。但是,这种方案存在严重的问题,就是无法检测“循环引用”:当两个物件互相引用,它俩的计数都不为零,因此永远不会被回收。而实际上对于开发者而言,这两个物件已经完全没有用处了。
比如我们都曾经遇到过:两个类相互是对方的成员变数,toString的时候,相互呼叫。造成循环引用。
因此,Java 里没有采用这样的方案来判定物件的“存活性”。
2、可达性分析
可达性分析基本思路是把所有引用的物件想象成一棵树,从树的根结点 GC Roots 出发,持续遍历找出所有连线的树枝物件,这些物件则被称为“可达”物件,或称“存活”物件。不能到达的则被可回收物件。
下面这张图就是可达性分析的描述:
我们发现,GC Roots 本身是一个出发点,也就是说我们每次进行可达性分析的时候都要从这个初始点出发。换句话说,初始点我们一定是可达的。那么,Java 里有哪些物件可以作为GC Roots呢?主要有以下四种:
虚拟机器栈(帧栈中的本地变量表)中引用的物件。方法区中静态属性引用的物件。方法区中常量引用的物件。本地方法栈中 JNI 引用的物件。三、有哪些算法回收这些垃圾呢?
上面我们已经能够确定那些物件可以被视为垃圾了。下面我们可以分析一下,如何去回收这些垃圾,同样的,有一系列算法。首先我们定义一个规则确定那些是垃圾、存活物件、空白空间
1、标记-清理
第一步(标记),利用可达性遍历内存,把“存活”物件和“垃圾”物件进行标记。第二步(清理),我们再遍历一遍,把所有“垃圾”物件所占的空间直接 清空 即可。
结果如下
特点:
简单方便容易产生内存碎片2、标记-整理
上面的方法我们发现会产生内存碎片,因此在这个方法中同样为两步:
第一步(标记):利用可达性遍历内存,把“存活”物件和“垃圾”物件进行标记。
第二步(整理):把所有存活物件堆到同一个地方,这样就没有内存碎片了。
结果如下
特点:
适合存活物件多,垃圾少的情况需要整理的过程3、复制
将内存按照容量划分为大小相等的两块,每次只使用其中的一块。当这一块用完了,就将还活着的物件复制到另一块上,然后再把使用过的内存空间一次性清理掉
过程如下:
特点:
简单不会产生碎片内存利用率太低,只用了一半四、堆和方法区的垃圾回收
上面我提到了三种方法来回收内存,下面要讲的分代回收算法是第四种。首先在文章的第一部分我们曾说到,java中的垃圾回收大致在两部分,第一个就是堆、第二个就是方法区。为此先看方法区是如何进行垃圾回收的。
1、方法区的垃圾回收
方法区又叫做永久代。永久代的垃圾回收主要有两部分:废弃常量和无用的类。
首先是废弃常量垃圾回收的一般步骤:
第一步:判定一个常量是否是废弃常量:没有任何一个地方对这个常量进行引用就表示是废弃常量。
第二步:垃圾回收
然后是无用的类垃圾回收的一般步骤
第一步:判定一个类是否是“无用的类”:需要满足下面三个条件
Java堆中不存在该类的任何例项,也就是该类的所有例项都被回收载入该类的ClassLoader已经被回收该类对应的Class物件在任何地方没有引用了,也不能通过反射访问该类的方法。第二步:满足上面三个条件就可以回收了,但不是强制的。
注意:《java虚拟机器规范》里面曾经说到过,不要求虚拟机器对方法区进行垃圾回收。而且方法区进行垃圾回收价效比比较低。
2、Java 堆的垃圾回收:分代回收算法
在讲回收算法前,我们先来看一下 Java 堆的结构。
Java 堆空间分成了三部分,这三部分用来储存三类资料:
刚刚建立的物件。存活了一段时间的物件。永久存在的物件。也就是说,常规的 Java 堆至少包括了 新生代 和 老年代 两块内存区域,而且这两块区域有很明显的特征:
新生代:存活物件少、垃圾多老年代:存活物件多、垃圾少针对这种特点,我们有如下的几种方案;
(1)新生代-复制 回收机制
对于新生代区域,由于每次 GC 都会有大量新物件死去,只有少量存活。因此采用 复制 回收算法,GC 时把少量的存活物件复制过去即可。但是从上面我们可以看到,新生代也划分了三个部分比例:Eden:S1:S2=8:1:1。
其中 Eden 意为伊甸园,形容有很多新生物件在里面建立;S1和S2中的S表示Survivor,为幸存者,即经历 GC 后仍然存活下来的物件。
工作原理如下:
首先,Eden对外提供堆内存。当 Eden区快要满了,触发垃圾回收机制,把存活物件放入 Survivor A 区,清空 Eden 区;Eden区被清空后,继续对外提供堆内存;当 Eden 区再次被填满,对 Eden区和 Survivor A 区同时进行垃圾回收,把存活物件放入 Survivor B区,同时清空 Eden 区和Survivor A 区;当某个 Survivor区被填满,把多余物件放到Old 区;当 Old 区也被填满时,进行 下一阶段的垃圾回收。下面看看老年代的垃圾回收。
(2)老年代-标记整理 回收机制
老年代的特点是:存活物件多、垃圾少。因此,根据老年代的特点,这里仅仅通过少量地移动物件就能清理垃圾,而且不存在内存碎片化。也就是标记整理的回收机制。既然是标记整理算法,而且老年代内部也不存在着内存划分,所以只需要根据标记整理的具体步骤进行垃圾回收就好了。
到了这,基本上对堆内存的分代回收机制进行了描述。但是要有一个问题没有解决,那就是jvm提供的垃圾回收器。
五、垃圾回收器
如果说收集算法是内存回收的方法论,那么垃圾收集器就是内存回收的具体实现。
在了解 垃圾回收器之前,首先得了解一下垃圾回收器的几个名词。
1. 吞吐量
CPU 用于执行使用者程式码的时间与 CPU 总消耗时间的比值。比如说虚拟机器总运行了 100 分钟,使用者程式码时间99分钟,垃圾回收时间 1 分钟,那么吞吐量就是 99%。
2. 停顿时间
停顿时间 指垃圾回收器正在执行时,应用程序 的 暂停时间。
3. GC的名词
新生代GC:Minor GC
老年代GC:Major GC
4. 并发与并行
(1)序列(Parallel)
垃圾回收执行绪 进行垃圾回收工作,但此时使用者执行绪仍然处于等待状态。
(2)并发(Concurrent)
这里的并发指使用者执行绪与垃圾回收执行绪交替执行。
(3)并行(Parallel)
这里的并行指使用者执行绪和多条垃圾回收执行绪分别在不同CPU上同时工作。
下面其中垃圾回收器是基于HotSpot虚拟机器。先给一张图看一下
在 JVM 中,具体实现有 Serial、ParNew、Parallel Scavenge、CMS、Serial Old(MSC)、Parallel Old、G1 等。在上图中,你可以看到不同垃圾回收器适合于不同的内存区域,如果两个垃圾回收器之间存在连线,那么表示两者可以配合使用。
下面对这其中垃圾回收器有一个了解。
第一种:Serial(单执行绪)
Serial 回收器是最基本的 新生代垃圾回收器,是单执行绪的垃圾回收器。采用的是 复制算法。垃圾清理时,Serial回收器不存线上程间的切换,因此,在单 CPU` 的环境下,垃圾清除效率比较高。
第二种:Serial Old(单执行绪)
Serial Old回收器是 Serial回收器的老生代版本,单执行绪回收器,使用 标记-整理算法。在 JDK1.5 及其以前,它常与Parallel Scavenge回收器配合使用,达到较好的吞吐量,另外它也是CMS回收器在Concurrent Mode Failure时的后备方案。
第三种:ParNew(多执行绪)
ParNew回收器是在Serial回收器的基础上演化而来的,属于Serial回收器的多执行绪版本,采用复制算法。执行在新生代区域。在实现上,两者共用很多程式码。在不同执行环境下,根据CPU核数,开启不同的执行绪数,从而达到最优的垃圾回收效果。
第四种:Parallel Scavenge(多执行绪)
Parallel Scavenge回收器也是执行在新生代区域,属于多执行绪的回收器,采用复制算法。与ParNew不同的是,ParNew回收器是通过控制垃圾回收的执行绪数来进行引数调整,而Parallel Scavenge回收器更关心的是程式执行的吞吐量。即一段时间内使用者程式码执行时间占总执行时间的百分比。
第五种:Parallel Old(多执行绪)
Parallel Old回收器是Parallel Scavenge回收器的老生代版本,属于多执行绪回收器,采用标记-整理算法。Parallel Old回收器和Parallel Scavenge回收器同样考虑了吞吐量优先这一指标,非常适合那些注重吞吐量和CPU资源敏感的场合。
第六种:CMS(多执行绪回收)
CMS回收器是在最短回收停顿时间为前提的回收器,属于多执行绪回收器,采用标记-清除算法。
第七种:G1回收器
G1是 JDK 1.7中正式投入使用的用于取代CMS的压缩回收器。它虽然没有在物理上隔断新生代与老生代,但是仍然属于分代垃圾回收器。G1仍然会区分年轻代与老年代,年轻代依然分有Eden区与Survivor区。
G1首先将堆分为大小相等的 Region,避免全区域的垃圾回收。G1的分割槽示例如下图所示:
这种使用区域划分内存空间以及有优先级的区域回收方式,保证G1回收器在有限的时间内可以获得尽可能高的回收效率。
下面对这几种垃圾回收机制进行一个总结:
六、总结
OK,到这jvm的垃圾回收机制都已经讲完了,有问题还请大家提出来,欢迎批评指正。如果你喜欢,还请给个关注,谢谢。