JVM中的引用

无论是通过引用计数算法判断对象的引用对象，还是通过可达性分析算法判断对象的引用链是否可达，判定对象是否是否存活都与引用有关。在jdk1.2以前，java中的引用的定义很传统:如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就叫做这块内存代表着一个引用，这种定义很纯粹，但是太过狭隘，一个对象在这种定义下只有引用和没有引用两种状态，对于如何描述一些 食之无味弃之可惜 的对象来说就显得无能为力。我们希望能描述这样一类对象：当内存空间还足够时，则能保留在内存中；如果内存空间在进行垃圾收集器后还是非常紧张，则可以抛弃这些对象，很多系统的缓存功能都符合这样的场景。

​ 在jdk1.2之后，java对引用的概念进行了扩充，将引用分为强引用，软引用，弱引用，虚引用 4种。这4种引用强度依次逐渐减弱。

​ 强引用就是指在程序代码中普遍存在的，类似"Object obj = new Object()"这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。

​ 软引用是用来描述一些还有用但并非必需的对象，对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在jdk1.2之后，提供了SoftReference类来实现软引用。

​ 弱引用也是用来描述非必需对象的，但是他的强度比软引用更弱一些，被软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集器发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉被弱引用关联的对象。在jdk1.2之后，提供了WeakReference类来实现弱引用。

​ 虚引用，也叫做幽灵引用或者幻影引用，他是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供了PhantomReference类来实现虚引用。

​

​ 即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候她们暂时处于“缓刑”阶段，要真正宣告一个对象的死亡，至少要经过两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize（）方法。当对象没有覆盖finalize（）方法，或者finalize（）方法已经被虚拟机调用过，虚拟机将这两种情况视为“没有必要执行”。

​ 如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列中，并在稍后由一个虚拟机自动建立起来的，低优先级的Finalizer线程去执行它。这里所谓的执行 指的是虚拟机会触发这个方法，但并不会承诺会等待它运行结束，这样做的原因是，如果一个对象在finalize（）方法中执行缓慢，或者发生了死循环，将很可能导致F-Queue队列中其他对象永久处于等待，甚至导致整个内存回收系统崩溃。finalize（）方法是对对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize（）种成功拯救自己--只要重新与引用链上的任何一个对象建立关联即可，比如把自己（this）关键字赋值给某个类变量或者对象的成员变量，那在第二次标记时，它就会被移出“即将回收”的集合；如果对象这时候还没有逃脱，那基本上他就真的被回收了。

读后感

​ 有意思，有意思，我愿叫做它为对象的救赎，对象也想在内存中活着，想尽一切办法，拼命地抓住自己的救命稻草---finalize，这不就是我人生的真实写照嘛，哈哈哈。与其把编程语言看做一门技术书，不如看做自己人生的侧面写照苦情戏的男主角。