引用計數與可達性分析：誰死了，誰還活著？
垃圾回收，顧名思義，便是將已經分配出去的，但卻不再使用的內存回收回來，以便能夠再次分配。在Java虛擬機的語境下，垃圾指的是死亡的對象所占據的堆空間。這里便涉及了一個關鍵的問題：如何辨別一個對象是存是亡？

引用計數
引用計數（Reference Counting）是一種古老的辨別方法，它的基本思想是給每個對象添加一個引用計數器，每當有一個引用指向該對象時，計數器就加1；每當有一個引用停止指向該對象時，計數器就減1。當計數器的值變為0時，就表示沒有任何引用指向該對象，因此該對象就成為垃圾，
引用計數的主要問題是無法處理循環引用（Reference Cycle）的情況。例如，如果對象A和對象B互相引用，那么即使沒有其他引用指向它們，它們的引用計數器也不會變為0，因此它們不會被回收，這就導致了內存泄漏。這是引用計數最大的缺點，也是它在許多現代編程語言中不被使用的主要原因。

另外，引用計數需要在每次引用賦值時更新引用計數器，這會帶來一定的性能開銷。而且，如果多個線程同時修改同一個對象的引用計數器，還需要進行同步，這會進一步增加性能開銷。

可達性分析
Java虛擬機的主要采取的是可達性分析（Reachability Analysis）。這個算法是通過一系列的稱為GC Roots的對象作為起始點，從這些節點開始向下搜索，搜索所走過的路徑稱為引用鏈（Reference Chain），當一個對象到GC Roots沒有任何引用鏈相連時，則證明此對象是不可用的。
GC Roots通常是由堆外指向堆內的引用，包括以下幾種。
1）虛擬機棧（棧幀中的本地變量表）中引用的對象；
2）方法區中類靜態屬性引用的對象；
3）方法區中常量引用的對象；
4）本地方法棧中JNI（即一般說的Native方法）引用的對象。

可達性分析可以解決引用計數所不能解決的循環引用問題。例如，即便對象A和B相互引用，只要從GC Roots出發無法到達A或者B，那么可達性分析便不會將它們加入存活對象合集之中。
盡管可達性分析的算法本身很直觀，但在實際應用中，還需要解決一些其他問題，如誤標和漏標。
1）誤標：將已經不再使用的對象錯誤地標記為"活的"。例如，一個全局靜態對象引用了一個已經不再需要的局部對象，它會被錯誤地標記為"活的"。
2）漏標：將仍在使用的對象錯誤地標記為"死的"。例如，在并發環境中，一個線程正在使用一個對象，而另一個線程正在進行垃圾回收。如果垃圾回收線程看到的是一個過時的對象引用關系，它可能會錯誤地認為一個正在使用的對象是"死的"。
誤報可能導致Java虛擬機錯過部分垃圾回收的機會。而漏報更麻煩，因為垃圾回收器可能會錯誤地回收仍被引用的對象內存。如果試圖從原引用訪問已經被回收的對象，可能會導致Java虛擬機崩潰。

Stop-the-world 以及安全點
為了避免這些問題，Java虛擬機的傳統垃圾回收算法采用了Stop-the-world方式。在此階段，Java虛擬機會暫停所有的應用線程，確保在垃圾回收過程中不會有新的對象被創建，也不會有對象引用關系的變化。但這會導致應用程序的響應時間增加，因為在這個階段，所有的應用線程都被暫停，應用程序無法響應用戶的請求。
安全點（Safe Point）是Java虛擬機用來控制Stop-the-World的一種機制。安全點是指那些可以安全地暫停應用線程的點。在這些點上，Java虛擬機可以確保對象引用關系不會發生變化。常見的安全點有方法調用（包括JNI方法調用）、循環跳轉、異常拋出等。其中方法調用是一個很好的安全點，因為方法調用通常涉及到大量的對象引用操作。
對于解釋執行，當有安全點請求時，Java虛擬機可以在每條字節碼指令后面都設置一個安全點，但這種方式的開銷很大。在執行即時編譯器生成的機器碼時，Java虛擬機通常會在方法的入口和退出處，以及循環的回邊處設置安全點。另外當線程阻塞時，由于處于Java虛擬機線程調度器的掌控之下，因此可以設置安全點。

未完待續

很高興與你相遇！如果你喜歡本文內容，記得關注哦