iOS 底層解析weak的實現原理(包含weak對象的初始化,引用,釋放的分析)

很少有人知道weak表其實是一個hash(哈希)表,Key是所指對象的地址,Value是weak指針的地址數組。更多人的人只是知道weak是弱引用,所引用對象的計數器不會加一,并在引用對象被釋放的時候自動被設置為nil。通常用于解決循環引用問題。但現在單知道這些已經不足以應對面試了,好多公司會問weak的原理。weak的原理是什么呢?下面就分析一下weak的工作原理(只是自己對這個問題好奇,學習過程中的筆記,希望對讀者也有所幫助)。

weak 實現原理的概括

Runtime維護了一個weak表,用于存儲指向某個對象的所有weak指針。weak表其實是一個hash(哈希)表,Key是所指對象的地址,Value是weak指針的地址(這個地址的值是所指對象指針的地址)數組。

weak 的實現原理可以概括一下三步:

1、初始化時:runtime會調用objc_initWeak函數,初始化一個新的weak指針指向對象的地址。
2、添加引用時:objc_initWeak函數會調用 objc_storeWeak() 函數, objc_storeWeak() 的作用是更新指針指向,創建對應的弱引用表。
3、釋放時,調用clearDeallocating函數。clearDeallocating函數首先根據對象地址獲取所有weak指針地址的數組,然后遍歷這個數組把其中的數據設為nil,最后把這個entry從weak表中刪除,最后清理對象的記錄。

下面將開始詳細介紹每一步:

1、初始化時:runtime會調用objc_initWeak函數,objc_initWeak函數會初始化一個新的weak指針指向對象的地址。

示例代碼:

{
    NSObject *obj = [[NSObject alloc] init];
    id __weak obj1 = obj;
}

當我們初始化一個weak變量時,runtime會調用 NSObject.mm 中的objc_initWeak函數。這個函數在Clang中的聲明如下:

id objc_initWeak(id *object, id value);

而對于 objc_initWeak() 方法的實現

id objc_initWeak(id *location, id newObj) {
// 查看對象實例是否有效
// 無效對象直接導致指針釋放
    if (!newObj) {
        *location = nil;
        return nil;
    }
    // 這里傳遞了三個 bool 數值
    // 使用 template 進行常量參數傳遞是為了優化性能
    return storeWeakfalse/*old*/, true/*new*/, true/*crash*/>
    (location, (objc_object*)newObj);
}

可以看出,這個函數僅僅是一個深層函數的調用入口,而一般的入口函數中,都會做一些簡單的判斷(例如 objc_msgSend 中的緩存判斷),這里判斷了其指針指向的類對象是否有效,無效直接釋放,不再往深層調用函數。否則,object將被注冊為一個指向value的__weak對象。而這事應該是objc_storeWeak函數干的。

注意:objc_initWeak函數有一個前提條件:就是object必須是一個沒有被注冊為__weak對象的有效指針。而value則可以是null,或者指向一個有效的對象。

2、添加引用時:objc_initWeak函數會調用 objc_storeWeak() 函數, objc_storeWeak() 的作用是更新指針指向,創建對應的弱引用表。

objc_storeWeak的函數聲明如下:

id objc_storeWeak(id *location, id value);

objc_storeWeak() 的具體實現如下:

// HaveOld:  true - 變量有值
//          false - 需要被及時清理,當前值可能為 nil
// HaveNew:  true - 需要被分配的新值,當前值可能為 nil
//          false - 不需要分配新值
// CrashIfDeallocating: true - 說明 newObj 已經釋放或者 newObj 不支持弱引用,該過程需要暫停
//          false - 用 nil 替代存儲
template bool HaveOld, bool HaveNew, bool CrashIfDeallocating>
static id storeWeak(id *location, objc_object *newObj) {
    // 該過程用來更新弱引用指針的指向
    // 初始化 previouslyInitializedClass 指針
    Class previouslyInitializedClass = nil;
    id oldObj;
    // 聲明兩個 SideTable
    // ① 新舊散列創建
    SideTable *oldTable;
    SideTable *newTable;
    // 獲得新值和舊值的鎖存位置(用地址作為唯一標示)
    // 通過地址來建立索引標志,防止桶重復
    // 下面指向的操作會改變舊值
retry:
    if (HaveOld) {
        // 更改指針,獲得以 oldObj 為索引所存儲的值地址
        oldObj = *location;
        oldTable = &SideTables()[oldObj];
    } else {
        oldTable = nil;
    }
    if (HaveNew) {
        // 更改新值指針,獲得以 newObj 為索引所存儲的值地址
        newTable = &SideTables()[newObj];
    } else {
        newTable = nil;
    }
    // 加鎖操作,防止多線程中競爭沖突
    SideTable::lockTwoHaveOld, HaveNew>(oldTable, newTable);
    // 避免線程沖突重處理
    // location 應該與 oldObj 保持一致,如果不同,說明當前的 location 已經處理過 oldObj 可是又被其他線程所修改
    if (HaveOld  &&  *location != oldObj) {
        SideTable::unlockTwoHaveOld, HaveNew>(oldTable, newTable);
        goto retry;
    }
    // 防止弱引用間死鎖
    // 并且通過 +initialize 初始化構造器保證所有弱引用的 isa 非空指向
    if (HaveNew  &&  newObj) {
        // 獲得新對象的 isa 指針
        Class cls = newObj->getIsa();
        // 判斷 isa 非空且已經初始化
        if (cls != previouslyInitializedClass  &&
            !((objc_class *)cls)->isInitialized()) {
            // 解鎖
            SideTable::unlockTwoHaveOld, HaveNew>(oldTable, newTable);
            // 對其 isa 指針進行初始化
            _class_initialize(_class_getNonMetaClass(cls, (id)newObj));
            // 如果該類已經完成執行 +initialize 方法是最理想情況
            // 如果該類 +initialize 在線程中
            // 例如 +initialize 正在調用 storeWeak 方法
            // 需要手動對其增加保護策略,并設置 previouslyInitializedClass 指針進行標記
            previouslyInitializedClass = cls;
            // 重新嘗試
            goto retry;
        }
    }
    // ② 清除舊值
    if (HaveOld) {
        weak_unregister_no_lock(&oldTable->weak_table, oldObj, location);
    }
    // ③ 分配新值
    if (HaveNew) {
        newObj = (objc_object *)weak_register_no_lock(&newTable->weak_table,
                                                      (id)newObj, location,
                                                      CrashIfDeallocating);
        // 如果弱引用被釋放 weak_register_no_lock 方法返回 nil
        // 在引用計數表中設置若引用標記位
        if (newObj  &&  !newObj->isTaggedPointer()) {
            // 弱引用位初始化操作
            // 引用計數那張散列表的weak引用對象的引用計數中標識為weak引用
            newObj->setWeaklyReferenced_nolock();
        }
        // 之前不要設置 location 對象,這里需要更改指針指向
        *location = (id)newObj;
    }
    else {
        // 沒有新值,則無需更改
    }
    SideTable::unlockTwoHaveOld, HaveNew>(oldTable, newTable);
    return (id)newObj;
}

撇開源碼中各種鎖操作,來看看這段代碼都做了些什么。

1)、SideTable

SideTable 這個結構體,我給他起名引用計數和弱引用依賴表,因為它主要用于管理對象的引用計數和 weak 表。在 NSObject.mm 中聲明其數據結構:

struct SideTable {
// 保證原子操作的自旋鎖
    spinlock_t slock;
    // 引用計數的 hash 表
    RefcountMap refcnts;
    // weak 引用全局 hash 表
    weak_table_t weak_table;

}
對于 slock 和 refcnts 兩個成員不用多說,第一個是為了防止競爭選擇的自旋鎖,第二個是協助對象的 isa 指針的 extra_rc 共同引用計數的變量(對于對象結果,在今后的文中提到)。這里主要看 weak 全局 hash 表的結構與作用。

2)、weak表

weak表是一個弱引用表,實現為一個weak_table_t結構體,存儲了某個對象相關的的所有的弱引用信息。其定義如下(具體定義在objc-weak.h中):

   struct weak_table_t {
    // 保存了所有指向指定對象的 weak 指針
    weak_entry_t *weak_entries;
    // 存儲空間
    size_t    num_entries;
    // 參與判斷引用計數輔助量
    uintptr_t mask;
    // hash key 最大偏移值
    uintptr_t max_hash_displacement;
};

這是一個全局弱引用hash表。使用不定類型對象的地址作為 key ,用 weak_entry_t 類型結構體對象作為 value 。其中的 weak_entries 成員,從字面意思上看,即為弱引用表入口。其實現也是這樣的。

其中weak_entry_t是存儲在弱引用表中的一個內部結構體,它負責維護和存儲指向一個對象的所有弱引用hash表。其定義如下:

typedef objc_object ** weak_referrer_t;
struct weak_entry_t {
    DisguisedPtrobjc_object> referent;
    union {
        struct {
            weak_referrer_t *referrers;
            uintptr_t        out_of_line : 1;
            uintptr_t        num_refs : PTR_MINUS_1;
            uintptr_t        mask;
            uintptr_t        max_hash_displacement;
        };
        struct {
            // out_of_line=0 is LSB of one of these (don't care which)
            weak_referrer_t  inline_referrers[WEAK_INLINE_COUNT];
        };
    }
}

在 weak_entry_t 的結構中,DisguisedPtr referent 是對泛型對象的指針做了一個封裝,通過這個泛型類來解決內存泄漏的問題。從注釋中寫 out_of_line 成員為最低有效位,當其為0的時候, weak_referrer_t 成員將擴展為多行靜態 hash table。其實其中的 weak_referrer_t 是二維 objc_object 的別名,通過一個二維指針地址偏移,用下標作為 hash 的 key,做成了一個弱引用散列。
那么在有效位未生效的時候,out_of_line 、 num_refs、 mask 、 max_hash_displacement 有什么作用?以下是筆者自身的猜測:

out_of_line:最低有效位,也是標志位。當標志位 0 時,增加引用表指針緯度。
num_refs:引用數值。這里記錄弱引用表中引用有效數字,因為弱引用表使用的是靜態 hash 結構,所以需要使用變量來記錄數目。
mask:計數輔助量。
max_hash_displacement:hash 元素上限閥值。
其實 out_of_line 的值通常情況下是等于零的,所以弱引用表總是一個 objc_objective 指針二維數組。一維 objc_objective 指針可構成一張弱引用散列表,通過第三緯度實現了多張散列表,并且表數量為 WEAK_INLINE_COUNT 。

總結一下 StripedMap[] : StripedMap 是一個模板類,在這個類中有一個 array 成員,用來存儲 PaddedT 對象,并且其中對于 [] 符的重載定義中,會返回這個 PaddedT 的 value 成員,這個 value 就是我們傳入的 T 泛型成員,也就是 SideTable 對象。在 array 的下標中,這里使用了 indexForPointer 方法通過位運算計算下標,實現了靜態的 Hash Table。而在 weak_table 中,其成員 weak_entry 會將傳入對象的地址加以封裝起來,并且其中也有訪問全局弱引用表的入口。


31B622B5-77ED-4D50-8CF9-0803785117BC.png

舊對象解除注冊操作 weak_unregister_no_lock

該方法主要作用是將舊對象在 weak_table 中接觸 weak 指針的對應綁定。根據函數名,稱之為解除注冊操作。從源碼中,可以知道其功能就是從 weak_table 中接觸 weak 指針的綁定。而其中的遍歷查詢,就是針對于 weak_entry 中的多張弱引用散列表。

新對象添加注冊操作 weak_register_no_lock

這一步與上一步相反,通過 weak_register_no_lock 函數把心的對象進行注冊操作,完成與對應的弱引用表進行綁定操作。

初始化弱引用對象流程一覽

弱引用的初始化,從上文的分析中可以看出,主要的操作部分就在弱引用表的取鍵、查詢散列、創建弱引用表等操作,可以總結出如下的流程圖:

C6029C92-5145-4334-9C25-3CDBA50F142B.png

這個圖中省略了很多情況的判斷,但是當聲明一個 __weak 會調用上圖中的這些方法。當然, storeWeak 方法不僅僅用在 __weak 的聲明中,在 class 內部的操作中也會常常通過該方法來對 weak 對象進行操作。

3、釋放時,調用clearDeallocating函數。clearDeallocating函數首先根據對象地址獲取所有weak指針地址的數組,然后遍歷這個數組把其中的數據設為nil,最后把這個entry從weak表中刪除,最后清理對象的記錄。

當weak引用指向的對象被釋放時,又是如何去處理weak指針的呢?當釋放對象時,其基本流程如下:

1、調用objc_release
2、因為對象的引用計數為0,所以執行dealloc
3、在dealloc中,調用了_objc_rootDealloc函數
4、在_objc_rootDealloc中,調用了object_dispose函數
5、調用objc_destructInstance
6、最后調用objc_clear_deallocating

重點看對象被釋放時調用的objc_clear_deallocating函數。該函數實現如下:

void  objc_clear_deallocating(id obj) 
{
    assert(obj);
    assert(!UseGC);
    if (obj->isTaggedPointer()) return;
   obj->clearDeallocating();
}

也就是調用了clearDeallocating,繼續追蹤可以發現,它最終是使用了迭代器來取weak表的value,然后調用weak_clear_no_lock,然后查找對應的value,將該weak指針置空,weak_clear_no_lock函數的實現如下:

/**
 * Called by dealloc; nils out all weak pointers that point to the
 * provided object so that they can no longer be used.
 *
 * @param weak_table
 * @param referent The object being deallocated.
 */
void weak_clear_no_lock(weak_table_t *weak_table, id referent_id)
{
    objc_object *referent = (objc_object *)referent_id;
    weak_entry_t *entry = weak_entry_for_referent(weak_table, referent);
    if (entry == nil) {
        /// XXX shouldn't happen, but does with mismatched CF/objc
        //printf("XXX no entry for clear deallocating %p\n", referent);
        return;
    }
    // zero out references
    weak_referrer_t *referrers;
    size_t count;
    
    if (entry->out_of_line) {
        referrers = entry->referrers;
        count = TABLE_SIZE(entry);
    }
    else {
        referrers = entry->inline_referrers;
        count = WEAK_INLINE_COUNT;
    }
    
    for (size_t i = 0; i < count; ++i) {
        objc_object **referrer = referrers[i];
        if (referrer) {
            if (*referrer == referent) {
                *referrer = nil;
            }
            else if (*referrer) {
                _objc_inform("__weak variable at %p holds %p instead of %p. "
                             "This is probably incorrect use of "
                             "objc_storeWeak() and objc_loadWeak(). "
                             "Break on objc_weak_error to debug.\n",
                             referrer, (void*)*referrer, (void*)referent);
                objc_weak_error();
            }
        }
    }
    weak_entry_remove(weak_table, entry);
}

objc_clear_deallocating該函數的動作如下:

1、從weak表中獲取廢棄對象的地址為鍵值的記錄
2、將包含在記錄中的所有附有 weak修飾符變量的地址,賦值為nil
3、將weak表中該記錄刪除
4、從引用計數表中刪除廢棄對象的地址為鍵值的記錄

看了objc-weak.mm的源碼就明白了:其實Weak表是一個hash(哈希)表,然后里面的key是指向對象的地址,Value是Weak指針的地址的數組。

補充:.m和.mm的區別

.m:源代碼文件,這個典型的源代碼文件擴展名,可以包含OC和C代碼。
.mm:源代碼文件,帶有這種擴展名的源代碼文件,除了可以包含OC和C代碼之外,還可以包含C++代碼。僅在你的OC代碼中確實需要使用C++類或者特性的時候才用這種擴展名。

參考資料:
weak 弱引用的實現方式
weak的生命周期:具體實現方法

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,818評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,185評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,656評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,647評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,446評論 6 405
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,951評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,041評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,189評論 0 287
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,718評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,602評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,800評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,316評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,045評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,419評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,671評論 1 281
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,420評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,755評論 2 371

推薦閱讀更多精彩內容