概述

引用計數(shù)法又是什么鬼呢? 顧名思義, 對對象的引用進行計數(shù). 通過記錄每個對象被引用的次數(shù), 來確定這個對象是否可以被回收.

實現(xiàn)

首先, 對對象的引用數(shù)量進行管理, 什么時候會更新呢?

創(chuàng)建對象: 新建一個對象(對這個新的對象引用數(shù)量+1)

更新指針: 將一個指向A對象的指針重新指向B對象(將A對象引用數(shù)量-1, B對象引用數(shù)量+1)

這次就不上代碼了, 簡單介紹一下思路就行. (我哥說代碼看著費勁)

前提: 我們有一個全局的空閑地址鏈表: FREE_HEAD

創(chuàng)建對象的操作

從FREE_HEAD中尋找內(nèi)存

若找到了, 該對象計數(shù)器置為1, 返回

若沒有找到, 內(nèi)存擴容, 返回1

更新指針的操作

將新的對象引用計數(shù)+1

將舊的對象引用計數(shù)-1. 若-1后引用數(shù)量為0, 則將該對象及所有的子對象添加到FREE_HEAD鏈表中.

實現(xiàn)說起來簡簡單單, 畢竟我也不用真的去實現(xiàn), 簡單想一下.

分析

在上一次的標記清除算法中, GC在每次內(nèi)存不足時運行, 勢必會導致程序暫停時間比較長. 但引用計數(shù)則在每次指針變更的同時進行管理, 在產(chǎn)生新的垃圾的時候立刻進行回收. 這就體現(xiàn)出它的幾個優(yōu)勢了:

最大暫停時間短.

產(chǎn)生垃圾可立即回收

當然, 只說優(yōu)勢不說劣勢都是扯犢子. 首先, 引用計數(shù)的優(yōu)勢也會成為它的劣勢, 計數(shù)頻繁的計算, 會拖累程序的速度. 而且每個對象都要開拓空間來保存引用數(shù)量. 當然了, 還有經(jīng)常被說到的循環(huán)引用的問題. 等等吧.

頻繁的更新引用計數(shù)拖累程序速度

每個對象需要開拓額外空間保存引用計數(shù)

循環(huán)引用對象無法被回收(就是A引用B, B引用A. 但是他們都沒有被其他對象引用, 導致他倆的引用始終為1, 無法回收)

當然, 針對問題, 偉大的前人總是有辦法去解決. 比如:

延遲計數(shù)法: 針對頻繁更新計數(shù)器的問題而提出的. 大概意思就是不去實時的對引用數(shù)量進行更新, 將引用數(shù)量為0的記錄到一個待處理的鏈表中, 當需要新的內(nèi)存時再統(tǒng)一處理. 但是這樣又會增大暫停時間, 才不要.

Sticky引用計數(shù)法: 引用計數(shù)通過額外的空間保存引用數(shù)量, 但這個必然會有最大值, 比如用1個字節(jié), 則引用數(shù)量超過256的就記不下了. 這個方法對超出范圍的處理方式很簡單, 什么都不做, 不去回收, 畢竟被引用這么多次, 該對象定然很重要. 那這些對象不就永遠都不能被回收了么? 可以, 等到?jīng)]有內(nèi)存了, 使用標記清除算法將所有對象過一遍.

當然, 針對引用計數(shù)法還有很多演變, 有些還是很有意思的, 有些是我看不懂的.

---

垃圾回收的整體思路分兩個流派(我所知道的):

引用計數(shù): 就是上面說的這種

可達性: 就是標記清除那種, 判斷一個對象是否可以到達.

引用計數(shù)的最大優(yōu)勢應該就是不需要暫停程序去進行回收了, 隨使用隨回收. 但劣勢也很明顯: 需要計數(shù)器額外空間以及循環(huán)引用的問題.

個人是比較喜歡引用計數(shù)的, 實時性又高, 又不需要太多的額外空間. 只是需要在編寫代碼的時候刻意規(guī)避循環(huán)引用, 或者其他方法規(guī)避一下? 甚至不去處理都刻意, 如果只有少數(shù)的話(如果有很多, 還是換個算法吧).

總結(jié)

以上是生活随笔為你收集整理的GC算法-引用计数法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。