先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

　　缺点：1 回收了被标记的对象后，由于未经过整理，所以导致很多内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集机制。

                  2 效率问题，标记和清除两个过程效率都不高 。

　　将可用的内存按容量划分为大小相等的两块（from，to），每次只是用其中一块（总有一块是空的【to区域】）。当这块的内存用完了，就将还存活着的对象复制到另外一块上面，然后把已使用过的内存空间一次清理完。　　

　　一般不需要按照1:1的比例来划分内存空间，而是将一块内存分为一块较大的Eden空间和两块较小的Survivor空间（From Survivor 和 To Survivor），每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另一块Survivor空间上，最后清理掉Eden和刚才使用过的Survivor空间。

　　HotSpot虚拟机默认Eden和Survivor大小的比例是8:1，也就是每次新生代中可用的内存空间为整个新生代容量的90%，只有10%的内存时被浪费的。

　　缺点：浪费内存空间，如果对象存活率较高时要执行较多的复制操作，效率降低。

       优点：不产生内存碎片

 

　　　　图解：有一块内存区域是空的，一般是to区域。保留区域每次回收后都因为复制的时候让他们变为连续的地址空间，所有不产生内存碎片。

 

　　复制收集算法在对象存活率较高的时候就要进行较多的复制操作，效率将会变低。

 

　　　　图解：由于标记后继续整理，可以很明显的看出未使用的地址空间都是连续的，不会产生内存碎片。

 

　　当前商业虚拟机的垃圾收集都采用“分代收集”算法，这种算法并没有什么新的思想，只是根据对象存活周期的不同将内存划分为几块。一般是把java堆分为新生代和老年代。

　　在新生代，每次垃圾收集时都会发现有大批对象死去，只有少量存活，那就使用 复制算法，只需要付出少量存活对象的复制成本就可以完成收集。

　　而老年代中因为对象存活率较高，没有额外空间进行分配担保，就必须使用 标记 - 清除  或者 标记 - 整理 算法来进行回收。

 

补充：分代划分内存介绍

　　　　整个JVM内存总共划分为三代：年轻代（Young Generation）、年老代（Old Generation）、（JDK 1.7 没了）持久代（Permanent Generation）

　　　　1、年轻代：所有新生成的对象首先都放在年轻代内存中。年轻代的目标就是尽可能快速的手机掉那些生命周期短的对象。年轻代内存分为一块较大的Eden空间和两块较小的Survior空间，每次使用Eden和其中的一块Survior.当回收时，将Eden和Survior中还存活的对象一次性拷贝到另外一块Survior空间上，最后清理Eden和刚才用过的Survior空间。

　　　　2、年老代：在年轻代经历了N次GC后，仍然存活的对象，就会被放在老年代中。因此可以认为老年代存放的都是一些生命周期较长的对象。

　　　　3、持久代：基本固定不变，用于存放静态文件，例如Java类和方法。持久代对GC没有显著的影响。持久代可以通过-XX:MaxPermSize=<N>进行设置。

三  内存分配和回收策略

3.1 Jvm怎么判断对象可以回收了？

　　对象没有引用

　　作用域发生未捕获异常

　　程序在作用域正常执行完毕

　　程序执行了System.exit()

　　程序发生意外终止（被杀线程等）

在Java程序中不能显式的分配和注销缓存，因为这些事情JVM都帮我们做了，那就是GC。

有些时候我们可以将相关的对象设置成null 来试图显示的清除缓存，但是并不是设置为null 就会一定被标记为可回收，有可能会发生逃逸。

将对象设置成null 至少没有什么坏处，但是使用System.gc() 便不可取了，使用System.gc() 时候并不是马上执行GC操作，而是会等待一段时间，甚至不执行，而且System.gc() 如果被执行，会触发Full GC ，这非常影响性能。

3.2 JVM GC什么时候执行？

eden区空间不够存放新对象的时候，执行Minor GC。升到老年代的对象大于老年代剩余空间的时候执行Full GC，或者小于的时候被HandlePromotionFailure 参数强制Full GC 。调优主要是减少 Full GC 的触发次数，可以通过 NewRatio 控制新生代转老年代的比例，通过MaxTenuringThreshold 设置对象进入老年代的年龄阀值（后面会介绍到）。

3.3 JVM分别对新生代和老年代采用不同的垃圾回收机制

在 Java 中，堆被划分成两个不同的区域：新生代 ( Young )、老年代 ( Old )。新生代 ( Young )又被划分为

三个区域：Eden、From Survivor、To Survivor。

这样划分的目的是为了使 JVM 能够更好的管理堆内存中的对象，包括内存的分配以及回收。

堆的内存模型大致为：

从图中可以看出： 堆大小 =新生代 + 老年代。其中，堆的大小可以通过参数 –Xms、-Xmx 来指定。

新生代（Young generation）：绝大多数最新被创建的对象都会被分配到这里，由于大部分在创建后很快变得不可达，很多对象被创建在新生代，然后“消失”。对象从这个区域“消失”的过程我们称之为：Minor GC 。

老年代（Old generation）：对象没有变得不可达，并且从新生代周期中存活了下来，会被拷贝到这里。其区域分配的空间要比新生代多。也正由于其相对大的空间，发生在老年代的GC次数要比新生代少得多。对象从老年代中消失的过程，称之为：Major GC 或者 Full GC。

（JDK7后 没了）持久代（Permanent generation）也称之为 方法区（Method area）：用于保存类常量以及字符串常量。注意，这个区域不是用于存储那些从老年代存活下来的对象，这个区域也可能发生GC。发生在这个区域的GC事件也被算为 Major GC 。只不过在这个区域发生GC的条件非常严苛，必须符合以下三种条件才会被回收：

1、所有实例被回收

2、加载该类的ClassLoader 被回收

3、Class 对象无法通过任何途径访问（包括反射）

可能我们会有疑问：

如果老年代的对象需要引用新生代的对象，会发生什么呢？

为了解决这个问题，老年代中存在一个 card table ，它是一个512byte大小的块。所有老年代的对象指向新生代对象的引用都会被记录在这个表中。当针对新生代执行GC的时候，只需要查询 card table 来决定是否可以被回收，而不用查询整个老年代。这个 card table 由一个write barrier 来管理。write barrier给GC带来了很大的性能提升，虽然由此可能带来一些开销，但完全是值得的。

新生代空间的构成与逻辑

为了更好的理解GC，我们来学习新生代的构成，它用来保存那些第一次被创建的对象，它被分成三个空间：

· 一个伊甸园空间（Eden）

· 两个幸存者空间（Fron Survivor、To Survivor）

默认新生代空间的分配：Eden : Fron : To = 8 : 1 : 1

老年代空间的构成与逻辑

老年代空间的构成其实很简单，它不像新生代空间那样划分为几个区域，它只有一个区域，里面存储的对象并不像新生代空间绝大部分都是朝闻道，夕死矣。这里的对象几乎都是从Survivor 空间中熬过来的，它们绝不会轻易的狗带。因此，Full GC（Major GC）发生的次数不会有Minor GC 那么频繁，并且做一次Major GC 的时间比Minor GC 要更长（约10倍）。

Java 中的堆也是 GC收集垃圾的主要区域。GC 分为两种：Minor GC、FullGC ( 或称为 Major GC )。

Minor GC 是发生在新生代中的垃圾收集动作，所采用的是复制算法。新生代几乎是所有 Java 对象出生的地方，即 Java 对象申请的内存以及存放都是在这个地方。Java 中的大部分对象通常不需长久存活，具有朝生夕灭的性质。当一个对象被判定为 "死亡" 的时候，GC 就有责任来回收掉这部分对象的内存空间。新生代是 GC 收集垃圾的频繁区域。当对象在 Eden ( 包括一个 Survivor 区域，这里假设是 from 区域 ) 出生后，在经过一次 Minor GC后，如果对象还存活，并且能够被另外一块 Survivor 区域所容纳(上面已经假设为 from 区域，这里应为 to 区域，即 to 区域有足够的内存空间来存储 Eden 和 from 区域中存活的对象 )，则使用复制算法将这些仍然还存活的对象复制到另外一块 Survivor 区域 ( 即 to 区域 ) 中，然后清理所使用过的 Eden以及 Survivor 区域 ( 即from 区域 )，并且将这些对象的年龄设置为1，以后对象在 Survivor 区每熬过一次 Minor GC，就将对象的年龄 + 1，当对象的年龄达到某个值时 ( 默认是 15 岁，可以通过参数 -XX:MaxTenuringThreshold 来设定)，这些对象就会成为老年代。但这也不是一定的，对于一些较大的对象 (即需要分配一块较大的连续内存空间 ) 则是直接进入到老年代。

Full GC 是发生在老年代的垃圾收集动作，所采用的是标记-清除算法。现实的生活中，老年代的人通常会比新生代的人"早死"。堆内存中的老年代(Old)不同于这个，老年代里面的对象几乎个个都是在 Survivor 区域中熬过来的，它们是不会那么容易就 "死掉" 了的。因此，Full GC发生的次数不会有 Minor GC 那么频繁，并且做一次 Full GC 要比进行一次 Minor GC 的时间更长。

另外，标记-清除算法收集垃圾的时候会产生许多的内存碎片 (即不连续的内存空间 )，此后需要为较大的对象分配内存空间时，若无法找到足够的连续的内存空间，就会提前触发一次 GC 的收集动作。

3.4 JVM参数选项

下面只列举其中的几个常用和容易掌握的配置选项

-Xms	初始堆大小。如：-Xms256m
-Xmx	最大堆大小。如：-Xmx512m
-Xmn	新生代大小。通常为 Xmx 的 1/3 或 1/4。新生代 = Eden + 2 个 Survivor 空间。实际可用空间为 = Eden + 1 个 Survivor，即 90%
-Xss	JDK1.5+ 每个线程堆栈大小为 1M，一般来说如果栈不是很深的话， 1M 是绝对够用了的。
-XX:NewRatio	新生代与老年代的比例，如 –XX:NewRatio=2，则新生代占整个堆空间的1/3，老年代占2/3
-XX:SurvivorRatio	新生代中 Eden 与 Survivor 的比值。默认值为 8。即 Eden 占新生代空间的 8/10，另外两个 Survivor 各占 1/10
-XX:PermSize	永久代(方法区)的初始大小
-XX:MaxPermSize	永久代(方法区)的最大值
-XX:+PrintGCDetails	打印 GC 信息

3.5 jvm调优问题--full gc太过频繁该如何处理？

1 full gc频繁说明old区很快满了。

2 如果是一次full gc后，剩余对象不多。那么说明你eden区设置太小，导致短生命周期的对象进入了old区。

3 如果一次full gc后，old区回收率不大，那么说明old区太小。

参考

《深入理解java虚拟机》

http://hllvm.group.iteye.com/group/topic/38223#post-248757

http://www.iteye.com/topic/1119491

http://www.importnew.com/1993.html