jvm的垃圾回收就是对jvm中不用的对象进行释放，将其所占的内存进行回收。
首先介绍下jvm的内存，jvm的内存结构如下图所示：
JVM 内存包含如下几个部分：
Heap(堆) Memory 存放Java对象
Non-Heap Memory 存放类加载信息和其它meta-data
Other 存放JVM 自身代码等
JVM启动时，就已经保留了固定的内存空间给Heap内存，这部分内存并不一定都会被JVM使用，但是可以确定的是这部分保留的内存不会被其他进程使用。这部分内存大小由 -Xmx参数指定。而另一部分内存在JVM启动时就分配给JVM，作为JVM的初始Heap内存使用。影响这个的参数是 -Xms。
默认空余堆内存小于40%时，JVM 就会增大堆直到-Xmx的最大限制，可以由-XX:MinHeapFreeRatio指定。
默认空余堆内存大于70%时，JVM 会减少堆直到-Xms的最小限制，可以由-XX:MaxHeapFreeRatio指定。
可以通过-XX:MaxPermSize设置Non-Heap大小.
GC 的年代划分
图：Java堆中各代分布
Young：主要是用来存放新生的对象。
Old：主要存放应用程序中生命周期长的内存对象。
Permanent：是指内存的永久保存区域，主要存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域. 它和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。
-Xms指定的值比-Xmx的小，那么两者的差值就是Virtual内存值。随着程序的运行，Eden区、 Tenured区和Perm区会逐渐使用保留的Virtual空间。
JVM内存模型中Heap区分两大块，一块是 NEW Generation,另一块是Old Generation. 在NewGeneration中，有一个叫Eden的空间，主要是用来存放新生的对象，还有两个Survivor Spaces（from,to），它们的大小总是一样，它们用来存放每次垃圾回收后存活下来的对象。在OldGeneration中，主要存放应用程序中生命周期长的内存对象。在NewGeneration块中，垃圾回收一般用Copying的算法，速度快。每次GC的时候，存活下来的对象首先由Eden 拷贝到某个Survivor Space, 当Survivor Space空间满了后, 剩下的live对象就被直接拷贝到OldGeneration中去。因此，每次GC后，Eden内存块会被清空。在OldGeneration块中，垃圾回收一般用mark-compact的算法，速度慢些，但减少内存要求.
2．JVM 使用的GC算法是什么？
分代收集。
即将内存分为几个区域，将不同生命周期的对象放在不同区域里；
在GC收集的时候，频繁收集生命周期短的区域(Young area)；
比较少的收集生命周期比较长的区域(Old area)；
基本不收集的永久区(Perm area)。
还有个Permanent Generation，主要用来放JVM自己的反射对象，比如类对象和方法对象等。关于这个区，它还提供String pool，看下面的例子：
String first = "abc";
String second = new String ("abc");
第一个对象存贮在Permanent Generation，而第二个对象存储在Heap里面。所以：
String s = "abc"; String p = "abc";
对象s和p指向同一个对象，这样效率大大提高。
JVM垃圾回收简介：
垃圾回收分多级，0级为全部(Full)的垃圾回收，会回收OLD段中的垃圾；1级或以上为部分垃圾回收，只会回收NEW中的垃圾，内存溢出通常发生于OLD段或Perm段垃圾回收后，仍然无内存空间容纳新的Java对象的情况。
3．GC 和 Full GC 有什么区别？
GC（或Minor GC）：收集生命周期短的区域(Young area)。
Full GC （或Major GC）：收集生命周期短的区域(Young area)和生命周期比较长的区域(Old area)。
他们的收集算法不同，所以使用的时间也不同。 GC 效率也会比较高，我们要尽量减少 Full GC 的次数。当显示调用System.gc() 时，gc does a full collection(both young generation and tenured generation).
4．Minor GC后，Eden是空的吗？
是的，Minor GC会把Eden中的所有活的对象都移到Survivor区域中，如果Survivor区中放不下，那么剩下的活的对象就被移到Old generation 中。
8. 常见的内存泄露错误
很多开发人员都碰到过java.lang.OutOfMemoryError的错误。这种错误又分两种：java.lang.OutOfMemoryError: Java heap space和java.lang.OutOfMemoryError: PermGen space。引起这种错误的原因可能是程序问题，也可能是是JVM参数配置问题引起的。若是参数问题，前者可以同过配置-Xms和-Xmx参数来设置，而后者可以通过配置 -XX:PermSize和-XX:MaxPermSize来设置。
内存申请过程如下：
JVM 会试图为相关Java对象在Eden中初始化一块内存区域
当Eden空间足够时，内存申请结束。否则到下一步
JVM 试图释放在Eden中所有不活跃的对象（这属于1或更高级的垃圾回收）,释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区
Survivor区被用来作为Eden及OLD的中间交换区域，当OLD区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区
当OLD区空间不够时，JVM 会在OLD区进行完全的垃圾收集（0级）
完全垃圾收集后，若Survivor及OLD区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现”out of memory错误”
垃圾收集的目的在于清除不再使用的对象。gc（Garbage Collector）通过确定对象是否被活动对象引用来确定是否收集该对象。gc首先要判断该对象是否是时候可以收集。两种常用的方法是引用计数和对象引用遍历。
1.引用计数
引用计数存储对特定对象的所有引用数，也就是说，当应用程序创建引用以及引用超出范围时，jvm必须适当增减引用数。当某对象的引用数为0时，便可以进行垃圾收集。
2.对象引用遍历
早期的jvm使用引用计数，现在大多数jvm采用对象引用遍历。对象引用遍历从一组对象开始，沿着整个对象图上的每条链接，递归确定可到达 （reachable）的对象。如果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集。在对象遍历阶段，gc必须记住哪些对象可以到 达，以便删除不可到达的对象，这称为标记（marking）对象。
下一步，gc要删除不可到达的对象。删除时，有些gc只是简单的扫描堆栈，删除未标记的未标记的对象，并释放它们的内存以生成新的对象，这叫做清除 （sweeping）。这种方法的问题在于内存会分成好多小段，而它们不足以用于新的对象，但是组合起来却很大。因此，许多gc可以重新组织内存中的对 象，并进行压缩（compact），形成可利用的空间。
为此，gc需要停止其他的活动活动。这种方法意味着所有与应用程序相关的工作停止，只有gc运行。结果，在响应期间增减了许多混杂请求。另外，更复杂的gc不断增加或同时运行以减少或者清除应用程序的中断。有的gc使用单线程完成这项工作，有的则采用多线程以增加效率。
几种垃圾回收机制
1.标记－清除收集器
这种收集器首先遍历对象图并标记可到达的对象，然后扫描堆栈（应该是扫描堆吧，因为java对象在堆中。堆栈是栈的一种吧？）以寻找未标记对象并释放它们的内存。这种收集器一般使用单线程工作并停止其他操作。
2.标记－压缩收集器
有时也叫标记－清除－压缩收集器，与标记－清除收集器有相同的标记阶段。在第二阶段，则把标记对象复制到堆栈的新域中以便压缩堆栈。这种收集器也停止其他操作。
3.复制收集器
这种收集器将堆栈分为两个域，常称为半空间。每次仅使用一半的空间，jvm生成的新对象则放在另一半空间中。gc运行时，它把可到达对象复制到另一半空间，从而压缩了堆栈。这种方法适用于短生存期的对象，持续复制长生存期的对象则导致效率降低。
4.增量收集器
增量收集器把堆栈分为多个域，每次仅从一个域收集垃圾。这会造成较小的应用程序中断。
5.分代收集器
这种收集器把堆栈分为两个或多个域，用以存放不同寿命的对象。jvm生成的新对象一般放在其中的某个域中。过一段时间，继续存在的对象将获得使用期并转入更长寿命的域中。分代收集器对不同的域使用不同的算法以优化性能。
6.并发收集器
并发收集器与应用程序同时运行。这些收集器在某点上（比如压缩时）一般都不得不停止其他操作以完成特定的任务，但是因为其他应用程序可进行其他的后台操作，所以中断其他处理的实际时间大大降低。
7.并行收集器
并行收集器使用某种传统的算法并使用多线程并行的执行它们的工作。在多cpu机器上使用多线程技术可以显著的提高java应用程序的可扩展性。
参考：http://blog.csdn.net/autofei/article/details/7456213
http://developer.51cto.com/art/200607/29278.htm
http://blog.csdn.net/winniepu/article/details/4829087