javaGC回收机制
在面试java后端开发的时候一般都会问到java的自动回收机制(GC)。在了解java的GC回收机制之前,我们得先了解下Java虚拟机的内存区域。
java虚拟机运行时数据区
java虚拟机在执行的过程中会将其管理的内存划分为不用的数据区域,不同的区域有不同的作用以及线程时间。
数据区划分如下:
下面将介绍不同区域的作用,如果已经了解可以跳过
-
程序计数器(线程私有)
程序计数器的作用很简单,就是记录当前线程所执行的位置(所以为线程私有),可以看成当前线程所执行的字节码的行号指示器。如果执行的是native方法,则这个计数器为空。
-
Java虚拟机栈(线程私有,生命周期与线程相同)
虚拟机栈描述的是Java方法执行的内存模型:每个Java方法在执行的时候都会创建一个栈帧(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出口等信息。
-
本地方法栈(线程共享)
本地方法栈与虚拟机栈发挥的作用类似,不过它执行的是虚拟机使用的Native方法。
-
Java堆(线程共享)
Java堆是Java虚拟机管理内存中最大的一块,在虚拟机启动的时候创建。此区域的唯一目的就是存放对象示例,几乎所有的对象实例都是在这分配内存的。
-
方法区(线程共享)
刚开始的时候,看到方法区域,第一想法就是
Java中的方法
,不过实际上并不是这样。方法区储存的是已被虚拟机加载的类信息,常量,静态变量,即时编译器编译后的代码等数据。我们可以想一想,当我们需要创建一个对象的时候,我们需要根据类的信息去创建,那么类的信息在哪?当然是在方法区!-
运行时常量池
运行时常量池是方法区的一部分,用于存放编译期生成的各种字面量和符号引用。
-
垃圾收集(Garbage Collection)GC
前面说了这么多,现在我们终于可以来说说垃圾回收机制了。
首先我们得说下垃圾回收回收的是哪一部分内存区域。在前面我们知道:程序计数器,虚拟机栈,本地方法栈都是线程私有的,随着线程生或灭。这部分我们就不需要考虑了。所以我们需要考虑的就是Java堆
和方法区
。
垃圾回收的内容
回收java堆
-
对象是否可以被回收
判断对象是否被回收就是当一个对象死了的时候就需要进行回收。那么如何判断一个对象是否死亡,在Java中,我们使用了可达性分析算法来判断对象是否存活。
当一个对象到GC Roots没有任何链(称为
引用链
)相连(也就是对象到GC Roots不可达)则判定对象已经死亡(如图中的Object5,Object6),可进行回收。可作为GC Roots的对象:
- 虚拟机栈(栈帧中的本地变量表)中引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中JNI(即一般说的Native方法)引用的对象
在前面中,我们知道,不可达就意味着回收,可是当我们的内存很够时,有一些对象又是“食之无味弃之可惜”的时候,我们怎么办呢?在JDK1.2中,Java对引用进行扩张,分为以下引用:
- 强引用(Strong Reference):只要强引用还在,则不回收
- 软引用(Soft Reference):描述一些有用但非必须的对象,在系统将要发生内存溢出之前,将这些对象列入回收范围之中进行第二次回收。<java.lang.ref.SoftReference>
- 弱引用(Weak Reference):比软引用还要弱,被弱引用关联的对象只能生存到下一次垃圾收集发生之前。<java.lang.ref.WeakReference>
- 虚引用(Phantom Reference):不会对生存时间构成影响,唯一的作用就是这个对象被回收的时候会收到一个通知。<java.lang.ref.PhantomReference>
-
最终判断对象是否能够存活
在可达性分析算法中,如果一个对象不可达,那么这个对象就进入到了“缓刑”阶段,真正宣告一个对象死亡还需要进行两次标记。
-
第一次标记进行筛选
对不可达的对象进行第一次标记并进行筛选。筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize方法,或者finzlize方法已经被虚拟机调用过(意思就是finalize()方法只能被调用一次,也就是对象只能够有一次避免被回收),虚拟机将这两种情况都视为“没有必要执行”,对象被回收。
-
第二次标记
如果这个对象被判定为有必要执行finalize()方法,那么这个对象将会被放置在一个名为:F-Queue的队列之中,并在稍后由一条虚拟机自动建立的、低优先级的Finalizer线程去执行。这里所谓的“执行”是指虚拟机会触发这个方法,但并不承诺会等待它运行结束。这样做的原因是,如果一个对象finalize()方法中执行缓慢,或者发生死循环(更极端的情况),将很可能会导致F-Queue队列中的其他对象永久处于等待状态,甚至导致整个内存回收系统崩溃。
finalize()方法是对象脱逃死亡命运的最后一次机会,稍后GC将对F-Queue中的对象进行第二次小规模标记,如果对象要在finalize()中成功拯救自己----只要重新与引用链上的任何的一个对象建立关联即可,譬如把自己赋值给某个类变量或对象的成员变量,那在第二次标记时它将移除出“即将回收”的集合。如果对象这时候还没逃脱,那基本上它就真的被回收了。
-
回收方法区
在Java虚拟机规范中说过不要求方法区实现垃圾收集,并且进行垃圾收集的“性价比”也较低。不过既然写了,那必定有方法区的垃圾收集,主要回收以下两部分内容:
-
废弃常量:字面量和符号引用
-
无用的类:
- 该类的所有实例都被回收,即:Java堆中不存在该类的任何实例
- 该类的Classloader已经被回收
- 该类对用的java.lang.Class对象没有任何地方被引用,无法在任何地方通过反射访问到该类的方法。
当满足以上三个条件时,也未必说是一定要被回收。也仅仅是可以。
垃圾收集算法
年代划分
我们通过对象的存活周期来将JVM堆中内存空间划分为新生代和老年代。
-
新生代:主要是用来存放新生的对象。一般占据堆的1/3空间。
-
老年代:主要存放应用程序中生命周期长的内存对象。
算法
OK,说了这么多,我们现在终于可以来说说垃圾收集的算法了。
下面的图片来源于这位大佬,这位大佬讲的真滴不错。
-
标记-清除算法(Mark-Sweep)
标记:首先标记需要回收的对象,标记完成统一回收
清除:就是清除对象,释放空间
缺点:标记和清除的效率不高,同时产生大量不连续的内存碎片(可能不利于下次的空间分配)。
-
标记整理法
标记整理算法相比较于标记清除算法,标记-整理算法在清除的时候并不是一个一个的清除对象释放空间,而是一次清除全部的可回收的空间。这样使得空间变得连续,有利于对象空间的分配。
-
复制算法
- 将内存分成两块大小相等的空间。
- 每次使用其中一块。
- 进行垃圾回收的时候,将不要的回收的对象复制到另外一个空间
- 完全清除原来的空间。
优点:速度快,效率高,不会产生内存碎片。
缺点:显而易见,空间浪费大,缩小了一半。
解决方法:
IBM研究表明:新生代98%的对象是“朝生夕死”,所以我们并不需要将空间划分为1:1,而是将空间划分为
Eden:Survivor:Survivor = 8:1:1
。每次使用Eden和其中一块Survivor。- 使用其中Eden和一块Survivor。
- 进行回收时,讲Eden和Survivor还存活的对象一次性的复制到另外一块Survivor上。
- 清理第一步中的Eden和Survivor。
如果第二步中Survivor的空间不足,则依赖于其他内存(老年代)进行分配担保(也就是讲存活的对象放入老年代)。
-
分代收集算法
分代收集算法其实就是前面几种算法的应用。根据年代使用不同的算法
- 新生代GC(MinorGC,回收速度快):复制算法
- 老年代(Full GC/Major GC,比Minor慢10倍以上):标记整理法和标记清除法。
对象分配内存区域
- 新生代:大多数情况下爱,对象在新生代Eden区中分配。如果没有足够的空间,则发起一次MinorGC。
- 老年代:
- 大对象直接进入老年代。比如说很长的字符串或数组。
- 长期存活的对象:没熬过一次MinorGC,年龄age增加一岁,当它的年龄超过一定岁数时(默认15,可设置),则进入老年代中。
- 动态对象年龄判定:如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代。
参考书籍:《深入理解Java虚拟机》——周志明,这本书写的太好了,写的通熟易懂。强烈推荐去看看。