简单理解垃圾收集器

Serial收集器

    它的缺点是当它想要进行垃圾回收时，必须暂停用户的所有进程，即stop the world。到现在为止它依然是虚拟机运行在client模式下的默认年轻代收集器，与其他收集器相比，对于限定在单个cpu的运行环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾回收自然可以获得高效的单线程收集效率。

    Serial Old是它的年老代版本。它同样是一个单线程收集器，使用标记-整体的算法。这个收集器的主要意义也是被client模式下的虚拟机使用。在Server模式下，他有主要的两大用途，一个是在JDK1.5以及以前的版本中与Parallel Scanvenge收集器搭配使用，另一个就是作为CMS收集器的后备预案，在并发收集发生Concurrent ModeFailure的时候使用。

    通过指定-UseSerialGC参数，使用Serial+Serial Old的串行收集器组合进行垃圾回收。

 

ParNew收集器

    它是Serial收集器年轻代的多线程实现，注意在进行垃圾回收时依旧是stop the world，只是相对serial时它会运行多条进程进行垃圾回收。

    ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百的保证能超越Serial收集器。当然，随着可以使用的CPU的数量增加，它对于GC时系统资源的利用还是很有好处的。它默认开启的收集线程数与CPU的数量相同，在CPU非常多（譬如32个，现在CPU动辄4核加超线程，服务器超过32个逻辑CPU的情况越来越多了）的环境下，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

    -UserParNewGC，打开此开关后，使用ParNew+Serial Old的收集器组合进行内存回收，这样年轻代使用并行收集器，年老代使用串行收集器。

 

Parallel Scanvenge收集器

    Parallel是采用复制算法的多线程年轻代垃圾回收器，似乎与ParNew收集器有很多相同的地方。但是这个收集器所关注的目标是吞吐量。所谓吞吐量就是CPU用于运行用户代码的时间和CPU总消耗时间的比值，也就是（吞吐量=运行用户代码的时间/（运行用户代码的时间+垃圾回收的时间））停顿时间越短就越适合需要与用户交互的程序。良好的响应速度能够提升用户的体验；而高吞吐量则可以最高效率的利用cpu时间，尽快的完成程序的运算任务，主要适合后台运算而不需要太多交互的任务。

     Parallel Old收集器是Parallel Scavenge收集器的老年代版本，采用多线程和”标记－整理”算法。这个收集器是在jdk1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是如果新生代Parallel Scavenge收集器，那么老年代除了Serial Old(PS MarkSweep)收集器外别无选择。由于单线程的老年代Serial Old收集器在服务端应用性能上的”拖累“，即使使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，又因为老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合”给力“。直到Parallel Old收集器出现后，”吞吐量优先“收集器终于有了比较名副其实的应用祝贺，在注重吞吐量及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。

    -UseParallelGC: 虚拟机运行在Server模式下的默认值，打开此开关后，使用Parallel Scavenge + Serial Old的收集器组合进行内存回收。-UseParallelOldGC: 打开此开关后，使用Parallel Scavenge + Parallel Old的收集器组合进行垃圾回收

 

CMS（Concurrent mark swep）收集器

    是一个比较重要的收集器，现在应用非常广泛。CMS是一种获取最短回收停顿时间为目标的收集器，这使得他很适合于和用户交互的业务。从名字可以看出它是基于标记清除算法的，四个步骤：

    初始标记（initial mark）；并发标记（concurrent mark）；重新标记（remark）；并发清除（concurrent sweep）。

    初始标记和重新标记还是会stop the world，但是在耗费时间更长的并发标记和并发清除两个阶段都可以和用户进程同时工作。

    不过由于CMS收集器是基于标记清除算法实现的，会导致有大量的空间碎片产生，在为大对象分配内存的时候，往往会出现年老代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前开启一次full gc为了解决这个问题，CMS收集器默认提供了一个-xx:+UseCMSCompactAtFullCollection收集开关参数（默认就是开启的），用于在CMS收集器进行Full gc完开启内存碎片的合并整理过程，内存整理的过程是无法并发的，这样内存碎片问题倒是没有了，但是停顿时间不得不变长，虚拟机还提供了另一个参数：-xx:CMSFullGCSBeforeCopaction参数用于设置执行多少次不压缩的Full gc后跟着来一次压缩，默认为0，也就是每次进入Full gc 都进行碎片整理。

    不幸的是，它作为年老代收集器，无法与jdk1.4中已经存在的年轻代收集器Parallel Scavenge配合工作，所以在jdk1.5中使用cms收集年老代时，年轻代只能选择ParNew或者Serial收集器的其中一个。ParNew是使用-xx:+UseConcMarkSweepGC选项启用CMS收集器后的默认年轻代收集器，也可以使用-xx:+UseParNewGC选项来强制指定它。

CMS算法的几个常用参数

    UseCMSInitatingOccupancyOnly:表示只在到达阈值的时候，才进行CMS回收，为了减少第二次暂停时间，通过-xx:+CMSParallelRemarkEnabled开启并行remark。如果remark时间还是过长，可以开启-xx:+CMSScavengeBeforeRemark,强制remark之前开启一次minor gc，减少remark的暂停时间，但是在remark之后也立即开启一次minor gc。

    CMS默认启动的回收线程数目是（parallelGCThreads+3）/4，并且也可以通过-xx:+ParallelCMSThreads来设定，其中-xx:ParallelGCThreads代表的年轻代的并发收集线程数目。

    CMSClassUnloadingEnabled:允许对类元数据进行回收。

    CMSInitatingPermOccupancyFraction：当永久区占用率达到这一百分比后，启动 CMS 回收 (前提是-XX:+CMSClassUnloadingEnabled 激活了)。
    CMSIncrementalMode：使用增量模式，比较适合单 CPU。
    UseCMSCompactAtFullCollection参数可以使 CMS 在垃圾收集完成后，进行一次内存碎片整理。内存碎片的整理并不是并发进行的。
    UseFullGCsBeforeCompaction：设定进行多少次 CMS 垃圾回收后，进行一次内存压缩。

 

一些建议
对于Native Memory:

• 使用了NIO或者NIO框架（Mina/Netty）
• 使用了DirectByteBuffer分配字节缓冲区
• 使用了MappedByteBuffer做内存映射

由于Native Memory只能通过FullGC回收，所以除非你非常清楚这时真的有必要，否则不要轻易调用System.gc()。

另外为了防止某些框架中的System.gc调用（例如NIO框架、Java RMI），建议在启动参数中加上-XX:+DisableExplicitGC来禁用显式GC。这个参数有个巨大的坑，如果你禁用了System.gc()，那么上面的3种场景下的内存就无法回收，可能造成OOM，如果你使用了CMS GC，那么可以用这个参数替代：-XX:+ExplicitGCInvokesConcurrent。

此外除了CMS的GC，其实其他针对old gen的回收器都会在对old gen回收的同时回收young gen。

 

G1收集器

G1收集器是一款面向服务端应用的垃圾收集器。HotSpot团队赋予它的使命是在未来替换掉JDK1.5中发布的CMS收集器。与其他GC收集器相比，G1具备如下特点：

1. 并行与并发：G1能更充分的利用CPU，多核环境下的硬件优势来缩短stop the world的停顿时间。
2. 分代收集：和其他收集器一样，分代的概念在G1中依然存在，不过G1不需要其他的垃圾回收器的配合就可以独自管理整个GC堆。
3. 空间整合：G1收集器有利于程序长时间运行，分配大对象时不会无法得到连续的空间而提前触发一次GC。
4. 可预测的非停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

在使用G1收集器时，Java堆的内存布局和其他收集器有很大的差别，它将这个Java堆分为多个大小相等的独立区域，虽然还保留新生代和老年代的概念，但是新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。

虽然G1看起来有很多优点，实际上CMS还是主流。

与GC相关的常用参数

除了上面提及的一些参数，下面补充一些和GC相关的常用参数：

• -Xmx: 设置堆内存的最大值。
• -Xms: 设置堆内存的初始值。
• -Xmn: 设置新生代的大小。
• -Xss: 设置栈的大小。
• -PretenureSizeThreshold: 直接晋升到老年代的对象大小，设置这个参数后，大于这个参数的对象将直接在老年代分配。
• -MaxTenuringThrehold: 晋升到老年代的对象年龄。每个对象在坚持过一次Minor GC之后，年龄就会加1，当超过这个参数值时就进入老年代。
• -UseAdaptiveSizePolicy: 在这种模式下，新生代的大小、eden 和 survivor 的比例、晋升老年代的对象年龄等参数会被自动调整，以达到在堆大小、吞吐量和停顿时间之间的平衡点。在手工调优比较困难的场合，可以直接使用这种自适应的方式，仅指定虚拟机的最大堆、目标的吞吐量 (GCTimeRatio) 和停顿时间 (MaxGCPauseMills)，让虚拟机自己完成调优工作。
• -SurvivorRattio: 新生代Eden区域与Survivor区域的容量比值，默认为8，代表Eden: Suvivor= 8: 1。
• -XX:ParallelGCThreads：设置用于垃圾回收的线程数。通常情况下可以和 CPU 数量相等。但在 CPU 数量比较多的情况下，设置相对较小的数值也是合理的。
• -XX:MaxGCPauseMills：设置最大垃圾收集停顿时间。它的值是一个大于 0 的整数。收集器在工作时，会调整 Java 堆大小或者其他一些参数，尽可能地把停顿时间控制在 MaxGCPauseMills 以内。
• -XX:GCTimeRatio:设置吞吐量大小，它的值是一个 0-100 之间的整数。假设 GCTimeRatio 的值为 n，那么系统将花费不超过 1/(1+n) 的时间用于垃圾收集。