jvm垃圾回收器

1、串行收集器
最古老、最稳定
效率高
可能会产生较长的停顿
-XX:+UseSerialGC
   - 新生代、老年代使用串行回收
   - 新生代复制算法
   - 老年代标记-压缩

2、ParNew
-XX:+UseParNewGC
   新生代并行
   老年代串行
- Serial收集器新生代的并行版本
-复制算法
- 多线程，需要多核支持
- XX:ParallelGCThreads 限制线程数量

3、Parallel收集器
类似ParNew
新生代复制算法
老年代标记-压缩
更加关注吞吐量
-XX:+UseParallelGC
    使用Parallel收集器+老年代串行
-XX:+UseParallelOldGC
    使用Parallel收集器+老年代并行

其他参数
-XX:MaxGCPauseMills
  最大停顿时间，单位毫秒
  GC尽力保证回收时间不超过设定值
-XX:GCTimeRatio
   0-100的取值范围
   垃圾收集时间占总时间的比
   默认99，即最大允许1%时间做GC
这两个参数是矛盾的。因为停顿时间和吞吐量不可能同时调优

4、CMS收集器
-XX:+UseConcMarkSweepGC
  Concurrent Mark Sweep 并发标记清除
  标记-清除算法（与标记-压缩相比）
  并发阶段会降低吞吐量
  老年代收集器（新生代使用ParNew）

CMS运行过程比较复杂，着重实现了标记的过程，可分为
  初始标记
      根可以直接关联到的对象
      速度快
  并发标记（和用户线程一起）
      主要标记过程，标记全部对象
  重新标记
      由于并发标记时，用户线程依然运行，因此在正式清理前，再做修正
  并发清除（和用户线程一起）
      基于标记结果，直接清理对象

特点
  尽可能降低停顿
  会影响系统整体吞吐量和性能
    比如，在用户线程运行过程中，分一半CPU去做GC，系统性能在GC阶段，反应速度就下降一半
  清理不彻底
        因为在清理阶段，用户线程还在运行，会产生新的垃圾，无法清理
  因为和用户线程一起运行，不能在空间快满时再清理
    -XX:CMSInitiatingOccupancyFraction设置触发GC的阈值
        如果不幸内存预留空间不够，就会引起concurrent mode failure

=========================================================================

查看JDK垃圾回收器版本：java -XX:+PrintCommandLineFlags -version

-XX:+UseSerialGC：JDK 4和5的默认串行垃圾收集器。

-XX:+UseParallelGC：JDK 6和7的新生代并行老年代串行垃圾收集器。

 -XX:+UseG1GC：JDK 8的新生代老年代并行垃圾收集器。