java虛擬機器總共分為五個區域，其中三個是執行緒私有：程式計數器，虛擬機器棧，本地方法棧，兩個是執行緒共享：堆，方法區。執行緒私有的區域等到執行緒結束時（棧幀出棧時）會自動被釋放，空間比較容易清理。而執行緒共享的java堆和方法區中的空間較大而且沒有執行緒的回收容易產生很多垃圾資訊，GC垃圾回收真正關心的就是這部分。

java堆和方法區主要存放各種型別的物件（方法區中也儲存一些靜態變數和全域性常量等資訊），那麼我們在使用GC對其進行回收的時候首先要考慮的就是如何判斷一個物件是否應該被回收。也就是要判斷一個物件是否還有其他的引用或關聯使得這個物件處於存活的狀態。我們需要將不在存活狀態的所有物件標記出，以便於GC進行回收。

判斷物件是否存活有兩種比較常見的方法：引用計數法與可達性分析演算法。

引用計數法

引用計數法的邏輯非常簡單，但是存在問題，java並不採用這種方式進行物件存活判斷。

引用計數法的邏輯是：在堆中儲存物件時，在物件頭處維護一個counter計數器，如果一個物件增加了一個引用與之相連，則將counter++。如果一個引用關係失效則counter–。如果一個物件的counter變為0，則說明該物件已經被廢棄，不處於存活狀態。

這種方法來標記物件的狀態會存在很多問題：

1 jdk從1.2開始增加了多種引用方式：軟引用、弱引用、虛引用，且在不同引用情況下程式應進行不同的操作。如果我們只採用一個引用計數法來計數無法準確的區分這麼多種引用的情況。

引用計數法無法解決多種型別引用的問題。但這並不是致命的，因為我們可以通過增加邏輯區分四種引用情況，雖然麻煩一些但還算是引用計數法的變體，真正讓引用計數法徹底報廢的下面的情況。

2 如果一個物件A持有物件B，而物件B也持有一個物件A，那發生了類似作業系統中死鎖的迴圈持有，這種情況下A與B的counter恆大於1，會使得GC永遠無法回收這兩個物件。

可達性分析演算法

在主流的商用程式語言中(Java和C#)，都是使用可達性分析演算法判斷物件是否存活的。這個演算法的基本思路就是通過一系列名為GC Roots的物件作為起始點，從這些節點開始向下搜尋，搜尋所走過的路徑稱為引用鏈(Reference Chain)，當一個物件到GC Roots沒有任何引用鏈相連時，則證明此物件是不可用的，下圖物件object5, object6, object7雖然有互相判斷，但它們到GC Roots是不可達的，所以它們將會判定為是可回收物件。

那麼那些點可以作為GC Roots呢？一般來說，如下情況的物件可以作為GC Roots：

1. 虛擬機器棧(棧楨中的本地變量表)中的引用的物件
2. 方法區中的類靜態屬性引用的物件
3. 方法區中的常量引用的物件
4. 本地方法棧中JNI（Native方法）的引用的物件

HotSpot虛擬機器如何實現可達性演算法？

java中的主流虛擬機器HotSpot採用可達性分析演算法來確定一個物件的狀態，那麼HotSpot在具體實現該演算法時採用了哪些結構？

使用OopMap記錄並列舉根節點

HotSpot首先需要列舉所有的GC Roots根節點，虛擬機器棧的空間不大，遍歷一次的時間或許可以接受，但是方法區的空間很可能就有數百兆，遍歷一次需要很久。更加關鍵的是，當我們遍歷所有GC Roots根節點時，我們需要暫停所有使用者執行緒，因為我們需要一個此時此刻的”虛擬機器快照”，如果我們不暫停使用者執行緒，那麼虛擬機器仍處於執行狀態，我們無法確保能夠正確遍歷所有的根節點。所以此時的時間開銷過大更是我們不能接受的。

基於這種情況，HotSpot實現了一種叫做OopMap的資料結構，這種資料結構在類載入完成時把物件內的偏移量是什麼型別計算出，並且存放下位置，當需要遍歷根結點時訪問所有OopMap即可。

用安全點Safepoint約束根節點

如果將每個符合GC Roots條件的物件都存放進入OopMap中，那麼OopMap也會變得很大，而且其中很多物件很可能會發生一些變化，這些變化使得維護這個對映表很困難。實際上，HotSpot並沒有為每一個物件都建立OopMap，只在特定的位置上建立了這些資訊，這些位置稱為安全點（Safepoints）。

為了保證虛擬機器中安全點的個數不算太多也不是太少，主要決定安全點是否被建立的因素是時間。當進行了耗時的操作時，比如方法呼叫、迴圈跳轉等時會產生安全點。此外，HotSpot虛擬機器在安全點的基礎上還增加了安全區域的概念，安全區域是安全點的擴充套件。在一段安全區域中能夠實現安全點不能達成的效果。