Objective-C runtime機制(6)——weak引用的底層實現原理

阿新 • • 發佈：2018-11-22

前言

提起弱引用，大家都知道它的作用：
（1）不會新增引用計數（2）當所引用的物件釋放後，引用者的指標自動置為nil
那麼，圍繞它背後的實現，是怎麼樣的呢？在許多公司面試時，都會問到這個問題。那麼，今天就帶大家一起分析一下weak引用是怎麼實現的，希望能夠搞清楚每一個細節。

Store as weak

當我們要weak引用一個物件，我們可以這麼做：

int main(int argc, char * argv[]) {
    @autoreleasepool {
        NSObject *obj = [[NSObject alloc] init];
        __weak NSObject *weakObj = obj;
    }
}

建立了一個NSObject物件obj，然後用weakObj對obj做弱引用。
當我們對一個物件做weak引用的時候，其背後是通過runtime來支援的。當把一個物件做weak引用時，會呼叫runtime方法objc_initWeak ：

objc_initWeak

id objc_initWeak(id *location, id newObj)
{
    if (!newObj) {
        *location = nil;
        return nil;
    }

    return storeWeak<DontHaveOld, DoHaveNew, DoCrashIfDeallocating>
        (location, (objc_object*)newObj);
}

該方法接受兩個引數：

id *location ：__weak指標的地址，即例子中的weak指標取地址： &weakObj 。它是一個指標的地址。
id newObj ：所引用的物件。即例子中的obj 。

有一個返回值 id ：會返回obj自身，但其值已經做了更改（isa_t中的weak_ref位置1），參見Objective-C runtime機制(5)——iOS 記憶體管理

objc_initWeak實質是呼叫了storeWeak方法。看這個方法的名字，就可以猜到是將weak引用存到某個地方，沒錯，實際上蘋果就是這麼做的。

storeWeak

storeWeak方法有點長，這也是weak引用的核心實現部分。其實核心也就實現了兩個功能：

將weak指標的地址location存入到obj對應的weak_entry_t的陣列（連結串列）中，用於在obj析構時，通過該陣列（連結串列）找到所有其weak指標引用，並將指標指向的地址（location）置為nil。關於weak_entry_t，在上一篇中已有介紹。
如果啟用了isa優化，則將obj的isa_t的weakly_referenced位置1。置位1的作用主要是為了標記obj被weak引用了，當dealloc時，runtime會根據weakly_referenced標誌位來判斷是否需要查詢obj對應的weak_entry_t，並將引用置為nil。

// Template parameters.
enum HaveOld { DontHaveOld = false, DoHaveOld = true };
enum HaveNew { DontHaveNew = false, DoHaveNew = true };
enum CrashIfDeallocating {
    DontCrashIfDeallocating = false, DoCrashIfDeallocating = true
};

template <HaveOld haveOld, HaveNew haveNew,
          CrashIfDeallocating crashIfDeallocating>
static id 
storeWeak(id *location, objc_object *newObj)
{
    assert(haveOld  ||  haveNew);
    if (!haveNew) assert(newObj == nil);

    Class previouslyInitializedClass = nil;
    id oldObj;
    SideTable *oldTable;
    SideTable *newTable;

    // Acquire locks for old and new values.
    // Order by lock address to prevent lock ordering problems. 
    // Retry if the old value changes underneath us.
 retry:
    if (haveOld) { // 如果weak ptr之前弱引用過一個obj，則將這個obj所對應的SideTable取出，賦值給oldTable
        oldObj = *location;
        oldTable = &SideTables()[oldObj];
    } else {
        oldTable = nil; // 如果weak ptr之前沒有弱引用過一個obj，則oldTable = nil
    }
    if (haveNew) { // 如果weak ptr要weak引用一個新的obj，則將該obj對應的SideTable取出，賦值給newTable
        newTable = &SideTables()[newObj];
    } else {
        newTable = nil; // 如果weak ptr不需要引用一個新obj，則newTable = nil
    }
    
    // 加鎖操作，防止多執行緒中競爭衝突
    SideTable::lockTwo<haveOld, haveNew>(oldTable, newTable);

    // location 應該與 oldObj 保持一致，如果不同，說明當前的 location 已經處理過 oldObj 可是又被其他執行緒所修改
    if (haveOld  &&  *location != oldObj) {
        SideTable::unlockTwo<haveOld, haveNew>(oldTable, newTable);
        goto retry;
    }

    // Prevent a deadlock between the weak reference machinery
    // and the +initialize machinery by ensuring that no 
    // weakly-referenced object has an un-+initialized isa.
    if (haveNew  &&  newObj) {
        Class cls = newObj->getIsa();
        if (cls != previouslyInitializedClass  &&  
            !((objc_class *)cls)->isInitialized())  // 如果cls還沒有初始化，先初始化，再嘗試設定weak
        {
            SideTable::unlockTwo<haveOld, haveNew>(oldTable, newTable);
            _class_initialize(_class_getNonMetaClass(cls, (id)newObj));

            // If this class is finished with +initialize then we're good.
            // If this class is still running +initialize on this thread 
            // (i.e. +initialize called storeWeak on an instance of itself)
            // then we may proceed but it will appear initializing and 
            // not yet initialized to the check above.
            // Instead set previouslyInitializedClass to recognize it on retry.
            previouslyInitializedClass = cls; // 這裡記錄一下previouslyInitializedClass， 防止改if分支再次進入

            goto retry; // 重新獲取一遍newObj，這時的newObj應該已經初始化過了
        }
    }

    // Clean up old value, if any.
    if (haveOld) {
        weak_unregister_no_lock(&oldTable->weak_table, oldObj, location); // 如果weak_ptr之前弱引用過別的物件oldObj，則呼叫weak_unregister_no_lock，在oldObj的weak_entry_t中移除該weak_ptr地址
    }

    // Assign new value, if any.
    if (haveNew) { // 如果weak_ptr需要弱引用新的物件newObj
        // (1) 呼叫weak_register_no_lock方法，將weak ptr的地址記錄到newObj對應的weak_entry_t中
        newObj = (objc_object *)
            weak_register_no_lock(&newTable->weak_table, (id)newObj, location, 
                                  crashIfDeallocating);
        // weak_register_no_lock returns nil if weak store should be rejected
        
        // (2) 更新newObj的isa的weakly_referenced bit標誌位
        // Set is-weakly-referenced bit in refcount table.
        if (newObj  &&  !newObj->isTaggedPointer()) {
            newObj->setWeaklyReferenced_nolock();
        }

        // Do not set *location anywhere else. That would introduce a race.
        // （3）*location 賦值，也就是將weak ptr直接指向了newObj。可以看到，這裡並沒有將newObj的引用計數+1
        *location = (id)newObj; // 將weak ptr指向object
    }
    else {
        // No new value. The storage is not changed.
    }
    
    // 解鎖，其他執行緒可以訪問oldTable, newTable了
    SideTable::unlockTwo<haveOld, haveNew>(oldTable, newTable);

    return (id)newObj; // 返回newObj，此時的newObj與剛傳入時相比，weakly-referenced bit位置1
}

下面我們就一起來分析下storeWeak方法。

storeWeak方法實質上接受5個引數，其中HaveOld haveOld, HaveNew haveNew, CrashIfDeallocating crashIfDeallocating 這三個引數是以模板列舉的方式傳入的，其實這是三個bool引數，分別表示：weak ptr之前是否已經指向了一個弱引用，weak ptr是否需要指向一個新引用，如果被弱引用的物件正在析構，此時再弱引用該物件，是否應該crash。

具體到objc_initWeak，這三個引數的值分別為false，true，true。

storeWeak 另外兩個引數是id *location, objc_object *newObj，這兩個引數和objc_initWeak是一樣的，分別代表weak 指標的地址，以及被weak引用的物件。

接下來函式體裡的內容，大家可以結合註釋，應該能夠看個明白。

這裡涉及到兩個關鍵的函式：

weak_unregister_no_lock  // 將 weak ptr地址 從obj的weak_entry_t中移除
weak_register_no_lock   // 將 weak ptr地址 註冊到obj對應的weak_entry_t中

這裡我們先看註冊函式：

weak_register_no_lock

id 
weak_register_no_lock(weak_table_t *weak_table, id referent_id, 
                      id *referrer_id, bool crashIfDeallocating)
{
    objc_object *referent = (objc_object *)referent_id;
    objc_object **referrer = (objc_object **)referrer_id;

    // 如果referent為nil 或 referent 採用了TaggedPointer計數方式，直接返回，不做任何操作
    if (!referent  ||  referent->isTaggedPointer()) return referent_id;

    // 確保被引用的物件可用（沒有在析構，同時應該支援weak引用）
    bool deallocating;
    if (!referent->ISA()->hasCustomRR()) {
        deallocating = referent->rootIsDeallocating();
    }
    else {
        BOOL (*allowsWeakReference)(objc_object *, SEL) = 
            (BOOL(*)(objc_object *, SEL))
            object_getMethodImplementation((id)referent, 
                                           SEL_allowsWeakReference);
        if ((IMP)allowsWeakReference == _objc_msgForward) {
            return nil;
        }
        deallocating =
            ! (*allowsWeakReference)(referent, SEL_allowsWeakReference);
    }
    // 正在析構的物件，不能夠被弱引用
    if (deallocating) {
        if (crashIfDeallocating) {
            _objc_fatal("Cannot form weak reference to instance (%p) of "
                        "class %s. It is possible that this object was "
                        "over-released, or is in the process of deallocation.",
                        (void*)referent, object_getClassName((id)referent));
        } else {
            return nil;
        }
    }

    // now remember it and where it is being stored
    // 在 weak_table中找到referent對應的weak_entry,並將referrer加入到weak_entry中
    weak_entry_t *entry;
    if ((entry = weak_entry_for_referent(weak_table, referent))) { // 如果能找到weak_entry,則講referrer插入到weak_entry中
        append_referrer(entry, referrer); 	// 將referrer插入到weak_entry_t的引用陣列中
    } 
    else { // 如果找不到，就新建一個
        weak_entry_t new_entry(referent, referrer);  
        weak_grow_maybe(weak_table);
        weak_entry_insert(weak_table, &new_entry);
    }

    // Do not set *referrer. objc_storeWeak() requires that the 
    // value not change.

    return referent_id;
}

注意看開頭的地方：

 // 如果referent為nil 或 referent 採用了TaggedPointer計數方式，直接返回，不做任何操作
    if (!referent  ||  referent->isTaggedPointer()) return referent_id;

這裡再次出現了taggedPointer的身影，若引用計數使用了taggedPointer，則不會做任何引用計數。

接著，會判斷referent_id是否能夠被weak 引用。這裡主要判斷referent_id是否正在被析構以及referent_id是否支援weak引用。如果referent_id不能夠被weak引用，則直接返回nil。

接下來，如果referent_id能夠被weak引用，則將referent_id對應的weak_entry_t從weak_table的weak_entry_t雜湊陣列中找出來,並將若

entry = weak_entry_for_referent(weak_table, referent)

如果entry不存在，則會新建一個referent_id所對應的weak_entry_t ：

    else { // 如果找不到，就新建一個
        weak_entry_t new_entry(referent, referrer);  // 建立一個新的weak_entry_t ，並將referrer插入到weak_entry_t的引用陣列中
        weak_grow_maybe(weak_table);  // weak_table的weak_entry_t 陣列是否需要動態增長，若需要，則會擴容一倍
        weak_entry_insert(weak_table, &new_entry); // 將weak_entry_t插入到weak_table中
    }

將referrer插入到對應的weak_entry_t的引用陣列後，我們的weak工作基本也就結束了。
最後，只需要返回被引用的物件即可：

return referent_id;

關於referrer是如何插入到weak_entry_t中的，其hash演算法是怎麼樣的，我們會在稍後的部分進行介紹。

weak_unregister_no_lock

如果weak ptr在指向obj之前，已經weak引用了其他的物件，則需要先將weak ptr從其他物件的weak_entry_t的hash陣列中移除。在storeWeak方法中，會呼叫weak_unregister_no_lock來做移除操作：

    if (haveOld) {
        weak_unregister_no_lock(&oldTable->weak_table, oldObj, location); // 如果weak_ptr之前弱引用過別的物件oldObj，則呼叫weak_unregister_no_lock，在oldObj的weak_entry_t中移除該weak_ptr地址
    }

weak_unregister_no_lock的實現如下：

void
weak_unregister_no_lock(weak_table_t *weak_table, id referent_id, 
                        id *referrer_id)
{
    objc_object *referent = (objc_object *)referent_id;
    objc_object **referrer = (objc_object **)referrer_id;

    weak_entry_t *entry;

    if (!referent) return;

    if ((entry = weak_entry_for_referent(weak_table, referent))) { // 查詢到referent所對應的weak_entry_t
        remove_referrer(entry, referrer);  // 在referent所對應的weak_entry_t的hash陣列中，移除referrer
       
        // 移除元素之後， 要檢查一下weak_entry_t的hash陣列是否已經空了
        bool empty = true;
        if (entry->out_of_line()  &&  entry->num_refs != 0) {
            empty = false;
        }
        else {
            for (size_t i = 0; i < WEAK_INLINE_COUNT; i++) {
                if (entry->inline_referrers[i]) {
                    empty = false; 
                    break;
                }
            }
        }

        if (empty) { // 如果weak_entry_t的hash陣列已經空了，則需要將weak_entry_t從weak_table中移除
            weak_entry_remove(weak_table, entry);
        }
    }

weak_unregister_no_lock的實現邏輯比較簡單。

首先，它會在weak_table中找出referent對應的weak_entry_t
在weak_entry_t中移除referrer
移除元素後，判斷此時weak_entry_t中是否還有元素（empty==true？）
如果此時weak_entry_t已經沒有元素了，則需要將weak_entry_t從weak_table中移除

OK，上面的所有就是當我們將一個obj作weak引用時，所發生的事情。那麼，當obj釋放時，所有weak引用它的指標又是如何自動設定為nil的呢？接下來我們來看一下obj釋放時，所發生的事情。

Dealloc

當物件引用計數為0時，runtime會呼叫_objc_rootDealloc方法來析構物件，實現如下：

void
_objc_rootDealloc(id obj)
{
    assert(obj);

    obj->rootDealloc();
}

它會呼叫objc_object的rootDealloc方法：

inline void
objc_object::rootDealloc()
{
    if (isTaggedPointer()) return;  // fixme necessary?

    if (fastpath(isa.nonpointer  &&  
                 !isa.weakly_referenced  &&  
                 !isa.has_assoc  &&  
                 !isa.has_cxx_dtor  &&  
                 !isa.has_sidetable_rc))
    {
        assert(!sidetable_present());
        free(this);
    } 
    else {
        object_dispose((id)this);
    }
}

rootDealloc的實現邏輯如下：

判斷object是否採用了Tagged Pointer計數，如果是，則不進行任何析構操作。關於這一點，我們可以看出，用Tagged Pointer計數的物件，是不會析構的。Tagged Pointer計數的物件在記憶體中應該是類似於字串常量的存在，多個物件指標其實會指向同一塊記憶體地址。雖然官方文件中並沒有提及，但可以推測，Tagged Pointer計數的物件的記憶體位置很有可以就位於字串常量區。
接下來判斷物件是否採用了優化的isa計數方式（isa.nonpointer）。如果是，則判斷是否能夠進行快速釋放（free(this) 用C函式釋放記憶體）。可以進行快速釋放的前提是：物件沒有被weak引用!isa.weakly_referenced，沒有關聯物件!isa.has_assoc，沒有自定義的C++析構方法!isa.has_cxx_dtor，沒有用到sideTable來做引用計數 !isa.has_sidetable_rc。
其餘的，則進入object_dispose((id)this)慢釋放分支。

如果obj被weak引用了，應該進入object_dispose((id)this)分支：

id 
object_dispose(id obj)
{
    if (!obj) return nil;

    objc_destructInstance(obj);    
    free(obj);

    return nil;
}

object_dispose方法中，會先呼叫objc_destructInstance(obj)來析構obj，再用 free(obj)來釋放記憶體。

objc_destructInstance的實現如下：

void *objc_destructInstance(id obj) 
{
    if (obj) {
        // Read all of the flags at once for performance.
        bool cxx = obj->hasCxxDtor();
        bool assoc = obj->hasAssociatedObjects();

        // This order is important.
        if (cxx) object_cxxDestruct(obj); // 呼叫C++解構函式
        if (assoc) _object_remove_assocations(obj); // 移除所有的關聯物件，並將其自身從Association Manager的map中移除
        obj->clearDeallocating(); // 清理相關的引用
    }
    return obj;
}

在objc_destructInstance 中，會清理相關的引用：obj->clearDeallocating() ：

inline void 
objc_object::clearDeallocating()
{
    if (slowpath(!isa.nonpointer)) {
        // Slow path for raw pointer isa.
        sidetable_clearDeallocating();
    }
    else if (slowpath(isa.weakly_referenced  ||  isa.has_sidetable_rc)) {
        // Slow path for non-pointer isa with weak refs and/or side table data.
        clearDeallocating_slow();
    }

    assert(!sidetable_present());
}

clearDeallocating中有兩個分支，先判斷obj是否採用了優化isa引用計數。沒有，則要清理obj儲存在sideTable中的引用計數等資訊，這個分支在當前64位裝置中應該不會進入，不必關係。
如果啟用了isa優化，則判斷是否使用了sideTable，使用的原因是因為做了weak引用（isa.weakly_referenced ）或使用了sideTable的輔助引用計數（isa.has_sidetable_rc）。符合這兩種情況之一，則進入慢析構路徑：

   // Slow path for non-pointer isa with weak refs and/or side table data.
        clearDeallocating_slow();

NEVER_INLINE void
objc_object::clearDeallocating_slow()
{
    assert(isa.nonpointer  &&  (isa.weakly_referenced || isa.has_sidetable_rc));

    SideTable& table = SideTables()[this]; // 在全域性的SideTables中，以this指標為key，找到對應的SideTable
    table.lock();
    if (isa.weakly_referenced) { // 如果obj被弱引用
        weak_clear_no_lock(&table.weak_table, (id)this); // 在SideTable的weak_table中對this進行清理工作
    }
    if (isa.has_sidetable_rc) { // 如果採用了SideTable做引用計數
        table.refcnts.erase(this); // 在SideTable的引用計數中移除this
    }
    table.unlock();
}

這裡呼叫了weak_clear_no_lock來做weak_table的清理工作，同時將所有weak引用該物件的ptr置為nil：

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); // 找到referent在weak_table中對應的weak_entry_t
    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;
    
    // 找出weak引用referent的weak 指標地址陣列以及陣列長度
    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]; // 取出每個weak ptr的地址
        if (referrer) {
            if (*referrer == referent) { // 如果weak ptr確實weak引用了referent，則將weak ptr設定為nil，這也就是為什麼weak 指標會自動設定為nil的原因
                *referrer = nil;
            }
            else if (*referrer) { // 如果所儲存的weak ptr沒有weak 引用referent，這可能是由於runtime程式碼的邏輯錯誤引起的，報錯
                _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); // 由於referent要被釋放了，因此referent的weak_entry_t也要移除出weak_table
}

OK，上面就是為什麼當物件析構時，所有弱引用該物件的指標都會被設定為nil的原因。

總結

縱觀weak引用的底層實現，其實原理很簡單。就是將所有弱引用obj的指標地址都儲存在obj對應的weak_entry_t中。當obj要析構時，會遍歷weak_entry_t中儲存的弱引用指標地址，並將弱引用指標指向nil，同時，將weak_entry_t移除出weak_table。

這裡涉及到runtime 四個重要的資料結構：
SideTables，SideTable，weak_table，weak_entry_t.

關於它們，我們在Objective-C runtime機制(5)——iOS 記憶體管理中已有涉及。

為了加深對runtime的理解，在接下來的一章中，我們會依次分析這四個資料結構。

補充

在文章的開頭，我們舉的例子：

int main(int argc, char * argv[]) {
    @autoreleasepool {
        NSObject *obj = [[NSObject alloc] init];
        __weak NSObject *weakObj = obj;
    }
}

它底層會呼叫objc_initWeak方法，並最終會呼叫

storeWeak<DontHaveOld, DoHaveNew, DoCrashIfDeallocating>
        (location, (objc_object*)newObj);

這是，傳入storeWeak的引數中，haveOld被設定為false，表明weakObj之前並沒有weak指向其他的物件。

那麼，什麼時候storeWeak的引數haveOld被設定為true呢？當我們的weakObj已經指向一個weak物件，又要指向新的weak物件時，storeWeak的haveOld引數會被置為true：

int main(int argc, char * argv[]) {
    @autoreleasepool {
        NSObject *obj = [[NSObject alloc] init];
        __weak NSObject *weakObj = obj; // 這裡會呼叫objc_initWeak方法，storeWeak的haveOld == false
        NSObject *obj2 = [[NSObject alloc] init];
        weakObj = obj2;  // 這裡會呼叫objc_storeWeak方法，storeWeak的haveOld == true，會將之前的引用先移除
    }
}

objc_storeWeak方法的實現如下：

/** 
 * This function stores a new value into a __weak variable. It would
 * be used anywhere a __weak variable is the target of an assignment.
 * 
 * @param location The address of the weak pointer itself
 * @param newObj The new object this weak ptr should now point to
 * 
 * @return \e newObj
 */
id
objc_storeWeak(id *location, id newObj)
{
    return storeWeak<DoHaveOld, DoHaveNew, DoCrashIfDeallocating>
        (location, (objc_object *)newObj);
}

Objective-C runtime機制(6)——weak引用的底層實現原理

前言

Store as weak

objc_initWeak

storeWeak

weak_register_no_lock

weak_unregister_no_lock

Dealloc

總結

補充

Objective-C runtime機制(6)——weak引用的底層實現原理

Objective-C runtime機制

Objective-C runtime機制(7)——SideTables, SideTable, weak_table, weak_entry_t

Objective-C runtime機制(5)——iOS 記憶體管理

Objective-C runtime機制(4)——深入理解Category

Objective-C runtime機制(3)——method swizzling

Objective-C runtime機制(2)——訊息機制

Objective-C runtime機制(1)——基本資料結構:objc_object & objc_class

Objective-C runtime機制(前傳2)——Mach-O格式和runtime

Objective-C runtime機制(前傳)——Mach-O格式

ios學習路線—Objective-C(Runtime訊息機制)

Objective-C Runtime 總結：訊息機制篇

Objective-C Runtime 文檔翻譯（一）—Runtime版本和平臺

Objective-C Runtime 執行時之五：協議與分類

Objective-C Runtime 執行時之六：拾遺

Objective C Runtime

Objective-C Runtime 執行時之一：類與物件

Objective-C Runtime 執行時之二：成員變數與屬性

Objective-C Runtime 執行時之三：方法與訊息

Objective-C Runtime 執行時之四：Method Swizzling

Objective-C runtime機制(6)——weak引用的底層實現原理

前言

Store as weak

objc_initWeak

storeWeak

weak_register_no_lock

weak_unregister_no_lock

Dealloc

總結

補充

相關推薦