【初步學習記憶體回收機制】

jvm記憶體的記憶體回收機制主要是針對堆來講的
因為棧的記憶體回收機制隨著一個基本型別的建立與銷燬而進行建立而銷燬，比較固定。

【如何判斷物件是否死亡】

早期有兩種演算法：

第一種是【引用計數演算法】：

    給物件新增一個計數器，物件被引用，則+1，物件引用失效時，就-1。

    任何時刻計數器為0的物件都是可以被清除的。

    但是這裡有一個問題，是我在後面【小狗】那一篇博文中記錄的一個片段，當兩個物件互相引用的時候，  

    他們就算都沒有實際存在價值了，也無法被這種演算法識別。

第二種是【可達性分析演算法】：

    首先確定一個【GcRoots】物件作為起始點，向下搜尋，走過的路經叫做【引用鏈】，如果一個物件到沒有與引用鏈相連，則      認為他是沒有存在價值的一個物件，可以進行回收。

    然而被認為沒有存在價值的物件也不是被直接就回收掉的，他會先被標記並進行一次篩選，

    篩選條件：

    此物件是否有必要執行finalize()方法，當物件沒有覆蓋這個方法或者已經被呼叫過，被視為沒必要執行；

    此物件如果有必要執行finalize()方法，這個物件會被放在一個F-Queue的佇列中，並在之後被一個虛擬機器自動建立的，低優先順序的Finalizer執行緒去執行它，所謂的執行時指虛擬機器會觸發這個方法，但並不承諾會等待他結束，這是為了防止發生異常造成記憶體崩潰。之後GC會對F-queue中物件進行第二次標記，如果物件此時與GcRoot的引用鏈連線上了，就逃脫了被回收的命運，反之被回收。

【一種特例物件】

在回收機制演算法的背後，體現的是一個物件的狀態，分為被引用和沒有被引用兩種。

但實際對於記憶體分析來說，還有一種物件，沒什麼實際用處，但是依然在被引用著，

是否可以有一種方式，可以讓這些雞肋的物件在記憶體充足時可以保留，記憶體不足時則被拋除。

因此jvm1.2之後，java對引用的概念進行了擴充，將引用分為了【強/軟/弱/虛】四種類型：

【強引用】：new一個物件這種普遍存在的；

【軟引用】：softReference類，描述的時有些用但非必需的物件；系統要發生oom異常之前，將會把物件收進回收範圍內進行二次回收，若果仍然不能提供足夠記憶體，才會報異常。

【弱引用】：強度比軟引用更弱一些，弱引用的物件只能存活到下一次GC之前，由weakReference實現。

【虛引用】：需引用不會對物件的生存時間構成影響，也無法通過虛引用來建立物件例項，作用是這個物件被回收時，會獲得一個系統通知，由phantomReference實現。

【垃圾收集演算法】： 

【複製演算法】

這種演算法會將記憶體劃分為兩個相等的塊，每次只使用其中一塊。當這塊記憶體不夠使用時，就將還存活的物件複製到另一塊記憶體中，然後把這塊記憶體一次清理掉。這樣做的效率比較高，也避免了記憶體碎片。但是這樣記憶體的可使用空間減半，是個不小的損失。

把堆均分成兩個大小相同的區域，只使用其中的一個區域，直到該區域消耗完。此時垃圾回收器終端程式的執行，通過遍歷把所有活動的物件複製到另一個區域，複製過程中它們是緊挨著佈置的，這樣也可以達到消除記憶體碎片的目的。複製結束後程序會繼續執行，直到該區域被用完。 
但是，這種方法有兩個缺陷:
對於指定大小的堆，需要兩倍大小的記憶體空間，
需要中斷正在執行的程式，降低了執行效率

【標記-清除演算法】
這種垃圾回收一次回收分為兩個階段：標記、清除。首先標記所有需要回收的物件，在標記完成後回收所有被標記的物件。這種回收演算法會產生大量不連續的記憶體碎片，當要頻繁分配一個大物件時，jvm在新生代中找不到足夠大的連續的記憶體塊，會導致jvm頻繁進行記憶體回收(目前有機制，對大物件，直接分配到老年代中)
【標記-整理演算法】

這是標記-清除演算法的升級版。在完成標記階段後，不是直接對可回收物件進行清理，而是讓存活物件向著一端移動，然後清理掉邊界以外的記憶體

【分代收集演算法】

當前商業虛擬機器都採用這種演算法。
首先根據物件存活週期的不同將記憶體分為幾塊即新生代、老年代，
然後根據不同年代的特點，採用不同的收集演算法。
在新生代中，每次垃圾收集時都有大量物件死去，只有少量存活，所以選擇了複製演算法。

而老年代中因為物件存活率比較高，所以採用標記-整理演算法(或者標記-清除演算法)

新生代：包括一個Eden以及兩個Survivor區，分別稱為s0，s1；初始化後，第一次堆中的物件，放置在Eden中，當此區域記憶體滿了之後，進行一次GC，然後將Eden中存活的物件放到s0中，每次存貨物件被GC移動至其他區的時候，內建計數器+1，【預設當計數器到了15次後，將存貨物件放入老年區，此閾值可配置】當Eden第二次記憶體滿了之後，GC檢視Eden及s0區，將存活物件放入s1，並清空Eden及s0，若s1記憶體滿了，存貨物件也會進入老年區；當Eden第三次滿了之後，GC會檢視Eden及s1區，然後存活物件放入s0，以此類推。s0，s1交替存放存活的物件。

老年代：如果某個物件經歷了幾次垃圾回收之後還存活【上面提了預設8次】，就會被存放到老年代中。老年代的空間一般比新生代大。

【垃圾收集器】：

   這裡只作簡單介紹：

Serial收集器：最基本的收集齊，單執行緒，在gc時，需要暫停所有其他執行緒的工作。emmmm

ParNew收集器：Serial的多執行緒版本，使用複製演算法。

Parallel Scavenge收集器：與ParNew相似，但是關注點不同，其他收集器關注點是縮短GC時，減少使用者執行緒的停頓時間，而這個收集齊的目標是i達到一個可控制的吞吐量。

SerialOld收集器，使用標記整理，單執行緒。

ParallelOld收集器，使用標記整理，多執行緒。

CMS收集器：獲取最短回收停頓時間為目標的收集器。

G1收集器：最新的了，是面試的重點。

（CMS和G1我會在後續深入學習後，再寫一篇相關的部落格）

【幾種常用的GC】

Minor GC

從年輕代空間（包括 Eden 和 Survivor 區域）回收記憶體被稱為 Minor GC。這一定義既清晰又易於理解。但是，當發生Minor GC事件的時候，有一些有趣的地方需要注意到：

當 JVM 無法為一個新的物件分配空間時會觸發 Minor GC，比如當 Eden 區滿了。所以分配率越高，越頻繁執行 Minor GC。

記憶體池被填滿的時候，其中的內容全部會被複制，指標會從0開始跟蹤空閒記憶體。Eden 和 Survivor 區進行了標記和複製操作，取代了經典的標記、掃描、壓縮、清理操作。所以 Eden 和 Survivor 區不存在記憶體碎片。寫指標總是停留在所使用記憶體池的頂部。
執行 Minor GC 操作時，不會影響到永久代。從永久代到年輕代的引用被當成 GC roots，從年輕代到永久代的引用在標記階段被直接忽略掉。
質疑常規的認知，所有的 Minor GC 都會觸發“全世界的暫停（stop-the-world）”，停止應用程式的執行緒。對於大部分應用程式，停頓導致的延遲都是可以忽略不計的。其中的真相就 是，大部分 Eden 區中的物件都能被認為是垃圾，永遠也不會被複制到 Survivor 區或者老年代空間。如果正好相反，Eden 區大部分新生物件不符合 GC 條件，Minor GC 執行時暫停的時間將會長很多。所以 Minor GC 的情況就相當清楚了——每次 Minor GC 會清理年輕代的記憶體。
Major GC vs Full GC
大家應該注意到，目前，這些術語無論是在 JVM 規範還是在垃圾收集研究論文中都沒有正式的定義。但是我們一看就知道這些在我們已經知道的基礎之上做出的定義是正確的，Minor GC 清理年輕帶記憶體應該被設計得簡單：
Major GC 是清理老年代。
Full GC 是清理整個堆空間—包括年輕代和老年代。