当JVM自动帮你管理内存后，可能不需要你去了解GC的回收，以及内存的分配。但是当你需要排查各种内存溢出、内存泄露问题的时候，当垃圾回收成为系统系能瓶颈的时候，就必须要求你对GC和内存分配有对应的了解才能解决。
首先提出一个问题：JVM进行GC的时候，是针对什么东西做GC？
一般我们能想到的答案是：针对“不再使用”的对象，或者说是“已死”的对象。其实这样的回答是隔靴搔痒，没能追随到问题的本质。
一般在JVM 里面判断一个对象是否需要进行回收是使用的“可达性分析算法”来判定对象是否存活。基本思路是：通过一系列的“GC Roots”的对象作为起始点，从这些起始点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots 没有任何引用链相连时，那这个对象就是不再使用，可以对其进行垃圾回收。那在Java这个层面，可以作为GC Roots的对象包括下面几种：
1. 虚拟机栈中引用的对象，主要是指栈帧中的本地变量表
2. 方法区中类静态属性引用的对象
3. 方法区中常量引用的对象
4. 本地方法栈中引用的对象
在系统上，有时候需要对回收的对象做不同等级的缓存，那这时候，就需要对各个引用做不同的区分。在JDK1.2 之后将Java引用的概念进行了扩充，分成了，强引用、软引用、弱引用以及虚引用四种，这四种引用强度依次逐渐减缩。
其实，在经过可达性分析算法后被判断为不可达的对象，也不是马上就会被GC掉，如果对象覆盖了finalize()方法，可以在finalize()方法里面，将自己（this）赋值给某个类变量或者独享的成员变量就可以成功逃脱被GC的命运。但是，真心，非常不鼓励这么做。
还需要注意一个问题：
一般我们说垃圾回收的时候，都是针对非永久代而言。非永久代就是指Java堆区，这个区按照分代收集模型，分成新生代和老年代两种。而JVM的整个内存模型中，方法区我们一般把它当做永久代，一般对永久代的垃圾回收效率很低，并且Java虚拟机规范中也没有要求方法区进行垃圾回收的实现。但是如果要回收方法区，需要回收的就是：无用的常量和无用的类。
