垃圾收集器
【收集算法的选择】
新生代，由于只有少量的对象能存活下来，所以选用“复制算法”，只需要付出少量存活对象的复制成本。
老年代，由于对象的存活率高，没有额外的空间分担，就必须使用“标记-清除”或“标记-整理”算法。
那么老年代也使用标记-复制策略吧？当然不行！老年代中的对象可不像新生代中的，每次回收都会清除掉大部分。如果贸然采用复制的策略，老年代的回收效率可想而知。
【收集器具体的实现种类】
（1）新生代上的GC实现
Serial：单线程的收集器，只使用一个线程进行收集，并且收集时会暂停其他所有工作线程（Stop the world）。它是Client模式下的默认新生代收集器。
ParNew：Serial收集器的多线程版本。在单CPU甚至两个CPU的环境下，由于线程交互的开销，无法保证性能超越Serial收集器。
Parallel Scavenge：也是多线程收集器，与ParNew的区别是，它是吞吐量优先收集器。吞吐量=运行用户代码时间/(运行用户代码+垃圾收集时间)。另一点区别是配置-XX:+UseAdaptiveSizePolicy后，虚拟机会自动调整Eden/Survivor等参数来提供用户所需的吞吐量。我们需要配置的就是内存大小-Xmx和吞吐量GCTimeRatio。
（2）老年代上的GC实现
Serial Old：Serial收集器的老年代版本。
Parallel Old：Parallel Scavenge的老年代版本。此前，如果新生代采用PS GC的话，老年代只有Serial Old能与之配合。现在有了Parallel Old与之配合，可以在注重吞吐量及CPU资源敏感的场合使用了。
CMS：采用的是标记-清除而非标记-整理，是一款并发低停顿的收集器。但是由于采用标记-清除，内存碎片问题不可避免。可以使用-XX:CMSFullGCsBeforeCompaction设置执行几次CMS回收后，跟着来一次内存碎片整理。
【触发：何时开始GC？】
Minor GC（新生代回收）的触发条件比较简单，Eden空间不足就开始进行Minor GC回收新生代。而Full GC（老年代回收，一般伴随一次Minor GC）则有几种触发条件：
（1）老年代空间不足
（2）PermSpace空间不足
（3）统计得到的Minor GC晋升到老年代的平均大小大于老年代的剩余空间
这里注意一点：PermSpace并不等同于方法区，只不过是Hotspot JVM用PermSpace来实现方法区而已，有些虚拟机没有PermSpace而用其他机制来实现方法区。
【对象的空间分配和晋升】
（1）对象优先在Eden上分配
（2）大对象直接进入老年代
虚拟机提供了-XX:PretenureSizeThreshold参数，大于这个参数值的对象将直接分配到老年代中。因为新生代采用的是标记-复制策略，在Eden中分配大对象将会导致Eden区和两个Survivor区之间大量的内存拷贝。
（3）长期存活的对象将进入老年代
对象在Survivor区中每熬过一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁）时，就会晋升到老年代中。
【收集器选择综述】
新生代的垃圾收集器有：Serial收集器、ParNew收集器、Parallel Scavenge收集器
老年代的垃圾收集器有：Serial Old收集器、Parallel Old收集器、CMS收集器、G1收集器
下面我们来分别介绍一下这些垃圾收集器
Serial收集器/Serial Old收集器
Serial收集器/Serial Old收集器，是单线程的，使用“复制”算法。当它工作时，必须暂停其它所有工作线程。特点：简单而高效。对于运行在Client模式下的虚拟机来说是一个很好的选择。
ParNew收集器
ParNew收集器，是Serial收集器的多线程版。是运行在Server模式下的虚拟机中首选的新生代收集器。除了Serial收集器外，目前只有它能与CMS收集器配合工作。
Parallel Scavenge收集器/Parallel Old收集器
Parallel Scavenge收集器，也是使用“复制”算法的、并行的多线程收集器。这些都和ParNew收集器一样。但它关注的是吞吐量（CPU用于运行用户代码的时间与CPU总消耗时间的比值），而其它收集器（Serial/Serial Old、ParNew、CMS）关注的是垃圾收集时用户线程的停顿时间。
Parallel Old收集器是Parallel Scavenge收集器的老年代版本。
CMS收集器
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器，使用“标记-清除”算法。
CMS收集器分4个步骤进行垃圾收集工作：
1、初始标记 2、并发标记 3、重新标记 4、并发清除
其中“初始标记”、“重新标记”是需要暂停其它所有工作线程的。
G1收集器
G1（Garbage First）收集器，基于“标记-整理”算法，可以非常精确地控制停顿。
【CMS】
Concurrent Mark Sweep：并发标记清除。老年代回收算法。
【并发收集，低停顿：最短停顿时间】【响应速度】
初始标记：全停，短暂停
并发标记：长时间，用户线程一起
重新标记：全停
并发清除：用户线程一起
【缺点】
消耗25%CPU资源。默认启动的回收线程数。
无法处理浮动垃圾。
产生空间碎片。
【适合】 应用中存在较多长生命周期的对象。减少full GC发生。
【G1收集器】
标记-整理算法。
Garbage First：服务器风格，多处理器机器上占用大量内存的应用。
2000区，1M-32M，6G堆内存，0.5秒以下停顿。
【特点】
多CPU并发与并行。
分代收集。
空间整合无碎片。
可预测的停顿时间模型。
多个等大小独立Region，优先列表，价值最大的Region优先回收。
【Region划分内存空间】【有优先级的区域回收】
引用问题：用Remember Set避免全堆扫描。记录引用。
初始标记，并发标记，最终标记，筛选回收。
【G1新生代收集】http://www.importnew.com/15311.html
被 圈起的绿色部分为新生代的区域(region)，经过Young GC后存活的对象被复制到一个或者多个区域空闲中，这些被填充的区域将是新的新生代；当新生代对象的年龄(逃逸过一次Young GC年龄增加１)已经达到某个阈值(ParNew默认15)，被复制到老年代的区域中。
回收过程是停顿的(STW,Stop-The-Word);回收完成之后根据Young GC的统计信息调整Eden和Survivor的大小，有助于合理利用内存，提高回收效率。
回收的过程多个回收线程并发收集。
【Remembered Set概念】
G1 收集器中，Region之间的对象引用以及其他收集器中的新生代和老年代之间的对象引用是使用Remembered Set来避免扫描全堆。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序对Reference类型数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之间(在分代中例子中就是检查是否老年代中的对象引用了新生 代的对象)，如果是便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set中。当内存回收时，在GC根节点的枚举范围加入Remembered Set即可保证不对全局堆扫描也不会有遗漏。
G1 虽然保留了CMS关于代的概念，但是代已经不是物理上连续区域，而是一个逻辑的概念。在标记过程中，每个区域的对象活性都被计算，在回收时候，就可以根据 用户设置的停顿时间，选择活性较低的区域收集，这样既能保证垃圾回收，又能保证停顿时间，而且也不会降低太多的吞吐量。Remark阶段新算法的运用，以 及收集过程中的压缩，都弥补了CMS不足。引用Oracle官网的一句话：“G1 is planned as the long term replacement for the Concurrent Mark-Sweep Collector (CMS)”。
Serial收集器/Serial Old
新生代：复制算法。老年代：标记-整理算法。
暂停其他所有工作线程。运行在Client模式下的虚拟机。
ParNew收集器/Serial Old
新生代：复制算法。老年代：标记-整理算法。
目前，除了Serial收集器，只有ParNew能与CMS收集器配合工作。
Parallel Scavenge收集器
复制算法。
关注点：达到可控制的吞吐量。“吞吐量优先收集器”
Serial Old收集器
Serial的老年代版本。使用“标记-整理算法”。
Parallel Old收集器
和Parallel Scavenge收集器合作。
【Minor GC与Full GC】
虚拟机给每个对象定义了一个对象年龄（Age）计数器。
如果对象在 Eden 出生并经过第一次 Minor GC 后仍然存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间中，并将对象年龄设为 1。
对象在 Survivor 区中每熬过一次 Minor GC，年龄就增加 1 岁，当它的年龄增加到一定程度（默认为 15 岁）时，就会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。
在执行机制上JVM提供了串行GC(SerialGC)、并行回收GC(ParallelScavenge)和并行GC(ParNew)
1)串行GC
在整个扫描和复制过程采用单线程的方式来进行，适用于单CPU、新生代空间较小及对暂停时间要求不是非常高的应用上，是client级别默认的GC方式，可以通过-XX:+UseSerialGC来强制指定
2)并行回收GC
在整个扫描和复制过程采用多线程的方式来进行，适用于多CPU、对暂停时间要求较短的应用上，是server级别默认采用的GC方式，可用-XX:+UseParallelGC来强制指定，用-XX:ParallelGCThreads=4来指定线程数
3)并行GC
与旧生代的并发GC配合使用
旧生代的GC：
旧生代与新生代不同，对象存活的时间比较长，比较稳定，因此采用标记(Mark)算法来进行回收，所谓标记就是扫描出存活的对象，然后再进行回收未被标记的对象，回收后对用空出的空间要么进行合并，要么标记出来便于下次进行分配，总之就是要减少内存碎片带来的效率损耗。在执行机制上JVM提供了串行GC(SerialMSC)、并行GC(parallelMSC)和并发GC(CMS)，具体算法细节还有待进一步深入研究。
以上各种GC机制是需要组合使用的，指定方式由下表所示：
【JVM1.6 GC详解】http://www.cnblogs.com/ggjucheng/p/3977384.html
前言
JVM GC是JVM的内存回收算法，调整JVM GC(Garbage Collection)，可以极大的减少由于GC工作，而导致的程序运行中断方面的问题，进而适当的提高Java程序的工作效率。但是调整GC是以个极为复杂的过程，所以我们要了解JVM内存组成，回收算法，对象分配机制。
JVM 堆内存组成
Java堆由Perm区和Heap区组成，Heap区由Old区和New区（也叫Young区）组成，New区由Eden区、From区和To区（Survivor）组成。
Eden区用于存放新生成的对象。Eden中的对象生命不会超过一次Minor GC。
Survivor Space 有两个，存放每次垃圾回收后存活的对象，即图的S0和S1。
Old Generation Old区，也称老生代，主要存放应用程序中生命周期长的存活对象
JVM初始分配的内存由-Xms指定，JVM最大分配的内存由-Xmx指定。默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制。因此服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小。
-XX:NewRatio= 参数可以设置Young与Old的大小比例，-server时默认为1:2,如果太小，会使大对象直接分配到old区去，增大major collections的执行的次数，影响性能。
-XX:SurvivorRatio= 参数可以设置Eden与Survivor的比例，默认为1:8，Survivio大了会浪费，如果小了的话，会使一些大对象在做minor gc时，直接从eden区潜逃到old区，让old区的gc频繁。这个参数保持默认就好了，一般情况下，对性能影响不大。
启动后可通过jmap –heap [pid]查看。
由于堆的整体大小是固定的，young generation越大，tenured generation越小，越会增加major collections的执行的次数。所以最佳的选择是由对象的生命周期分布所决定。
New区的Collector
1、 串行GC（Serial Copying）
client模式下的默认GC方式，也可使用-XX:+UseSerialGC指定。
2、 并行回收GC（Parallel Scavenge）
server模式下的默认GC方式，也可用-XX:+UseParallelGC强制指定。
采用PS时，默认情况下JVM会在运行时动态调整Eden:S0:S1的比例，如果不希望自动调整可以使用-XX:-UseAdaptiveSizePolicy参数，内存分配和回收的算法和串行相同，唯一不同仅在于回收时为多线程。
3、 并行GC（ParNew）
CMS GC时默认采用，也可以采用-XX:+UseParNewGC指定。内存分配、回收和PS相同，不同的仅在于会收拾会配合CMS做些处理。
Old区的几种Collector
1、 串行GC（Serial MSC）
client模式下的默认GC方式，可通过-XX:+UseSerialGC强制指定。每次进行全部回收，进行Compact，非常耗费时间。
2、 并行GC（Parallel MSC）(备注，吞吐量大，但是gc的时候响应很慢)
server模式下的默认GC方式，也可用-XX:+UseParallelGC=强制指定。可以在选项后加等号来制定并行的线程数。
3、 并发GC（CMS）线上环境采用的GC方式，也就是Realese环境的方式。(备注，响应比并行gc快很多，但是牺牲了一定的吞吐量)
使用CMS是为了减少GC执行时的停顿时间，垃圾回收线程和应用线程同时执行，可以使用-XX:+UseConcMarkSweepGC=指定使用，后边接等号指定并发线程数。CMS每次回收只停顿很短的时间，分别在开始的时候（Initial Marking），和中间（Final Marking）的时候，第二次时间略长。具体CMS的过程可以参考相关文档。JStat中将Initial Mark和Remark都统计成了FGC。
CMS一个比较大的问题是碎片和浮动垃圾问题（Floating Gabage）。碎片是由于CMS默认不对内存进行Compact所致，可以通过-XX:+UseCMSCompactAtFullCollection。
总体来讲，Old区的大小较大，垃圾回收算法较费时间，导致较长时间的应用线程停止工作，而且需要进行Compact，所以不应该出现较多Major GC。Major GC的时间常常是Minor GC的几十倍。JVM内存调优的重点，减少Major GC 的次数，因为为Major GC 会暂停程序比较长的时间，如果Major GC 的次数比较多，意味着应用程序的JVM内存参数需要进行调整。
JVM内存分配策略
1. 对象优先在Eden分配
如果Eden区不足分配对象，会做一个minor gc，回收内存，尝试分配对象，如果依然不足分配，才分配到Old区。
2.大对象直接进入老年代
大对象是指需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串及数组，虚拟机提供了一个-XX:PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代中分配。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存拷贝（新生代采用复制算法收集内存）。PretenureSizeThreshold参数只对Serial和ParNew两款收集器有效，
3.长期存活的对象将进入老年代
在经历了多次的Minor GC后仍然存活：在触发了Minor GC后，存活对象被存入Survivor区在经历了多次Minor GC之后，如果仍然存活的话，则该对象被晋升到Old区。
虚拟机既然采用了分代收集的思想来管理内存，那内存回收时就必须能识别哪些对象应当放在新生代，哪些对象应放在老年代中。为了做到这点，虚拟机给每个对象定义了一个对象年龄（Age）计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并将对象年龄设为1。对象在Survivor区中每熬过一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁）时，就会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold来设置。
4.动态对象年龄判定
为了能更好地适应不同程序的内存状况，虚拟机并不总是要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
5.Minor GC后Survivor空间不足就直接放入Old区
6.空间分配担保
在发生Minor GC时，虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小，如果大于，则改为直接进行一次Full GC。如果小于，则查看HandlePromotionFailure设置是否允许担保失败；如果允许，那只会进行Minor GC；如果不允许，则也要改为进行一次Full GC。大部分情况下都还是会将HandlePromotionFailure开关打开，避免Full GC过于频繁。
JVM GC组合方式
如何监视GC
1.概览监视gc。
jmap -heap [pid] 查看内存分布
jstat -gcutil [pid] 1000 每隔1s输出java进程的gc情况
2.详细监视gc。
在jvm启动参数，加入-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:./gc.log。
输入示例:
[GC [ParNew: 11450951K->1014116K(11673600K), 0.8698830 secs] 27569972K->17943420K(37614976K), 0.8699520 secs] [Times: user=11.28 sys=0.82, real=0.86 secs]
表示发生一次minor GC，ParNew是新生代的gc算法，11450951K表示eden区的存活对象的内存总和，1014116K表示回收后的存活对象的内存总和，11673600K是整个eden区的内存总和。0.8699520 secs表示minor gc花费的时间。
27569972K表示整个heap区的存活对象总和，17943420K表示回收后整个heap区的存活对象总和，37614976K表示整个heap区的内存总和。
[Full GC [Tenured: 27569972K->16569972K(27569972K), 180.2368177 secs] 36614976K->27569972K(37614976K), [Perm : 28671K->28635K(28672K)], 0.2371537 secs]
表示发生了一次Full GC，整个JVM都停顿了180多秒，输出说明同上。只是Tenured: 27569972K->16569972K(27569972K)表示的是old区，而上面是eden区。
更多可以参考 阿里分享的ppt sunjdk1.6gc.pptx
