Jvm垃圾收集器

一.GC收集的工具

　　1.Servial收集器

　　　　特色：歷史悠久，單線程收集，複製算法，，stop the world，收集新生代，簡單高效，專心收集，沒有線程切換開銷

　　　　　　　用在Client模式下是一個很是好的選擇。

　　2.ParNew收集器

　　　　特色：就是serial收集器的多線程版本，可控參數回收算法都與serial同樣，server模式下，新生代的首選

　　　　　　   在單核的狀況下，毫不會有serial收集的效果好，存在線程交互開銷。

　　3.Parallel Scavenge收集器

　　　特色：多線程，收集新生代，複製算法，注重吞吐量

　　　吞吐量：就是用戶執行代碼的時間比上cpu總執行時間。

　　　這個收集器提供了兩個參數精準控制控制吞吐量

　　　-xx：MaxGCPauseMillis最大的GC停頓時間

　　　-xx：GCTimeRatio直接設置吞吐量大小

　　　-xx：+UseAdapttiveSizePolicy開關參數

　　　一些新生代中Eden，survivor比例，晉升老年代的年齡等

　　　細節就能夠自動設置，這個自動調節策略仍是很優秀的，它是根據

　　　當前運行的監控信息，動態調節的。

　　　上面兩個參數並非很如意的

　　　舉例：即使最大停頓時間設置的很小，

　　　　　　那也是犧牲吞吐量或者新生代的空間換來的

　　4.Serial Old收集器

 　　　特色：老年代，單線程回收，標記-整理算法

　　　 用途：主要被用做Client模式下的虛擬機。

　　　　　　 server模式下：jdk1.5與Parallel Scavenge搭配使用

　　　　　　　　　　　　　做爲CMS的後備方案

　　

　　5.Parallel Old收集器

　　特色：Parallel Scavenge收集器的老年代版本，標記-整理算法，JDK1.6纔出現

　　　　　

　　　　配合Parallel Scavenge收集器使用。

　　6.CMS收集器

　　　特色：最短回收停頓時間，重視響應速度，帶給用戶高效體驗

　　　　　　標記-清除算法，老年代，四個步驟收集（相對複雜）

　　　四個收集步驟：

　　　　　　初始標記：簡單標記GCRoots能直接關聯到的對象（快）

　　　　　　併發標記：GC Roots Tracing(跟蹤)過程（慢）

　　　　　　從新標記：修正併發標記時用戶程序致使標記發生變化的那部分對象記錄

　　　　　　併發清除：就是併發狀況下而後清除。

　　　　　　初始標記，從新標記都會「stop the world」

　　  CMS三個缺點：

　　　　1.對CPU資源敏感，併發階段雖然不會致使用戶線程停頓，但會佔用cpu資源，致使變慢

　　　　　總吞吐量下降。CMS默認啓動的回收線程數是(CPU+3）/4，但CPU核數4個以上，併發

　　　　　回收只佔用25%，不足4個那就慘了，會佔用50%。那用戶線程就慘了喲。解決方法就是

　　　　　i-CMS搶佔式使線程交替，這樣用戶線程影響小點。（可是不推薦使用）

　　　　2.CMS沒法收集浮動垃圾。

　　　　　併發清理過程當中，用戶線程仍是在不斷生成垃圾，本次GC不能處理，只能等下GC。

　　　　　因此，老年代空間不能太滿才GC，要預留一些空間（68%），否則會產生的浮動垃圾沒

　　　　　地方存放，若是出現這種狀況，虛擬機就會啓動後備方案，臨時使用Serial Old收集器重

　　　　　新進行老年代的垃圾收集，這樣時間就會更長。這個預留的空間設置多大仍是看狀況的好。

　　　　3.這個標記-清除算法會產生大量的空間碎片，空間碎片過多就會沒法分配內存給大對象，CMS

　　　　   提供一個-xx：UseCompactAtFullCollection參數（享受完FullGC後，送一次空間碎片整理）

　　7.G1收集器（簡單介紹）

　　　　特色：標記-整理（不產生空間碎片），精準控制停頓，不犧牲吞吐量完成低停頓的內存回收

　　　　　　　G1將新生代，老年代劃分爲多個固定獨立區域，跟蹤區域中垃圾堆積程度，在後臺維護

　　　　　　　一個優先列表，每次根據容許的收集時間，優先回收最多的區域。區域的劃分及有優先級

　　　　　　　的區域回收，保證了G1收集器在有限的時間內能夠得到最高的收集效率。

 

　　到這裏基本就介紹完常接觸的幾種收集器了。

　　參考：深刻理解Java虛擬機