系统的性能和吞吐量息息相关的
cpu是分到了 应用程序还是gc
cpu分到应用程序中 越多 吞吐量越高，比如一个网站，很多用户请求。
CMS 收集器
conccurrent Mark Sweep 并发的标记清除
标记清除算法
垃圾回收期与 应用程序交替执行。停顿时间少
停顿减少了， 并发阶段会降低吞吐量减少
它是一个老年代的 收集器(新生代采用 ParNew)
-XX：+UseConCMarkSweepGC
初始标记和重新标记 依然会产生停顿的。
CMS（Concurrent Mark Sweep,并行标记-清除）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的java应用集中在互联网或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来良好的体验。
整个过程分为四步：
1）初始标记，仅仅是标记一个垃圾收集的根节点所能直接关联到的对象，速度很快。
2）并发标记，并发标记阶段就是进行垃圾收集根节点跟踪的过程
3）重新标记则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。
4）并发清除
缺点：
1，CMS收集器对CPU资源非常敏感，CMS默认启动的回收线程数是(CPU数量+3)/4.当CPU的数量小于4的时候，CMS对用户程序的影响就变得很大。
2）CMS收集器无法处理浮动垃圾，可能出现Concurrent Mode Failure失败而导致另一次Full GC的产生。由于在CMS并发清理阶段用户线程还在运行着，CMS无法在档次收集中处理掉，只好等待下一次GC时再清理掉。这一部分垃圾就是浮动垃圾。由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留足够多的内存空间给用户线程使用。因此CMS收集器不能像其他收集器那样等到老年代几乎被完全填满再收集，需要预留一部分空间提供并发收集时程序使用。
3，有大量的空间碎片，影响内存的使用率，导致过早Full GC,浪费CPU时间。
为什么不使用标记-压缩 ？ 因为清理的时候，应用程序依然在执行。
CMS 当应用程序不断申请内存，肯能造成CMS收集失败
因为CMS 标记-清除，在清除后也需要整理一下 可用碎片的内存。
