在堆里存放着java世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前需要知道哪些对象还存活，哪些对象已经死去。那怎么样去判断对象是否存活呢？　　

　　一、判断对象是否存活算法

　　1、引用计数法

　　实现思路：给对象添加一个引用计数器。每当有一个地方引用它时，计数器加1；引用失效时计数器减1。在任何时刻计数器为0的对象就是不可能再被使用的。

　　优点：实现简单，效率高。

　　缺点：很难解决对象之间的相互循环引用。

　　2、可达性分析算法

　　实现思路：通过GC Roots的对象作为起始点，从这些节点向下搜索，搜索走过的路径成为引用链，当一个对象到GC Root没有任何引用链相连时，则证明对象是不可用的。

　　优点：可以很好的解决对象相互循环引用的问题。

　　缺点：没想到

　　二、在java中，哪些对象可以作为GC Roots呢？

　　1、虚拟机栈（栈帧中的本地变量表）中引用的对象

　　2、方法区中静态类属性和常量引用的对象

　　3、本地方法栈中JNI（Native方法）引用的对象

　　三、对象标记回收过程

　　如果一个对象在可达性分析算法中是不可达的，那是不是这个对象就一定会被回收呢？

　　答案是否定的，这些对象还有一次复活的机会。要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与任何的GC Roots相连接的引用链，那它会被第一次标记，且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。在什么情况下不会执行对象的finalize方法呢？1、当对象没有覆盖finalize()方法。2、该对象的finalize()方法已经被虚拟机调用过。如果一个对象被判定为有必要执行finalize方法，那这个对象会被放置在一个F-Queue的队列中，等待虚拟机自己创建的一个低优先级的Finalizer线程去执行。finalize方法是这些对象逃脱死亡命运的最后一次机会，如果对象要在finalize中成功拯救自己，只要重新与引用链上的任何一个对象建立关联即可，譬如把自己赋值给某个变量或者对象的成员变量。那在第二次标记是它将被移除“即将回收”集合。否则就只能等待着回收了。

　　但是，finalize方法运行代价高，不确定性大，无法保证各个对象的调用顺序。在日常开发中强烈不建议使用这个方法，如果需要有“关闭外部资源”之类的工作，使用try-finally或者其他方式都可以做得更好更及时。

　　四、垃圾收集算法

　　1、标记-清除算法

　　实现思路：标记算法实现很简单，通过前面介绍的可达性分析算法标记所有需要回收的对象，然后统一回收所有被标记的对象。它是最基础的收集算法，后续的收集算法都是基于这种思路并对其不足进行改进而得到的。

　　缺点：效率不高、产生内存碎片

　　2、复制算法V1

　　实现思路：将内存按容量划分为大小相等的两块，每次使用其中的一块。当一块的内存用完了，就将还存活的对象复制到另一块上面，然后再把已使用过的内存空间一次清理掉。这样每次都是针对整个半区的内存进行回收，不用考虑内存碎片问题。

　　优点：简单高效、不会有内存碎片问题

　　缺点：内存会缩小为原来一半，代价高

　　3、复制算法V2（新生代采用的算法）

　　实现思路：替代原来将内存一分为二的方案，将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次Eden使用其中的一块Survivor。当回收时，讲Eden和Survivor中还存活的对象一次性赋值到另外一块Survivor空间上，最后清理掉Eden和刚才使用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1（研究表明，新时代中98%的对象是朝生夕死的），也就是每次新时代中可用内存空间为整个新时代容量的90%。只有10%的内存会被浪费。但是，如果存活的对象占用的内存大于新时代的10%怎么办？这就需要依赖其他内存（老年代）进行分配担保了。

　　优点：改善了第二点中的缺点。

　　4、标记-整理算法（老年代采用的算法）

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