参考资料：

http://www.cnblogs.com/zhguang/p/3257367.html

概要：

Java GC机制主要完成3件事：确定哪些内存需要回收，确定什么时候需要执行GC，如何执行GC。

从4个方面学习Java GC机制，

1，内存是如何分配的；

2，如何保证内存不被错误回收(即：哪些内存需要回收)；

3，在什么情况下执行GC以及执行GC的方式；

4，如何监控和优化GC机制。

程序计数器也是所有JVM内存区域中唯一一个没有定义OutOfMemoryError的区域。

一般来说，一个Java的引用访问涉及到3个内存区域：JVM栈，堆，方法区。

通过直接指针访问的方式中，reference中存储的就是对象在堆中的实际地址，在堆中存储的对象信息中包含了在方法区中的相应类型数据。这种方法最大的优势是速度快，在HotSpot虚拟机中用的就是这种方式。

GC回收：

Java内存分配和回收的机制概括的说，就是：分代分配，分代回收。对象将根据存活的时间被分为：年轻代(Young Generation)、年老代(Old Generation)、永久代(Permanent Generation，也就是方法区)

在年轻代，进行的垃圾回收方法是著名的“停止-复制”清理法；

年轻代(Young Generation)：对象被创建时，内存的分配首先发生在年轻代(大对象可以直接被创建在年老代)，大部分的对象在创建后很快就不再使用，因此很快变得不可达，于是被年轻代的GC机制清理掉(IBM的研究表明，98%的对象都是很快消亡的)，这个GC机制被称为Minor GC或叫Young GC。注意，Minor GC并不代表年轻代内存不足，它事实上只表示在Eden区上的GC。

年轻代上的内存分配是这样的，年轻代可以分为3个区域：Eden区(伊甸园，亚当和夏娃偷吃禁果生娃娃的地方，用来表示内存首次分配的区域，再贴切不过)和两个存活区(Survivor 0 、Survivor 1)。内存分配过程为(来源于《成为JavaGC专家part I》，http://www.importnew.com/1993.html)：

绝大多数刚创建的对象会被分配在Eden区，其中的大多数对象很快就会消亡。Eden区是连续的内存空间，因此在其上分配内存极快；

当Eden区满的时候，执行Minor GC，将消亡的对象清理掉，并将剩余的对象复制到一个存活区Survivor0(此时，Survivor1是空白的，两个Survivor总有一个是空白的)；

此后，每次Eden区满了，就执行一次Minor GC，并将剩余的对象都添加到Survivor0；

当Survivor0也满的时候，将其中仍然活着的对象直接复制到Survivor1，以后Eden区执行Minor GC后，就将剩余的对象添加Survivor1(此时，Survivor0是空白的)。

当两个存活区切换了几次(HotSpot虚拟机默认15次，用-XX:MaxTenuringThreshold控制，大于该值进入老年代，但这只是个最大值，并不代表一定是这个值)之后，仍然存活的对象(其实只有一小部分，比如，我们自己定义的对象)，将被复制到老年代。

从上面的过程可以看出，Eden区是连续的空间，且Survivor总有一个为空。经过一次GC和复制，一个Survivor中保存着当前还活着的对象，而Eden区和另一个Survivor区的内容都不再需要了，可以直接清空，到下一次GC时，两个Survivor的角色再互换。因此，这种方式分配内存和清理内存的效率都极高，这种垃圾回收的方式就是著名的“停止-复制(Stop-and-copy)”清理法(将Eden区和一个Survivor中仍然存活的对象拷贝到另一个Survivor中)，这不代表着停止复制清理法很高效，其实，它也只在这种情况下高效，如果在老年代采用停止复制，则挺悲剧的。

年老代(Old Generation)：对象如果在年轻代存活了足够长的时间而没有被清理掉(即在几次Young GC后存活了下来)，则会被复制到年老代，年老代的空间一般比年轻代大，能存放更多的对象，在年老代上发生的GC次数也比年轻代少。当年老代内存不足时，将执行Major GC，也叫 Full GC。

可以使用-XX:+UseAdaptiveSizePolicy开关来控制是否采用动态控制策略，如果动态控制，则动态调整Java堆中各个区域的大小以及进入老年代的年龄。

如果对象比较大(比如长字符串或大数组)，Young空间不足，则大对象会直接分配到老年代上(大对象可能触发提前GC，应少用，更应避免使用短命的大对象)。用-XX:PretenureSizeThreshold来控制直接升入老年代的对象大小，大于这个值的对象会直接分配在老年代上。

可能存在年老代对象引用新生代对象的情况，如果需要执行Young GC，则可能需要查询整个老年代以确定是否可以清理回收，这显然是低效的。解决的方法是，年老代中维护一个512 byte的块——”card table“，所有老年代对象引用新生代对象的记录都记录在这里。Young GC时，只要查这里即可，不用再去查全部老年代，因此性能大大提高。