給物件新增乙個引用計數器,規定如下
引用計數器無法解決物件迴圈引用的問題
當執行系統停頓下來後,並不需要乙個不漏地檢查完所有執行上下文和全域性的引用位置,虛擬機器應當是有辦法直接得知哪些地方存放著物件引用.
在hotspot的實現中,是使用一組稱為oopmap的資料結構來達到目的的
在oopmap的協助下,hotspot可以快速且準確的完成gc roots列舉,但乙個很現實的問題隨之而來–可能導致引用關係變化,或者說oopmap內容變化的指令非常多,如果為每一條指令都生成對應的oopmap,那將會需要大量額外的空間,這樣gc的空間成本將會變得更高
實際上,hotspot並沒有為每條指令都生成oopmap,而是只在特定的位置記錄了這些資訊,這些位置稱為安全點safepoint,即程式執行時並非在所有地方都停下來開始gc,只有在達到安全點時才能暫停
safepoint的選定的既不能太少以至於讓gc等待太長時間,也不能過於頻繁以至於增大執行時的負載.所以,安全點的選定基本上是以是否具有讓程式長時間執行的特徵為標準選定的—因為每條指令執行的時間非常段短暫,程式不太可能疑問指令流長度太長這個原因而長時間的執行—長時間執行的最明顯特徵就是指令序列復用,如
所以具有這些功能的指令才會產生safepoint
對於safepoint,另乙個需要考慮的問題是如何在gc發生時讓所有執行緒(這裡不包括jni呼叫的執行緒)都"跑"到最近的安全點上在停頓下來,有兩種中斷
現在幾乎沒有虛擬機器採用搶斷式中斷來暫停執行緒從而響應gc事件
在使用safepoint似乎已經完美解決了如何進入gc的問題,但實際情況卻並不一定.
safepoint機制保證了程式執行時,在不太長的時間就會遇到可進入gc的safepoint,但如果程式在不執行的時候呢?
所謂程式不執行就是沒有分配cpu的時間,典型的例子就是處於sleep或者blocked狀態,只是就執行緒無法響應jvm的中斷請求,jvm也顯然不太可能等待執行緒重新分配cpu時間,對於這種情況,就需要安全區域safe regin來解決了
JVM 垃圾收集演算法
這裡只是各個演算法的思想及發展過程 這是最基礎的收集演算法，分為兩個過程，標記和清除兩個階段。首先標記出需要 的物件，在標記完成後統一 掉所有被標記的物件。標記的過程就是之前判定物件的時候標記的。後續的演算法都是基於這種思路進行改進的。缺點呢，有兩個，1.效率問題，標記和清除的效率都不高。2.空間問...
JVM之垃圾收集演算法
標記清除演算法主要分為兩個階段，標記階段和清除階段，這兩個階段效率比較低，而且收集之後會產生記憶體碎片，無法為大的物件分配記憶體空間。如下圖 複製演算法解決了記憶體碎片問題，但是隨之而來的卻是把記憶體一分為二。原理是 記憶體一分為二，每次使用其中的一半，當需要 的時候，講死亡物件清理，然後存活物件移...
jvm垃圾收集演算法整理
1，標記清除演算法 標記可 的記憶體，然後清除。2，複製演算法。使用標記清除演算法的過程中，如果 的記憶體很少這個演算法還是可以的，但是如果大量的記憶體都是需要 的，那這個就比較笨重，因為我們只需要保留少量不被 的記憶體就可以。這就衍生出了複製演算法。3，標記整理演算法 使用標記清除演算法的過程中，...