聊聊JVM系列一 对象死了吗？

    程序员:我辛辛苦苦创建的对象,GC你却把他回收了,你还我对象还我对象;

    GC:好啊,摘下星星给你,摘下月亮给你,摘下太阳给你,你要的都给你, 于是 -> java.lang.OutOfMemoryError:PermGen space ......

    作为一个心地善良正直勇敢的程序员,删过库,跑过路,我害怕一个小小的内存溢出,老板,服务器内存不够了,再来100个G

    你知道的,JVM作为程序员的好伙伴,我们一般不会关心他默默为我们做了那些事情,他像水一样无形的存在,除非下大雨发了洪水(OutOfMemoryError:PermGen 一类的状况)我们才发现,哦,原来他这么厉害啊,于是就紧急着翻书,百度,谷歌各种错误,寻求解决之道,这篇文章就是来聊聊和我们平时默默打交道JVM如何判断对象已死.

    先来看张图:

对象引用状态图

    了解对象的引用状态可以帮助你了解GC回收的时候是如何回收的,回收那些对象,怎么判断对象死没死!

• 强引用

     特点：我们平常典型编码Object obj = new Object()中的obj就是强引用。通过关键字new创建的对象所关联的引用就是强引用。 当JVM内存空间不足，JVM宁愿抛出OutOfMemoryError运行时错误（OOM），使程序异常终止，也不会靠随意回收具有强引用的“存活”对象来解决内存不足的问题。对于一个普通的对象，如果没有其他的引用关系，只要超过了引用的作用域或者显式地将相应（强）引用赋值为 null，就是可以被垃圾收集的了，具体回收时机还是要看垃圾收集策略。

• 软引用

     特点：软引用通过SoftReference类实现。 软引用的生命周期比强引用短一些。只有当 JVM 认为内存不足时，才会去试图回收软引用指向的对象：即JVM 会确保在抛出 OutOfMemoryError 之前，清理软引用指向的对象。软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收器回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。后续，我们可以调用ReferenceQueue的poll()方法来检查是否有它所关心的对象被回收。如果队列为空，将返回一个null,否则该方法返回队列中前面的一个Reference对象。

    应用场景：软引用通常用来实现内存敏感的缓存。如果还有空闲内存，就可以暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同时，不会耗尽内存。

•  弱引用

    特点：弱引用通过WeakReference类实现。 弱引用的生命周期比软引用短。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。由于垃圾回收器是一个优先级很低的线程，因此不一定会很快回收弱引用的对象。弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。

    应用场景：弱应用同样可用于内存敏感的缓存。

• 虚引用

    特点：虚引用也叫幻象引用，通过PhantomReference类来实现。无法通过虚引用访问对象的任何属性或函数。幻象引用仅仅是提供了一种确保对象被 finalize 以后，做某些事情的机制。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。虚引用必须和引用队列 （ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。

ReferenceQueue queue = new ReferenceQueue ();
PhantomReference pr = new PhantomReference (object, queue); 

程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。如果程序发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取一些程序行动。
    应用场景：可用来跟踪对象被垃圾回收器回收的活动，当一个虚引用关联的对象被垃圾收集器回收之前会收到一条系统通知。

   简单总结一下:强引用就像大老婆，关系很稳固。
   软引用就像二老婆，随时有失宠的可能，但也有扶正的可能。
   弱引用就像情人，关系不稳定，可能跟别人跑了。
   幻像引用就是梦中情人，只在梦里出现过。

知道了各个对象的引用关系,那么GC是何时进行回收呢,这里有一个算法叫做可达性分析算法,敲黑板,划重点了,期末考试要考,该算法的基本思路就是通过一些被称为引用链（GC Roots）的对象作为起点，从这些节点开始向下搜索，搜索走过的路径被称为（Reference Chain)，当一个对象到GC Roots没有任何引用链相连时（即从GC Roots节点到该节点不可达），则证明该对象是不可用的。看图:

    如上图所示，object1~object4对GC Root都是可达的，说明不可被回收，object5~object7对GC Root节点不可达，说明其可以被回收。
在Java中，可作为GC Root的对象包括以下几种：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• 本地方法栈中JNI（即一般说的Native方法）引用的对象

    总结一下,哪些不可以回收,static修饰的对象,栈中地址指向堆中的对象,方法区中包含String常量和各个常量信息,JNI引用的对象,除了这些的对象都是可以被回收的对象,但是可以被回收的对象并不代表已经死亡,有的对象是有BUFF加持的,可以侥幸逃过GC的追杀令,那么这个是怎么实现的!

    那是因为即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历再次标记过程。
    标记的前提是对象在进行可达性分析后发现没有与GC Roots相连接的引用链。
    1. 第一次标记并进行一次筛选。
    筛选的条件是此对象是否有必要执行finalize()方法。
    当对象没有覆盖finalize方法，或者finzlize方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”，对象被回收。
    2. 第二次标记
    如果这个对象被判定为有必要执行finalize（）方法，那么这个对象将会被放置在一个名为：F-Queue的队列之中，并在稍后由一条虚拟机自动建立的、低优先级的Finalizer线程去执行。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束。这样做的原因是，如果一个对象finalize（）方法中执行缓慢，或者发生死循环（更极端的情况），将很可能会导致F-Queue队列中的其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃。
    Finalize（）方法是对象脱逃死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模标记，如果对象要在finalize（）中成功拯救自己----只要重新与引用链上的任何的一个对象建立关联即可，譬如把自己赋值给某个类变量或对象的成员变量，那在第二次标记时它将移除出“即将回收”的集合。如果对象这时候还没逃脱，那基本上它就真的被回收了。

 

参考

• 《深入理解Java虚拟机》