1. 什麼是垃圾？
要確認一個對象是否爲垃圾，可以從以下兩個算法進行判斷。
1.1 引用計數法
只要應用程序中持有該對象的引用，也就是該對象的引用計數不爲0，就說明它不是垃圾。反之如果沒有任何引用指針對其引用就說明是 垃圾。
注：這種算法有一個很明顯的弊端，那就是兩個對象中相互引用時，則不會被回收
1.2 可達性分析法
1.2.1 通過GC Root的對象，開始向下尋找，看某個對象是否可達。
1.2.2 能作爲GC Root: 類加載器、Thread、虛擬機棧的本地變量表、static成員、常量引用、本地方法棧的變量等。
1.2.3 具體的有：
虛擬機棧（棧幀中的本地變量表）中引用的對象。
方法區中類靜態屬性引用的對象。
方法區中常量引用的對象。
本地方法棧中JNI（即一般說的Native方法）引用的對象。
2. 什麼是垃圾回收器，怎麼回收垃圾？
2.1 垃圾回收器就是對JVM內存空間的無用對象的銷燬並回收其佔用的內存空間的一種機制。
2.2 什麼時候進行垃圾回收？
GC是由JVM自動完成的，根據JVM系統環境而定，所以時機是不確定的。當然，我們可以手動進行垃圾回收，比如調 用System.gc()方法通知 JVM進行一次垃圾回收，但是具體什麼時刻運行也無法控制。也就是說System.gc()只是通知要回 收，什麼時候回收由JVM決定。
根據垃圾回收機制反推回來看就是：Eden區或者S區不夠用了、Old區不夠用了、方法區不夠用了或者System.gc()方 法 的調用會引起垃圾回收。
2.3 垃圾怎麼回收-回收算法
2.3.1 標記-清除
掃描內存空間並標記出要回收的對象，再對標記的對象進行回收，比較耗時。同時這種算法會造成很多空間碎 片、太多的空間碎片可能
導致後面需要分配較大對象時，找不到夠大的連續內存而提前觸發GC。
2.3.2 標記-整理
標記過程仍然與"標記-清除"算法一樣，但是後續步驟不是直接對可回收對象進行清理，而是讓所有存活的對象都 向一端移動，然後直接清理掉端邊界以外的內存。
2.3.3 標記-複製
將內存劃分爲兩塊相等的區域，每次只使用其中一塊，當其中一塊內存使用完了，就將還存活的對象複製到另外 一塊上面，然後把已經使用過的內存空間一次清除掉，缺點就是空間利用率低。
2.4 分代回收算法
2.4.1 新生代：適用標記複製算法，因爲新生代的對象大多是朝生夕死的，存活率低，複製效率高
2.4.2 老年代：適用標記清除和標記整理算法，因爲老年代的對象存活率高，使用複製算法效率反而更低，而且這種算 法需要浪費一半的內存空間，非常不適合在老年代中使用。
3. 有哪些垃圾回收器？
3.1 JVM中的垃圾回收器圖覽：
注：JDK11後引入了Zero GC，感興趣的可以瞭解一下。
3.2 Serial
一種單線程收集器，不僅僅意味着它只會使用一個CPU或者一條收集線程去完成垃圾收集工作，更重要的是其在進行垃圾收集的時候需要暫停其他線程。
3.2.1 Serial優缺點：簡單高效，擁有很高的單線程收集效率，但收集過程需要暫停應用線程。
3.2.2 算法：複製算法
3.2.3 應用：Client模式下的默認新生代垃圾收集器。
3.3 Serial Old
一種單線程收集器，執行過程和Serial一樣。Serial Old是應用在老年代的收集器。採用“標記-整理算法”。
3.4 ParNew
一種多線程收集器，和Serial相比不同的就是採用多線程收集罷了。
3.4.1 算法：複製算法
3.4.2 ParNew優缺點：在多CPU時效率比Serial高，單核時比Serial效率差。
3.4.3 應用：Server模式下的默認新生代垃圾收集器
3.5 Parallel Scavenge
一種並行的多線程收集器，適用於新生代。Parallel Scavenge更關注系統的吞吐量。
3.6 Parallel Old
是 Parallel Scavenge老年代版本，採用標記整理算法，同樣關注系統的吞吐量。
3.7 CMS
CMS是適用老年代的垃圾回收器，採用“標記-清除”算法。同時它採用“併發標記”和“併發整理”的工作機制使得在這兩個個過程中可以和其他應用線程共同工作，降低了回收停頓時間。
3.7.1 優缺點：併發收集，低停頓時間；產生空間碎片，併發階段會降低吞吐量。
3.7.2 CMS工作步驟圖解
3.8 G1收集器
使用G1收集器時，Java堆的內存佈局與就與其他收集器有很大差別，它將整個Java堆劃分爲多個大小相等的獨立區域（Region），雖然還保留有新生代和老年代的概念，但新生代和老年代不再是物理隔離的了，它們都是一部分Region（不需要連續）的集合。每個Region大小都是一樣的，可以是1M到32M之間的數值，但是必須保證是2的n次冪如果對象太大，一個Region放不下[超過Region大小的50%]，那麼就會直接放到H中。設置Region大小：-XX:G1HeapRegionSize=M。所謂Garbage-Frist，其實就是優先回收垃圾最多的Region區域。
3.8.1 G1特性
（1）分代收集（仍然保留了分代的概念）
（2）空間整合（整體上屬於“標記-整理”算法，不會導致空間碎片）
（3）可預測的停頓（比CMS更先進的地方在於能讓使用者明確指定一個長度爲M毫秒的時間片段內，消耗在垃圾收集上的時間不得超過N毫秒）。
3.8.2 Region圖解
3.8.3 G1收集器工作流程圖示：
初始標記：標記GCRoots能夠關聯的對象，並且修改TAMS的值
併發標記：從GCRoot出發進行可達性分析，找到存活對象
最終標記：修正併發標記階段產生的數據差異
篩選回收：對各個Region的回收價值和成本進行排序，根據用戶所期望的GC停頓時間制定回收計劃。
3.9 Zero GC
這是JDK11後引入的收集器，不管是物理上還是邏輯上，ZGC中已經不存在新老年代的概念了會分爲一個個page，當進行GC操作時會對page進行壓縮，因此沒有碎片問題只能在64位的linux上使用，目前用得還比較少。
3.9.1 ZGC特性
（1）可以達到10ms以內的停頓時間要求
（2）支持TB級別的內存
（3）堆內存變大後停頓時間還是在10ms以內
4. 垃圾回收器分類
4.1 串行收集器：Serial 及Serial Old，只有一個GC線程，用戶線程暫停
4.2 並行收集器：Parallel Scanvenge、Parallel Old。吞吐量優先，多條GC線程併發，但用戶線程暫停
4.3 併發收集器：CMS、G1，停頓時間優先，用戶線程和GC線程同時執行，垃圾收集線程執行的時候不會停頓用戶線程。
5. 垃圾回收器擴展
5.1 什麼是停頓時間、吞吐量？
停頓時間：垃圾回收器進行垃圾回收終端應用執行響應的時間。
吞吐量：運行用戶代碼時間/（運行用戶代碼時間+垃圾收集時間）這兩個指標是評價垃圾收集器性能的標準。
5.2 如何選擇適合的垃圾收集器？
優先調整堆的大小讓服務器自己來選擇
如果內存小於100M，使用串行收集器
如果是單核，並且沒有停頓時間要求，使用串行或JVM自己選
如果允許停頓時間超過1秒，選擇並行或JVM自己選
如果響應時間最重要，並且不能超過1秒，使用併發收集器
5.3 什麼時候選擇G1收集器？
JDK9的默認垃圾收集器，適用新老年代。
（1）50%以上的堆被存活對象佔用
（2）對象分配和晉升的速度變化非常大
（3）垃圾回收時間比較長
5.4 如何開啓指定的垃圾收集器
使用-XX: +Use某某垃圾收集器這樣子的配置信息。
6. 最後以一位大佬總結的垃圾回收器的圖加深一下理解和記憶
