在回答上面问题以前,咱们必定要了解JVM在进行垃圾回收时的机制,首先:算法
1、可达性算法
要知道对象何时死亡,咱们须要先知道JVM的GC是如何判断对象是能够回收的。JAVA是经过可达性算法来来判断对象是否存活的。这个算法的基本思路就是经过一系列的称为“GC Roots”的对象做为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用链,当一个对象到GC Roots 没有任何引用链相连时,则证实此对象是不可用的。this
在JAVA语言中,能够做为GC Roots的对象包括下面几种:线程
* 虚拟机栈(栈帧中的本地变量表)中引用的对象。对象
* 方法区中类静态属性引用的对象队列
* 方法区中常量引用的对象内存
* 本地方法栈中JNI(即通常说的Native方法)引用的对象资源
引用计数算法:这也是一个判断对象是否存活的算法,相对于可达性算法较为简单,判断效率也很高,可是没有在JAVA中使用。给对象中添加一个引用计数器,每当一个地方引用它时,计数器值就加1;当引用失效时,计数器就减1;任什么时候刻计数器为0的对象就是不可能再被使用的。
虚拟机
2、引用
JDK1.2以后,JAVA将引用分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Reference)、虚引用(Phantom Reference)。效率
* 强引用:相似Object obj = new Object()这类引用,只要引用还在,垃圾收集器就不会回收掉被引用的对象。变量
* 软引用:系统发生内存溢出异常以前,会把软引用的对象列进回收范围之中进行第二次回收。若是此次回收尚未足够的内存,才会抛出内存溢出异常。
* 弱引用:只要进行垃圾回收,就会回收掉引用关联的对象。
* 虚引用:不会对生存时间构成影响,惟一的目的是对象被回收时收到一个系统通知。
3、对象的复活及finalize()方法
即便在可达性算法中不可达的对象,也并不是是“非死不可”的,这时候它们暂时处于“缓刑阶段”。要真正宣告一个对象的死亡,至少要经历两次标记过程:若是对象在进行可达性分析后发现没有与GC Roots 相链接的引用链,那它将会被第一次标记而且进行一次筛选,筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法,或者finalize()方法已经被虚拟机调用过,虚拟机将这两种状况都视为“没有必要执行”。
若是这个对象被断定为有必要执行finalize()方法,那么这个对象将会放置在一个叫作F-Queue的队列之中,并在稍后由一个由虚拟机自动创建的、低优先级的Finalizer线程去执行它。这里所谓的“执行”是指虚拟机会触发这个方法,但并不承诺会等待它运行结束,这样作的缘由是若是一个对象在finalize()方法中执行缓慢,或者发生了死循环(更极端的状况),将极可能会致使F-Queue队列中其余对象永久处于等待,甚至致使整个内存回收系统崩溃。
finalize()方法是对象逃脱死亡命运的最后一次机会,稍后GC将对F-Queue中的对象进行第二次小规模的标记,若是对象要在finalize()中成功拯救本身——只要从新与引用链上的任何一个对象创建关联便可,譬如把本身(this关键字)赋值给某个类变量或者对象的成员变量,那么在第二次标记时它将被移除出“即将回收”的集合;若是对象这时候尚未逃脱,那么基本上它就真的被回收了。
总结:finalize()并非必需要执行的,它只能执行一次或者0次。若是在finalize中创建对象关联,则当前对象能够复活一次。Finalizer线程不保证必定执行finalize方法,由于此线程的优先级很低,得到CPU资源有限;并且这样会避免finalize执行缓慢或者发生死循环,从而致使整个GC奔溃