GC需要完成的3件事情：
1.哪些内存需要回收？
2.什么时候回收？
3.如何回收？
哪些内存需要回收？
对于程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭，栈帧随方法的进入和退出执行入栈和出栈的操作。每一个栈帧分配多少内存基本上在类结构确定下来时就已知（运行期JIT编译器会进行一些优化，但大体上认为是编译期可知），因此这3个区域的内存分配和回收具备确定性，因为方法结束或者线程结束，内存就跟着被回收了。
而Java堆和方法区则不一样。只有在运行期才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器关注的是这部分内存。
什么时候回收？
堆存放着几乎所有的对象实例，如何确定对象是否有必要继续存在。
可达性分析算法，基本思路是通过一系列称为“GC Roots”的对象作为起始点，从这些节点向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连（GC Roots到这个对象不可达），则证明此对象不可用。
object5、object6、object7虽然互有关联，但它们到GC Roots是不可达的，所以将被判定为可回收的对象。
可作为GC Roots的对象
1.虚拟机栈（栈帧中的本地变量表）中引用的对象
2.方法区中类静态属性引用的对象
3.方法区常量引用的对象
4.本地方法栈中JNI（Native方法）引用的对象
JDK1.2之后，引用概念被扩充了，以便可以描述更复杂的对象，比如当内存空间还足够时，则继续保留在内存之中，如果内存空间在进行垃圾收集后还是非常紧张，则可以抛弃这些对象（缓存功能）。
1.强引用：类似Object o = new Object()
2.软引用：描述有用但并非必须的对象，在系统即将发生内存溢出的时候，把这些对象列进回收范围，进行第二次回收，如果这些回收还没有足够内存，才抛出内存溢出异常
3.弱引用：描述非必须对象，强度比软引用弱一些，只能生存到下一次垃圾收集发生之前，无论内存是否足够，都会被回收掉
4.虚引用：最弱的引用关系，为一个对象设置虚引用关联的唯一目的是能在这个对象被垃圾回收时收到一个系统通知
回收方法区：
回收的目标：废弃常量和无用的类。
没有任何引用的常量为废弃常量
判断无用的类满足的条件：
1.该类的所有实例都已经被回收，也就是Java堆中不存在该类的任何实例
2.加载该类的ClassLoader已经被回收
3.该类对应的java.lang.Class对象没有在任何地方被引用，无法再任何地方通过反射访问该类
垃圾收集算法：
1.标记-清除（Mark-Sweep）
分为标记和清除两个阶段，首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。
不足之处：效率问题，标记和清除两个过程的效率都不高；空间问题，标记清除之后产生大量不连续的内存碎片，空间碎片太多导致以后分配较大对象，无法找到足够的连续空间而不得不触发另一次垃圾收集动作。
2.复制算法（Copying）
将可用内存容量划分为大小相等的两块，每次只使用其中一块，当这一块的内存用完了，就将还存活着的对象复制到另一块上，然后再把已使用过的内存一次清理掉。使得每次都是对整个半区进行内存回收，不用考虑内存碎片问题，只要移动堆顶指针，按序分配即可，实现简单，运行高效。
缺点：内存缩小为原来的一半，浪费大量内存空间。
商用虚拟机都采用这种算法回收新生代，IBM专门研究表明，新生代的对象98%是“朝生夕死”，所以不需要按1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间，和两块较小的Survivor空间，每次使用Eden和其中一块Survivor，当回收时，将Eden和Survivor中还存活的对象一次性复制到另一块Survivor空间，最后清理掉Eden和刚用过的Survivor空间，HotSpot默认Eden和Survivor的大小比例是8:1，只有10%的内存被“浪费”。没有办法保证每次回收只有不多于10%的对象存活，当Survivor空间不够时，需要依赖其他内存（老年代）进行分配担保。
3.标记-整理算法（Mark-Compact）
复制收集算法在对象存活率较高时要进行较多的复制操作，效率会变低，如果不想浪费50%空间，就需要额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的情况，所以老年代一般不使用这种算法。而是使用标记-整理算法。
标记过程与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
4.分代收集算法
只是根据对象存活周期的不同将内存划分为几块，一般分为新生代和老年代，这样可以根据年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集都有大批对象死去，只有少量存活，就选用复制算法，而老年代对象存活率高，采用标记-清理或者标记-整理算法进行回收。