1對象存活算法引用計數法
簡介：判斷對象是否存活算法，講解對象垃圾回收對象是否回收判斷
- 引用計數法存在的特點分析
- 優缺點
* 引用計數收集器可以很快的執行，交織在程序運行中。對程序需要不被長時間打斷的實時環境比較有利。
* 無法檢測出循環引用。如父對象有一個對子對象的引用，子對象反過來引用父對象。這樣，他們的引用計數永遠不可能為0.
- 代碼分析JVM是否用引用計數法
- run configurations—》vm options—》加配置項：-verbose:gc -XX:+PrintGCDetails 用來打印GC日志
2對象存活算法可達性分析
簡介：判斷對象是否存活算法，講解對象垃圾回收對象是否回收判斷
- 可達性分析算法的概念(又叫跟搜索法)
* 根搜索算法是從離散數學中的圖論引入的，程序把所有的引用關系看作一張圖，從一個節點GC ROOT開始，尋找對應的引用節點，找到這個節點以后，繼續尋找這個節點的引用節點，當所有的引用節點尋找完畢之后，剩余的節點則被認為是沒有被引用到的節點，即無用的節點
- java中可作為GC Root的對象有
* 虛擬機棧中引用的對象（本地變量表）
* 本地方法棧中引用的對象
* 方法區中靜態屬性引用的對象
* 方法區中常量引用的對象
3標記清除
- 大廠的標准就是原理
- 最基礎的收集算法是“標記-清除”（Mark-Sweep）算法，如同它的名字一樣，算法分為“標記”和“清除”兩個階段：
* 首先標記出所有需要回收的對象，在標記完成后統一回收所有被標記的對象，它的標記過程其實在前- -節講述對象標記判定時已經介紹過了。
* 它的主要不足有兩個：
* 一個是效率問題，標記和清除兩個過程的效率都不高；
* 另一個是空間問題，標記清除之后會產生大量不連續的內存碎片，空間碎片太多可能會導致以后在程序運行過程中需要分配較大對象時，無法找到足夠的連續內存而不得不提前觸發另一次垃圾收集動作
4復制算法
- 為甚么出現復制算法？
* 為了解決效率問題，一種稱為“復制”（Copying）的收集算法出現了，它將可用內存按量划分為大小相等的兩塊，每次只使用其中的一塊
* 當這一塊的內存用完了，就將還存活着的對象復制到另外一塊上面，然后再把已使用過的內存空間一次清理掉。這樣使得每次都是對整個半區進行內存回收，內存分配時也就不用考慮內存碎片等復雜情況，只要移動堆頂指針，按順序分配內存即可，實現簡單，運行高效
- 現在的商業虛擬機都采用這種收集算法來回收新生代，研究表明，新生代中的對象 98%是“朝生夕死”的，所以並不需要按照 1:1 的比例來划分內存空間，而是將內存分為一塊較大的 Eden 空間和兩塊較小的 Survivor 空間，每次使用 Eden 和其中一塊 Survivor。 Survivor from 和Survivor to ，內存比例 8：1：1
- 當回收時，將 Eden 和 Survivor 中還存活着的對象一次性地復制到另外一塊 Survivor 空間上，最后清理掉 Eden 和剛才用過的 Survivor 空間。HotSpot 虛擬機默認 Eden 和 Survivor 的大小比例是 8:1, 也就是每次新生代中可用內存空間為整個新生代容量的 90% (80%+10%），只有 10% 的內存會被“浪費”。當然，98%的對象可回收只是一般場景下的數據，我們沒有辦法保證每次回收都只有不多於 10%的對象存活，當 Survivor 空間不夠用時，需要依賴其他內存（這里指老年代）進行分配擔保（Handle Promotion）。
5標記整理算法與分代收集算法
- 標記整理算法解決了什么問題
* 復制收集算法在對象存活率較高時就要進行較多的復制操作，效率將會變低。更關鍵的是，如果不想浪費 50%的空間，就需要有額外的空間進行分配擔保，以應對被使用的內存中所有對象都 100%存活的極端情況，所以在老年代一般不能直接選用這種算法
- 標記-整理
* 根據老年代的特點，有人提出了另外一種“標記-整理（Mark- Compact）算法，標記過程仍然與“標記-清除”算法一樣，但后續步驟不是直接對可回收對象進行清理，而是讓所有存活的對象都向一端移動，然后直接清理掉端邊界以外的內存
*-分代收集
* 一般把 Java 堆分為新生代和老年代，這樣就可以根據各個年代的特點采用最適當的收集算法
* 在新生代中，每次垃圾收集時都發現有大批對象死去，只有少量存活，那就選用復制算法，標記整理只需要付出少量存活對象的復制成本就可以完成收集。而老年代中因為對象存活率高、沒有額外空間對它進行分配擔保，就必須使用“標記-清理”或者“標記一整理”算法來進行回收
