JVM是如何和“垃圾”發生關系的
本文轉載自微信公眾號「碼上Java」，作者碼上Java。轉載本文請聯系碼上Java公眾號。
在開始之前，我們先回顧一下堆是個什么玩意，大家可能都知道，我們每天創建的Java對象幾乎都存放在堆上面，所以說堆是一個巨大的對象池一點都不過分，在這個對象池里面管理者數據巨大的對象實例。
在對象池中對象的引用層次，有的是很深的。比如一個調用非常頻繁的接口，生產對象的速度是非常可觀的。對象之間的關系，可以形容成一張網。雖然Java總是給人一種有使不完的內存的感覺，但是對象也不能一直增加不減少啊，所以就必須有垃圾回收這個操作。
那么JVM如何發現垃圾的呢?
"垃圾回收"本文中簡稱 GC
你還記得電視劇中的“誅九族""?
比如小憨批打了皇帝老兒一巴掌，把皇帝老兒打的鼻青臉腫滴，皇帝老兒非常生氣，他要下令誅小憨批的九族，以平心頭只恨。
哈哈哈嗝~ 小憨批完了~
那么我們看看在古代這個誅九族是具體操作的呢?首先需要追溯到共同的祖先(也就是小憨批家族的大哥大)，再往下逐一細數和小憨批有關系的(小憨批真坑啊)。
其實發生在堆上的垃圾回收和這個“誅九族“的是相同思路，那么我們下面具體分析一下JVM是如何進行GC的呢?
關于JVM的GC是不受程序控制的，當滿足一定條件的時候就會主動觸發。
當發生GC的時候，對于一個對象來說，JVM總能夠找到引用它的祖先，當找到最后的時候，JVM發現這家伙的有些祖先已經玩完了，那么它們就會被JVM給干掉。
為什么還有沒有被干掉的祖先呢?因為這些躲過GC的祖先們，它們是GC Roots ，長得比較特殊嘛(下面介紹它們的樣子)。
當從GC Roots 向下追溯、搜索，就會產生一個引用鏈。當碰到有對象沒有任何一個GC Roots 產生關系的話，這個對象就會被無情的干掉。(一根繩上的螞蚱嘛)
來，我們畫個圖瞅瞅咋回事，如下圖所示，Object5、Object6、Object7，由于不能和 GC Root 產生關聯，發生 GC 時，就會被摧毀。
其實所謂的垃圾回收就是圍繞著GC Roots 來的，但是同時，GC Roots 也存在著很多內存泄漏的根源，因為其他引用小弟壓根沒有這個權利。
你可能會產生疑問，那么什么樣的對象才會是GC Roots 呢?
這個不在于它是什么樣的對象，關鍵是它所處的位置(仔細品~)。
GC Roots 是什么
首先，GC Roots必須是一組必須活躍的引用。簡單的講，就是程序接下來通過直接引用或間接引用，能夠被訪問到的潛在被使用的對象(咋感覺還是有點繞呢)。
GC Roots 是這樣子滴：
- Java線程中，當前所有正在被調用的方法的引用類型參數、局部變量、臨時值等等。也就是與我們棧幀相關的各種引用。
- 所有當前被加載的Java類。
- Java類的引用類型靜態變量。
- 運行時常量池里的引用類型常量。
- JVM內部數據結構的一些引用，比如sun.jvm.hotspot.memory.Univers類。
- 用于同步的監控對象。比如調用了對象的wait()方法。
- JNI handles,包括global handles 和 local handles。
以上GC Roots大致可以分為一下三大類。
- 活動線程相關的各種引用。
- 類的靜態變量的引用。
- JNI引用。
最后我們需要注意的是，我們這里說的是活躍的引用，而不是對象，對象是不能作為GC Roots的。
整個GC過程中是找到那些活對象，并把剩余的空間都認得為“無用”。而不是找到所有死掉的對象，并回收它們占用的空間。所有說，哪怕JVM的堆非常大，基于tracing的GC方式，回收速度也是跟快的。
總結
GC Roots 就是可達性分析法。還有一種叫作引用計數法的方式。下面我們簡單介紹一下。
引用計數法：在Java中如果要操作對象，就必須先獲取該對象的引用，因此可以通過引用計數法來判斷一個對象是否可以被回收。在為一個對象添加一個引用時，引用計數器就加1;為對象刪除一個引用時，引用計數器就減1;如果一個對象的引用計數為0，則說明該對象沒有被引用，可以回收。
優點是垃圾回收比較及時，實時性比較高，只要對象計數器為 0，則可以直接進行回收操作;而缺點是無法解決循環引用的問題。
因為存在循環引用這個致命的硬傷，沒有一個主流JVM是采用引用計數法來實現 GC 的，所以你現在完全忘記引用計數這種方式了。
