为什么需要垃圾回收
如果不进行垃圾回收，内存迟早都会被消耗空，因为我们在不断的分配内存空间而不进行回收。除非内存无限大，我们可以任性的分配而不回收，但是事实并非如此。所以，垃圾回收是必须的。
哪些内存需要回收？
哪些内存需要回收是垃圾回收机制第一个要考虑的问题，所谓“要回收的垃圾”无非就是那些不可能再被任何途径使用的对象。那么如何找到这些对象？
可达性分析法，这个算法的基本思想是通过一系列称为“GC Roots”的对象作为起始点，从这些节点向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链（即GC Roots到对象不可达）时，则证明此对象是不可用的。
如何选取GCRoots对象呢？在Java语言中，可以作为GCRoots的对象包括下面几种：
(1) 虚拟机栈（栈帧中的局部变量区，也叫做局部变量表）中引用的对象。
(2) 方法区中的类静态属性引用的对象。
(3) 方法区中常量引用的对象。
(4) 本地方法栈中JNI(Native方法)引用的对象。
下面给出一个GCRoots的例子，如下图，为GCRoots的引用链。
由图可知，obj8、obj9、obj10都没有到GCRoots对象的引用链，即便obj9和obj10之间有引用链，他们还是会被当成垃圾处理，可以进行回收。
四种引用状态
在JDK1.2之前，Java中引用的定义很传统：如果引用类型的数据中存储的数值代表的是另一块内存的起始地址，就称这块内存代表着一个引用。这种定义很纯粹，但是太过于狭隘，一个对象只有被引用或者没被引用两种状态。我们希望描述这样一类对象：当内存空间还足够时，则能保留在内存中；如果内存空间在进行垃圾收集后还是非常紧张，则可以抛弃这些对象。很多系统的缓存功能都符合这样的应用场景。在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用4种，这4种引用强度依次减弱。
1、强引用
代码中普遍存在的类似"Object obj = new Object()"这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
2、软引用
描述有些还有用但并非必需的对象。在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围进行二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。Java中的类SoftReference表示软引用。
3、弱引用
描述非必需对象。被弱引用关联的对象只能生存到下一次垃圾回收之前，垃圾收集器工作之后，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。Java中的类WeakReference表示弱引用。
4、虚引用
这个引用存在的唯一目的就是在这个对象被收集器回收时收到一个系统通知，被虚引用关联的对象，和其生存时间完全没关系。Java中的类PhantomReference表示虚引用。
JAVA什么时候执行垃圾回收
JAVA的垃圾回收分为三个区域：新生代，老年代，永久代。
1、新生代：
- Eden（伊甸园）区是新对象分配内存的地方，由于堆是所有线程共享的，因此在堆上分配内存需要加锁。而Sun JDK为提升效率，会为每个新建的线程在Eden上分配一块独立的空间由该线程独享，这块空间称为TLAB（Thread Local Allocation Buffer）。在TLAB上分配内存不需要加锁，因此JVM在给线程中的对象分配内存时会尽量在TLAB上分配。如果对象过大或TLAB用完，则仍然在堆上进行分配。如果Eden区内存也用完了，则会进行一次Minor GC（young GC）。
-
Survivor from to
Survivor 区有两块，一块称为from区，另一块为to区，这两个区是相对的，在发生一次Minor GC后，from区就会和to区互换。在发生Minor GC时，Eden区和Survivor from区会把一些仍然存活的对象复制进Survivor to区，并清除内存。Survivor to区会把一些存活得足够旧的对象移至年老代。
2、老年代：
老年代里存放的都是存活时间较久的，大小较大的对象，因此年老代使用标记整理算法。当年老代容量满的时候，会触发一次Major GC（full GC），回收年老代和年轻代中不再被使用的对象资源。
3、 永久代
在JDK8之前的HotSpot虚拟机中，类的这些“永久的”数据存放在一个叫做永久代的区域。永久代一段连续的内存空间，我们在JVM启动之前可以通过设置-XX:MaxPermSize的值来控制永久代的大小，32位机器默认的永久代的大小为64M，64位的机器则为85M。永久代的垃圾回收和老年代的垃圾回收是绑定的，一旦其中一个区域被占满，这两个区都要进行垃圾回收。但是有一个明显的问题，由于我们可以通过‑XX:MaxPermSize 设置永久代的大小，一旦类的元数据超过了设定的大小，程序就会耗尽内存，并出现内存溢出错误OutOfMemoryError(OOM)。这里值得注意的是，JDK8移除了永久代。
图3
总结一下：
- 一个对象实例化时，先去看伊甸园有没有足够的空间；
- 如果有，不进行垃圾回收，对象直接在伊甸园存储；
- 如果伊甸园内存已满，会进行一次minor gc；然后再进行判断伊甸园中的内存是否足够;
- 如果不足，则去看存活区的内存是否足够;如果内存足够，把伊甸园部分活跃对象保存在存活区，然后把对象保存在伊甸园。
- 如果内存不足，向老年代发送请求，查询老年代的内存是否足够；
- 如果老年代内存足够，将部分存活区的活跃对象存入老年代。然后把伊甸园的活跃对象放入存活区，对象依旧保存在伊甸园。
- 如果老年代内存不足，会进行一次full gc，之后老年代会再进行判断内存是否足够。如果足够，同上；如果不足，会抛出OutOfMemory Error。
需要注意的是，GC虽然可以进行内存空间的释放，但同时频繁的GC一定会影响性能，GC发生的频率越低，你的系统就越高效。
