1.标记-清除算法
这种收集器首先遍历对象图并标记可到达的对象，然后扫描堆栈以寻找未标记对象并释放它们的内存。这种收集器一般使用单线程工作并停止其他操作。
- 复制算法
这种收集器将堆栈分为两个域，常称为半空间。每次仅使用一半的空间，虚拟机生成的新对象则放在另一半空间中。垃圾回收器运行时，它把可到达对象复制到另一半空间，没有被复制的的对象都是不可达对象，可以被回收。这种方法适用于短生存期的对象，持续复制长生存期的对象由于多次拷贝，导致效率降低。缺点是只有一半的虚拟机空间得到使用。
- 标记-整理算法
- 分代收集算法
在实际中用到的回收器都是这几种算法的组合，比如从VisualVM中看到的内存是这样的（需要明白各部分都是怎样互相配合的）：
整体上来看是分代收集算法，而S0、S1这两部分可以看做是标记-整理算法。
年轻代对象因为生命周期短，每次有约90%以上对象的占用空间被回收，采用“复制-清除”算法清理，具体过程：将新生代分为一个Eden空间和两个Survivor空间，默认Eden空间和Survivor空间的比例为8:1，对象分配到Eden和其中一个Survivor空间，回收时将存活的对象复制到另一个Survivor空间，然后将Eden空间和先前使用的Survivor空间清理。
老年代因对象生命周期较长，每次回收只有少部分对象没清理，如果使用“复制-清理”算法的话需要额外预留更多的空闲空间用于复制生存对象，
（ 例如，100M的老年代占用空间 每次能回收50% ，那么他需要预留50M的空间 内存使用上不经济 ）
所以回收时使用“标记-整理”算法。
那么第三个问题：常见的CMS垃圾回收器的执行流程是怎样的？
1. 初始标记：GC Roots直接关联的对象。
2. 并发标记：Root Tracing。
3. 重新标记：修复由于程序运行导致标记产生变动。
4. 并发清除
具体如下图所示：
可以看到只有在初始标记和重新标记的时候才需要Stop The World，其他都是和用户线程一起执行，不要以为这就完美了，并行执行的过程会消耗掉一些CPU资源。
Garbage-First，面向服务器的垃圾收集器，主要针对配置多处理器及大容量内存的机器，以极高概率满足GC停顿时间要求的同时，还具备高吞吐量性能特征。
可以像CMS收集器一样，GC操作与应用的线程一起并发执行
紧凑的空闲内存区且没有很长的GC停顿时间
需要可预测的GC暂停耗时
不想牺牲太多吞吐量性能
启动后不需要请求更大的Java堆
G1是一款压缩型的收集器，G1通过有效的压缩完全避免了对细微空闲内存的分配，不用依赖于regions，大大简化了收集器，还消除了潜在的内存碎片问题。
G1执行垃圾回收的处理方式与CMS相似. G1在全局标记阶段(global marking phase)并发执行, 以确定堆内存中哪些对象是存活的。标记阶段完成后,G1就可以知道哪些heap区的empty空间最大。它会首先回收这些区,通常会得到大量的自由空间. 这也是为什么这种垃圾收集方法叫做Garbage-First(垃圾优先)的原因。顾名思义, G1将精力集中放在可能布满可收回对象的区域, 可回收对象(reclaimable objects)也就是所谓的垃圾. G1使用暂停预测模型(pause prediction model)来达到用户定 义的目标暂停时间,并根据目标暂停时间来选择此次进行垃圾回收的heap区域数量
被G1标记为适合回收的heap区将使用转移(evacuation)的方式进行垃圾回收. G1将一个或多个heap区域中的对象拷贝到其 他的单个区域中,并在此过程中压缩和释放内存. 在多核CPU上转移是并行执行的(parallel on multi-processors), 这样能减少 停顿时间并增加吞吐量. 因此,每次垃圾收集时, G1都会持续不断地减少碎片, 并且在用户给定的暂停时间内执行. 这比以前 的方法强大了很多. CMS垃圾收集器(Concurrent Mark Sweep,并发标记清理)不进行压缩. ParallelOld 垃圾收集只对整个堆 执行压缩,从而导致相当长的暂停时间。
需要强调的是, G1并不是一款实时垃圾收集器(real-time collector). 能以极高的概率在设定的目标暂停时间内完成,但不保证 绝对在这个时间内完成。 基于以前收集的各种监控数据, G1会根据用户指定的目标时间来预估能回收多少个heap区. 因此, 收集器有一个相当精确的heap区耗时计算模型,并根据该模型来确定在给定时间内去回收哪些heap区.
注意 G1分为两个阶段: 并发阶段(concurrent, 与应用线程一起运行, 如: 细化 refinement、标记 marking、清理 cleanup) 和 并行阶段(parallel, 多线程执行, 如: 停止所有JVM线程, stop the world). 而 FullGC(完整垃圾收集)仍然是单线程的, 但如果进 行适当的调优,则应用程序应该能够避免 full GC。
S Concurrent Mark Sweep并发标记清理收集器，回收年老代内存。
吞吐量 应用花在非GC上的时间百分比
GC负荷 与吞吐量相反，指应用花在GC上的时间百分比
暂停时间 应用花在GC stop-the-world 的时间
GC频率 顾名思义
Footprint 一些资源大小的测量，比如堆的大小
反应速度 从一个对象变成垃圾道这个对象被回收的时间
一个交互式的应用要求暂停时间越少越好，然而，一个非交互性的应用，当然是希望GC负荷越低越好。
一个实时系统对暂停时间和GC负荷的要求，都是越低越好。
一个嵌入式系统当然希望Footprint越小越好。
整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
1. 堆大小设置
JVM 中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制。32位系统下，一般限制在1.5G~2G；64为操作系统对内存无限制。我在Windows Server 2003 系统，3.5G物理内存，JDK5.0下测试，最大可设置为1478m。
2. 典型设置 java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xmx3550m：设置JVM最大可用内存为3550M。
-Xms3550m：设置JVM促使内存为3550m。
此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
-Xmn2g：设置年轻代大小为2G。
-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。
更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。
但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。
java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -
XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。
设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，
则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6
-XX:MaxPermSize=16m:设置持久代大小为16m。
-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，
则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。
如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，
这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。
3. 参数信息
JVM提供了大量命令行参数，打印信息，供调试使用。主要有以下一些：
· -XX:+PrintGC 输出形式：[GC 118250K->113543K(130112K), 0.0094143 secs]
[Full GC 121376K->10414K(130112K), 0.0650971 secs]
· -XX:+PrintGCDetails 输出形式：
[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs]
· -XX:PrintHeapAtGC:打印GC前后的详细堆栈信息
· -Xloggc:filename:与上面几个配合使用，把相关日志信息记录到文件以便分析。
· -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
· -XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。
并行收集线程数。
· -XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。
· -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
· -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)
· -Xloggc:filename
· -XX:+UseSerialGC:设置串行收集器
· -XX:+UseParallelGC:设置并行收集器
· -XX:+UseParalledlOldGC:设置并行年老代收集器
· -XX:+UseConcMarkSweepGC:设置并发收集器
· -Xms:初始堆大小
· -Xmx:最大堆大小
· -XX:NewSize=n:设置年轻代大小
· -XX:NewRatio=n:设置年轻代和年老代的比值。
如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4
· -XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。
如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5
· -XX:MaxPermSize=n:设置持久代大小
1. 年轻代大小选择
· 响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
· 吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。
2. 年老代大小选择
· 并发垃圾收集信息
· 持久代并发收集次数
· 传统GC信息
· 花在年轻代和年老代回收上的时间比例
· 响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：减少年轻代和年老代花费的时间，一般会提高应用的效率
· 吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。
3. 较小堆引起的碎片问题
因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：
· -XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。
· -XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩
GC打印时间: [垃圾回收类型回收时间: [收集器名称: 年轻代回收前占用大小->年轻代回收后占用大小(年轻代当前容量),
年轻代局部GC时JVM暂停处理的时间] 堆空间GC前占用的空间->堆空间GC后占用的空间(堆空间当前容量)
,GC过程中JVM暂停处理的时间]。
垃圾回收类型：分为GC和Full GC.
GC一般为堆空间某个区发生了垃圾回收，
Full GC基本都是整个堆空间及持久代发生了垃圾回收，通常优化的目标之一是尽量减少GC和Full GC的频率。
收集器名称：一般都为收集器的简称或别名，通过收集器名称基本都能判断出那个区发生了GC。
代码执行
把Java源码丢给JVM肯定是不能执行的，需要先用javac编译成class文件才行，那么第一个问题：class文件的结构是怎样的？
· 常量池
· 访问标志
· 类索引、父类索引和接口索引
· 字段表
· 方法表
· 属性表
虚拟机规范并没有规定在什么时候要加载类，但是规定了在遇到new、反射、父类、Main的时候需要初始化完成。
JVM将类加载过程划分为三个步骤：装载、链接和初始化。
装载（Load）：装载过程负责找到二进制字节码并加载至JVM中，JVM通过类的全限定名（com.bluedavy. HelloWorld）及类加载器（ClassLoaderA实例）完成类的加载；
链接（Link）：链接过程负责对二进制字节码的格式进行校验、初始化装载类中的静态变量及解析类中调用的接口、类；
初始化（Initialize）：执行类中的静态初始化代码、构造器代码及静态属性的初始化。
解释执行的好处是下载后启动速度快，但是缺点也非常明显：运行速度慢。
JIT正是用来解决这个问题的，能够将多次调用的方法、多次执行的循环体编译成本地代码。
优化是个很好玩的题目，记得在参加一次变成比赛的时候用gcc -O3编译之后的代码把printf()都没输出了。。在JIT中比较常见的优化手段有：
在HotSpot虚拟机中，对象在内存中存储的布局可以分为对象头包括两部分信息，第一部分
任何对象的finalize()方法都只会被系统自动调用一次，如果对象面临下一次回收，它的finalize()方法不会被再次执行。反对使用原因：代价高昂，不确定性大，如果发生死循环可能导致整个内存回收系统崩溃。
回收方法区（HotSpot虚拟机中的永久代）：很多人认为方法去是没有垃圾收集的
主要回收两部分内容：废弃敞亮和无用的类
怎样的类可以被回收：
- 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例；
- 加载该类的ClassLoader已经被回收
- 该类对应的java.lang.Class对象没有在任何地方被引用，无法再任何地方通过反射访问该类的方法。
