JVM垃圾回收算法你都知道嗎？

原創 java金融 java金融 3月9日

---

怎麼判斷對象"已死"？

1.引用計數法

不能解決對象循環依賴的問題。所以通常不用這種。

2.可達性分析算法。

GCRoots 不可達時 對象死，採用這個。

垃圾收集算法

1.標記清除算法

1.標記、清除階段效率不高。

2.標記清除以後會產生大量不連續的碎片，致使分配較大的對象時候，沒法找到足夠的連續內存。

2.複製算法

1.兩塊相同的內存空間，一塊使用，一塊空閒，致使空間浪費。不存在碎片問題。

3.記整理算法

1.標記過程與"標記清除算法"同樣，整理過程是讓全部存活對象都往一端移動，而後直接清理掉邊界之外的內存。

4.分代收集算法。

把對象進行分代，新生代和來年代。

總結

新生代通常用複製算法，老年代通常用標記整理或者標記清除算法。

垃圾收集器

1. Serial收集器
2. 做用於新生代
3. 單線程收集
4. 採用複製算法
5. 開啓方式：-XX:+UseSerialGC
6. Client模式下的默認新生代收集器。進行垃圾收集時，必須Stop the world，直到它收集結束
7. ParNew收集器.
8. 做用於新生代。
9. 多線程收集
10. 採用複製算法
11. -XX:+UseParNewGC-XX:ParallelGCThreans=2（2指定垃圾收集的線程數).
12. Server模式下的默認新生代收集器
13. ParallelScavenge收集器
14. 新生代.
15. 多線程
16. 複製算法
17. -XX:MaxGCPauseMillis控制最大垃圾收集時間 -XX:GCTimeRatio 控制吞吐量大小
18. 吞吐量優先收集器目標：控制吞吐量吞吐量=運行用戶代碼時間/(運行用戶代碼時間+垃圾收集時間)吞吐量越高說明CPU時間利用率越高。
19. SerialOld收集器
20. 老年代
21. 單線程
22. 標記整理算法
23. 這個收集器的主要意義也是在於給Client模式下的虛擬機使用。若是在Server模式下，主要兩大用途：1.在JDK1.5以及以前的版本中與ParallelScavenge收集器搭配使用。2.做爲CMS收集器的後備預案，在併發收集發生Concurrent Mode Failure時使用
24. ParallelOld收集器
25. 老年代
26. 多線程
27. 標記整理
28. ParallelOld是ParallelScavenge收集器的老年代版本。這個收集器在1.6中才開始提供。在JDK1.5以及以前的版本中，Parallel Scavenge+Serial Old（單線程），沒法充分利用多CPU的處理能力。1.6以後，終於有了名副其實的"吞吐量優先"收集器組合：Parallel Scavenge + Parallel Old。
29. CMS
30. 老年代
31. 多線程
32. 標記清除算法
33. -XX:+UseConcMarkSweepGC新生代使用了PartNew

CMS在老年代的整個過程分爲4個步驟：

1.初始標記stop the word 僅僅標記GC Roots能直接關聯到的對象，速度很快

2.併發標記進行GCRoots Tracing的過程（判斷對象是否仍在使用中）和用戶線程一塊兒工做。3 .從新標記stop the word 修正併發標記階段因用戶程序繼續運行而致使標記發生變更的那一部分標記記錄。此階段比初始標記階段稍長，但遠比並發標記階段的時間短。

4.併發清除 和用戶線程一塊兒工做。

G1 收集器

內存組成：Eden、 Survivor、 Old、 Humongous

內存變化：字符串內部池，已經在JDK7中從永久代中移除，JDK1.7中，存儲在永久代的部分數據就已經轉移到了JavaHeap或者是NativeHeap。但永久代仍存在於JDK1.7中，並沒徹底移除，譬如符號引用(Symbols)轉移到了native heap；字面量(internedstrings)轉移到了javaheap；類的靜態變量(classstatics)轉移到了java heap持久代也移動到了普通的堆內存空間中，改成元空間 。

大對象的分配

1 TLAB(Thread Local Allocation Buffer)線程本地分配緩衝區

2 Eden區中分配

3 Humongous區分配

GC模式

G1提供了兩種Young GC和Mixed GC，兩種都是Stop The World(STW)