所谓的并发回收算法即是指垃圾回收器与应用程序能够交替工作，
并发回收 器其实也会暂停，
但是时间非常短，
它并不会在从开始回收寻找、标记、清楚、压缩或拷贝等方式过程完全暂停服务，
它发现有几个时间比较长，一个就是标记，因 为这个回收一般面对的是老年代，
这个区域一般很大，而一般来说绝大部分对象应该是活着的，
所以标记时间很长，
还有一个时间是压缩，但是压缩并不一定非要每 一次做完GC都去压缩的，
而拷贝呢一般不会用在老年代，
所以暂时不考虑；所以他们想出来的办法就是：
**第一次短暂停机是将所有对象的根指针找到，这个非常容 易找到，而且非常快速，
找到后，此时GC开始从这些根节点标记活着的节点（这里可以采用并行），
然后待标记完成后，此时可能有新的 内存申请以及被抛弃（java本身没有内存释放这一概念）
，此时JVM会记录下这个过程中的增量信息，而对于老年代来说，必须要经过多次在 survivor倒腾后才会进入老年代，**
所以它在这段时间增量一般来说会非常少，
而且它被释放的概率前面也说并不大（JVM如果不是完全做Cache，自 己做pageCache而且发生概率不大不小的pageout和pagein是不适合的）
；JVM根据这些增量信息快速标记出内部的节点，也是非常快速 的，就可以开始回收了，
由于需要杀掉的节点并不多，所以这个过程也非常快，
压缩在一定时间后会专门做一次操作，
有关暂停时间在Hotspot版本，也就是 SUN的jdk中都是可以配置的，
当在指定时间范围内无法回收时，JVM将会对相应尺寸进行调整，如果你不想让它调整，在设置各个区域的大小时，
就使用定 量，而不要使用比例来控制；
当采用并发回收算法的时候，
一般对于老年代区域，不会等待内存小于10%左右的时候才会发起回收，
因为并发回收是允许在回收的 时候被分配，那样就有可能来不及了，所以并发回收的时候，J
VM可能会在68%左右的时候就开始启动对老年代GC了。
Serial GC 适合最小化地使用内存和并行开销的场景、Parallel GC 适合最大化应用程序吞吐量的场景、CMS GC 适合最小化中断或停顿时间的场景
