JVM之垃圾回收-垃圾收集器( 二 ) _内存碎片

为什么只有能与CMS收集器配合收集器
收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。
收集器关注点是吞吐量（如何高效率的利用CPU）。
CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。
所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。（吞吐量：CPU用于用户代码的时间/CPU总消耗时间的比值，即=运行用户代码的时间/(运行用户代码时间+垃圾收集时间) 。比如，虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99% 。）
运行示意图：
收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解的话，不进行手工优化，可以选择把内存管理优化交给虚拟机去完成。
特点应用场景设置参数
收集器提供两个参数用于精确控制吞吐量：
控制最大垃圾收集停顿时间
"-XX:MaxGCPauseMillis"
设置垃圾收集时间占总时间的比率
"-XX:GCTimeRatio"
设置垃圾收集时间占总时间的比率，0 < n < 100的整数；
相当于设置吞吐量大小；
垃圾收集执行时间占应用程序执行时间的比例的计算方法是： 1 / (1 + n)。
例如，选项-XX:=19，设置了垃圾收集时间占总时间的5% = 1/(1+19)；默认值是1% = 1/(1+99)，即n=99；
垃圾收集所花费的时间是年轻一代和老年代收集的总时间；
如果没有满足吞吐量目标，则增加代的内存大小以尽量增加用户程序运行的时间；
GC自适应的调节策略（GC ）
另外还有一个参数：
"-XX:+UseAdptiveSizePolicy"
开启这个参数后，就不用手工指定一些细节参数，如：
Old收集器
收集器的老年代版本，它同样是一个单线程收集器。
它主要有两大用途：一种用途是在JDK1.5以及以前的版本中与收集器搭配使用，另一种用途是作为CMS收集器的后备方案
特点应用场景Old收集器
收集器的老年代版本。
使用多线程和“标记-整理”算法。在注重吞吐量以及CPU资源的场合，都可以优先考虑收集器和 Old收集器。
在JDK1.6才有的。
特点应用场景设置参数
指定使用Parallel Old收集器:"-XX:+UseParallelOldGC"
CMS（ Mark Sweep）收集器
CMS（ Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常适合在注重用户体验的应用上使用。
特点
CMS是在JDK1.5推出的第一款真正意义上的并发（）收集器；
第一次实现了让垃圾收集线程与用户线程（基本上）同时工作；
应用场景CMS收集器运作过程
从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程可分为四个步骤：
重新标记：重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录（采用多线程并行执行来提升效率）；需要"Stop The World"，且停顿时间比初始标记稍长，但远比并发标记短；并发清除：开启用户线程，同时GC线程开始对为标记的区域做清扫，回收所有的垃圾对象；
由于整个过程耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作。