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

前言

提起弱引用,大家都知道它的作用:
(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它是一個指針的地址。之所以要存儲指針的地址,是因為最后我們要講__weak指針指向的內容置為nil,如果僅存儲指針的話,是不能夠完成這個功能的。
  • 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_tweakly_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,這三個參數的值分別為falsetruetrue

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_tweak_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算法是怎么樣的,利用函數append_referrer:

static void append_referrer(weak_entry_t *entry, objc_object **new_referrer)
{
    if (! entry->out_of_line()) { // 如果weak_entry 尚未使用動態數組,走這里
        // Try to insert inline.
        for (size_t i = 0; i < WEAK_INLINE_COUNT; i++) {
            if (entry->inline_referrers[i] == nil) {
                entry->inline_referrers[i] = new_referrer;
                return;
            }
        }
        
        // 如果inline_referrers的位置已經存滿了,則要轉型為referrers,做動態數組。
        // Couldn't insert inline. Allocate out of line.
        weak_referrer_t *new_referrers = (weak_referrer_t *)
            calloc(WEAK_INLINE_COUNT, sizeof(weak_referrer_t));
        // This constructed table is invalid, but grow_refs_and_insert
        // will fix it and rehash it.
        for (size_t i = 0; i < WEAK_INLINE_COUNT; i++) {
            new_referrers[i] = entry->inline_referrers[i];
        }
        entry->referrers = new_referrers;
        entry->num_refs = WEAK_INLINE_COUNT;
        entry->out_of_line_ness = REFERRERS_OUT_OF_LINE;
        entry->mask = WEAK_INLINE_COUNT-1;
        entry->max_hash_displacement = 0;
    }

    // 對于動態數組的附加處理:
    assert(entry->out_of_line()); // 斷言: 此時一定使用的動態數組

    if (entry->num_refs >= TABLE_SIZE(entry) * 3/4) { // 如果動態數組中元素個數大于或等于數組位置總空間的3/4,則擴展數組空間為當前長度的一倍
        return grow_refs_and_insert(entry, new_referrer); // 擴容,并插入
    }
    
    // 如果不需要擴容,直接插入到weak_entry中
    // 注意,weak_entry是一個哈希表,key:w_hash_pointer(new_referrer) value: new_referrer
    
    // 細心的人可能注意到了,這里weak_entry_t 的hash算法和 weak_table_t的hash算法是一樣的,同時擴容/減容的算法也是一樣的
    size_t begin = w_hash_pointer(new_referrer) & (entry->mask); // '& (entry->mask)' 確保了 begin的位置只能大于或等于 數組的長度
    size_t index = begin;  // 初始的hash index
    size_t hash_displacement = 0;  // 用于記錄hash沖突的次數,也就是hash再位移的次數
    while (entry->referrers[index] != nil) {
        hash_displacement++;
        index = (index+1) & entry->mask;  // index + 1, 移到下一個位置,再試一次能否插入。(這里要考慮到entry->mask取值,一定是:0x111, 0x1111, 0x11111, ... ,因為數組每次都是*2增長,即8, 16, 32,對應動態數組空間長度-1的mask,也就是前面的取值。)
        if (index == begin) bad_weak_table(entry); // index == begin 意味著數組繞了一圈都沒有找到合適位置,這時候一定是出了什么問題。
    }
    if (hash_displacement > entry->max_hash_displacement) { // 記錄最大的hash沖突次數, max_hash_displacement意味著: 我們嘗試至多max_hash_displacement次,肯定能夠找到object對應的hash位置
        entry->max_hash_displacement = hash_displacement;
    }
    // 將ref存入hash數組,同時,更新元素個數num_refs
    weak_referrer_t &ref = entry->referrers[index];
    ref = new_referrer;
    entry->num_refs++;
}

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的實現邏輯比較簡單。

  1. 首先,它會在weak_table中找出referent對應的weak_entry_t
  2. 在weak_entry_t中移除referrer
  3. 移除元素后,判斷此時weak_entry_t中是否還有元素 (empty==true?)
  4. 如果此時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_objectrootDealloc方法:

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的實現邏輯如下:

  1. 判斷object是否采用了Tagged Pointer計數,如果是,則不進行任何析構操作。關于這一點,我們可以看出,用Tagged Pointer計數的對象,是不會析構的。Tagged Pointer計數的對象在內存中應該是類似于字符串常量的存在,多個對象指針其實會指向同一塊內存地址。雖然官方文檔中并沒有提及,但可以推測,Tagged Pointer計數的對象的內存位置很有可以就位于字符串常量區。
  2. 接下來判斷對象是否采用了優化的isa計數方式(isa.nonpointer)。如果是,則判斷是否能夠進行快速釋放(free(this) 用C函數釋放內存)。可以進行快速釋放的前提是:對象沒有被weak引用!isa.weakly_referenced,沒有關聯對象!isa.has_assoc,沒有自定義的C++析構方法!isa.has_cxx_dtor,沒有用到sideTable來做引用計數 !isa.has_sidetable_rc
  3. 其余的,則進入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 四個重要的數據結構:
SideTablesSideTableweak_tableweak_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);
}
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,501評論 6 544
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,673評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,610評論 0 383
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,939評論 1 318
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,668評論 6 412
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 56,004評論 1 329
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 44,001評論 3 449
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 43,173評論 0 290
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,705評論 1 336
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,426評論 3 359
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,656評論 1 374
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,139評論 5 364
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,833評論 3 350
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,247評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,580評論 1 295
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,371評論 3 400
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,621評論 2 380

推薦閱讀更多精彩內容