JVM-对象的存活与死亡

1.对象是否存活
　　1）引用计数器：给对象添加一个引用计数器，每当有一个地方引用他时，计数器值就加一，当引用失效时，计数器值就减一。任何时刻计数器为零的对象就是不可在被使用的。

　　分析：客观的说，引用计数器算法（Reference Counting）的实现简单，判定效率很高，在大部分情况下，都是一个不错的算法。但是，主流的Java 虚拟机里面没有选用引用计数算法来管理内存，其中最主要的原因是他很难解决u对象之间相互循环引用的问题。例如：objA.instance = objB;及 objB.instance = objA;除此之外两个对象再无其他引用，实际上这两个对象已经不可能再被访问，但是他们因为互相引用着对方，导致他们的引用计数都不为零，于是引用计数算法无法通知GC收集器回收他们。 

　　2）可达性分析算法
　　　  在主流的商用程序语言（Java ， C# 等）的主流实现中都是使用可达性分析（Reachability Analysis）来判定对象是否是存活的。 

　　　  基本思想：通过一系列称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots 没有任何引用链相连（用图论的话来说就是从GC Roots 到这个对象不可达）时，则证明此对象是不可引用的。 

　　      在Java 语言中，可作为GC Roots的对象包括下面几种：
　　　  a.虚拟机栈（栈帧中的本地变量表）中引用的对象
　　　  b.方法区中类静态属性引用的对象
　　　  c.方法区中常量引用的对象
　　　  d.本地方法栈中JIT（即一般说的Native方法）引用的对象

2.引用

　　引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reerence）、虚引用（Phanton Reference）4种，这4种引用强度依次逐渐减弱。 

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

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

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

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

3.垃圾收集算法
　　a) 垃圾-清除算法
　　算法分为"标记"和"清除"两个阶段: 首先标记出所有需要回收的对象，在标记完成后，统一回收所有被标记的对象。 

　　不足：i. 效率问题：标记和清除两个过程的效率都不高
　　            ii. 空间问题：标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致在程序运行过程中需要分配对象时，无法找到足够的连续的内存而不得不提前触发另一次垃圾收集动作。

　　b) 复制算法
　　将可用内存按容量划分为大小相等的两快，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另一块上面，然后再把已使用过的内存空间一次清空。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。
　　现在的商业虚拟机都采用这种收集算法回收新生代。 

　　c) 标记-整理算法
　　标记过程和"标记-清除"算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。 

　　d) 分代收集算法
　　当前商业虚拟机的垃圾收集都采用"分代收集"(Denarationl Collection)算法。 

　　根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代。这样就可以根据各个年代的特点采用最合适的收集算法。在新生代中，每次垃圾收集时，都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高，没有额外空间对它进行配置担保，就必须使用"标记-整理"算法来进行回收。

4.HotSpot的算法实现
　　1) 枚举跟节点
　　GC停顿：可达性分析工作必须在一个能确保一致性的快照中进行。"一致性"是指在整个执行系统看起来就像被冻结在某个时间上，不可以出现分析过程中对象引用关系还在不断变化的情况，该点不满足的话分析结果准确性就无法得到保证。这点是导致GC进行时必须停顿所有Java执行线程的其中一个重要的原因，即使是号称几乎不会发生GC停顿的CMS收集起中，枚举根节点时也是必须停顿的。 

　　在HotSpot的实现中，是使用一组称为OopMap的数据结构来达到这个目的的，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样GC在扫描时就可以得知这些信息类。

　　2) 安全点
　　HotSpot没有为每条指令都生成OopMap，只是在"特定位置"记录类这些信息，这些位置称为安全点(Safepoint),即程序执行时并非所有地方都能停顿下来开始GC，只有到达安全点时才能暂停。 

　　Safepoint选定既不能太少以至于GC等待时间太长，也不能过于频繁以至于过分增大运行的负荷。所以安全点的选定基本上是一程序"是否有让程序长时间执行的特征"为标准选定的，因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度这个原因而过长时间运行，"长时间执行"的最明显的特征就是指令序列复用，例如方法调用、循环跳转、异常跳转等，所以具有这些功能的指令才会产生Safeponit。 

　　如何在GC发生发生时让所有线程(不包括执行JNI调用的线程)都在最近的安全点上才停下来。有两种方案可供选择：
　　I.抢先式中断(Preemtive Suspension)：不需要线程的执行代码主动去配合，在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不再安全点上，就恢复线程让它跑到安全点上。(现在几乎没有虚拟机实现采用抢先式中断来暂停线程响应GC事件) 

　　II.主动式中断(Boluntary Suspension)：思想是当GC需要中断线程的时候，不直接堆线程操作，仅仅简单地设置一个标志，各个线程执行是主动去轮询这个标志，发现中断标志为真时就自己中断挂起。轮询标志的地方和安全点是重合的。另外再加上创建对象需要分配内存的地方。 

　　3) 安全区域(Safe Regin)
　　安全区域是指在一端代码片段中，引用关系不会发生变化。在这个区域的任意地方开始GC都是安全的，我们可以把Safe Regin看作是被扩展了的Safepoint。