所謂的并發回收算法即是指垃圾回收器與應用程序能夠交替工作，
并發回收 器其實也會暫停，
但是時間非常短，
它并不會在從開始回收尋找、標記、清楚、壓縮或拷貝等方式過程完全暫停服務，
它發現有幾個時間比較長，一個就是標記，因 為這個回收一般面對的是老年代，
這個區域一般很大，而一般來說絕大部分對象應該是活著的，
所以標記時間很長，
還有一個時間是壓縮，但是壓縮并不一定非要每 一次做完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 適合最小化中斷或停頓時間的場景
