objc源码解析|引用计数管理

通过以下方法查看iOS的引用计数管理:

  • alloc
  • retain
  • release
  • retainCount
  • dealloc

源码版本:objc4-723

alloc


+ (id)alloc {
    return _objc_rootAlloc(self);
}

id
_objc_rootAlloc(Class cls)
{
    return callAlloc(cls, false/*checkNil*/, true/*allocWithZone*/);
}

static ALWAYS_INLINE id
callAlloc(Class cls, bool checkNil, bool allocWithZone=false)
{
    if (slowpath(checkNil && !cls)) return nil;

#if __OBJC2__
    if (fastpath(!cls->ISA()->hasCustomAWZ())) {
        // No alloc/allocWithZone implementation. Go straight to the allocator.
        // fixme store hasCustomAWZ in the non-meta class and 
        // add it to canAllocFast's summary
        if (fastpath(cls->canAllocFast())) {
            // No ctors, raw isa, etc. Go straight to the metal.
            bool dtor = cls->hasCxxDtor();
            id obj = (id)calloc(1, cls->bits.fastInstanceSize());
            if (slowpath(!obj)) return callBadAllocHandler(cls);
            obj->initInstanceIsa(cls, dtor);
            return obj;
        }
        else {
            // Has ctor or raw isa or something. Use the slower path.
            id obj = class_createInstance(cls, 0);
            if (slowpath(!obj)) return callBadAllocHandler(cls);
            return obj;
        }
    }
#endif

    // No shortcuts available.
    if (allocWithZone) return [cls allocWithZone:nil];
    return [cls alloc];
}

当我们调用类的alloc方法时,调用的方法栈如上所示,我们来看最后一部分代码即可。

在这一部分代码中,有两个宏定义:

#define fastpath(x) (__builtin_expect(bool(x), 1))
#define slowpath(x) (__builtin_expect(bool(x), 0))

__builtin_expect的主要作用就是帮助编译器判断条件跳转的预期值,避免因执行jmp跳转指令造成时间浪费。

编译器优化时,根据条件跳转的预期值,按正确地顺序生成汇编代码,把“很有可能发生”的条件分支放在顺序执行指令段,而不是jmp指令段(jmp指令会打乱CPU的指令执行顺序,大大影响CPU指令执行效率)。
在本例中,if else句型编译后, 一个分支的汇编代码紧随前面的代码,而另一个分支的汇编代码需要使用jmp指令才能访问到,很明显通过jmp访问需要更多的时间, 在复杂的程序中,有很多的if else句型,又或者是一个有if else句型的库函数,每秒钟被调用几万次,通常程序员在分支预测方面做得很糟糕,编译器又不能精准的预测每一个分支,这时jmp产生的时间浪费就会很大,函数__builtin_expert()就是用来解决这个问题的。

所以,这里的逻辑就是如果slowpath(checkNil && !cls)0时,该函数返回nil,为1时走接下里的逻辑。

在接下来的逻辑中,fastpath(!cls->ISA()->hasCustomAWZ()首先会判断当前classsuper class是否实现了allocWithZone:方法(AWZAllocWithZone),如果没有实现这个方法,最终都会调用C语言函数calloc申请一块内存空间。

如果实现了AWZ方法,就会执行allocWithZone:

总结,调用alloc时,经过一系列方法调用,最终会在内存中申请一块内存空间,但此时并没有设置引用计数。

retain


- (id)retain {
    return ((id)self)->rootRetain();
}


ALWAYS_INLINE id 
objc_object::rootRetain()
{
    return rootRetain(false, false);
}

id
objc_object::sidetable_retain()
{
#if SUPPORT_NONPOINTER_ISA
    assert(!isa.nonpointer);
#endif
    SideTable& table = SideTables()[this];
    
    table.lock();
    size_t& refcntStorage = table.refcnts[this];
    if (! (refcntStorage & SIDE_TABLE_RC_PINNED)) {
        refcntStorage += SIDE_TABLE_RC_ONE;
    }
    table.unlock();

    return (id)this;
}

在上面代码块中,因为篇幅所限省去了rootRetain()的具体实现代码,在rootRetain()中实际上调用了sidetable_retain()方法,也就是最后那部分代码。

在了解最后一部分代码前,需要了解一些概念上的知识,有助于更好的理解系统对对象引用计数管理的实现原理。

为了管理所有对象的引用计数以及对象的所有弱引用指针,系统创建了一个全局的SideTablesSideTables里存的是一个个的SideTable,每个SideTable实际上都是一个结构体,如下:

struct SideTable {
    spinlock_t slock;
    RefcountMap refcnts;
    weak_table_t weak_table;

    //省略部分代码

SideTables本质上是一个全局的hash表,key值为对象的内存地址。
回到sidetable_retain()方法,首先会根据当前对象的指针到SideTables中获取SideTable

SideTable& table = SideTables()[this];

然后在SideTable的结构体当中获取当前对象的引用计数值:

size_t &refcntStorage = table.refcnts[this];

需要注意的是,这两次查找都是hash查找。
然后再对应用计数值进行+1操作:

refcntStorage += SIDE_TABLE_RC_ONE;

以上,就是进行retain操作时,系统对对象引用计数操作的具体实现。

release


- (oneway void)release {
    ((id)self)->rootRelease();
}

ALWAYS_INLINE bool 
objc_object::rootRelease()
{
    return rootRelease(true, false);
}

uintptr_t
objc_object::sidetable_release(bool performDealloc)
{
#if SUPPORT_NONPOINTER_ISA
    assert(!isa.nonpointer);
#endif
    SideTable& table = SideTables()[this];

    bool do_dealloc = false;

    table.lock();
    RefcountMap::iterator it = table.refcnts.find(this);
    if (it == table.refcnts.end()) {
        do_dealloc = true;
        table.refcnts[this] = SIDE_TABLE_DEALLOCATING;
    } else if (it->second < SIDE_TABLE_DEALLOCATING) {
        // SIDE_TABLE_WEAKLY_REFERENCED may be set. Don't change it.
        do_dealloc = true;
        it->second |= SIDE_TABLE_DEALLOCATING;
    } else if (! (it->second & SIDE_TABLE_RC_PINNED)) {
        it->second -= SIDE_TABLE_RC_ONE;
    }
    table.unlock();
    if (do_dealloc  &&  performDealloc) {
        ((void(*)(objc_object *, SEL))objc_msgSend)(this, SEL_dealloc);
    }
    return do_dealloc;
}

篇幅所限,省略了rootRelease()的代码实现,在rootRelease()中会调用sidetable_release(),也就是最后一部分代码,我们可以将最后一部分代码进行简化,简化后的代码如下所示:

SideTable &table = SideTables()[this];
RefcountMap ::iterator it = table.refcnts.find(this);
it->second -= SIDE_TABLE_RC_ONE;

首先根据对象的内存地址到hash表中查找SideTable

SideTable &table = SideTables()[this];

然后根据查找到的SideTable和对象的内存地址获取其引用计数并-1

RefcountMap ::iterator it = table.refcnts.find(this);
it->second -= SIDE_TABLE_RC_ONE;

另外,当对象需要被回收时,系统还会利用objc_msgSend向对象发送dealloc消息。

以上,就是进行release操作时,系统对对象引用计数操作的具体实现。

retainCount


- (NSUInteger)retainCount {
    return ((id)self)->rootRetainCount();
}


inline uintptr_t 
objc_object::rootRetainCount()
{
    if (isTaggedPointer()) return (uintptr_t)this;

    sidetable_lock();
    isa_t bits = LoadExclusive(&isa.bits);
    ClearExclusive(&isa.bits);
    if (bits.nonpointer) {
        uintptr_t rc = 1 + bits.extra_rc;
        if (bits.has_sidetable_rc) {
            rc += sidetable_getExtraRC_nolock();
        }
        sidetable_unlock();
        return rc;
    }

    sidetable_unlock();
    return sidetable_retainCount();
}

uintptr_t
objc_object::sidetable_retainCount()
{
    SideTable& table = SideTables()[this];

    size_t refcnt_result = 1;
    
    table.lock();
    RefcountMap::iterator it = table.refcnts.find(this);
    if (it != table.refcnts.end()) {
        // this is valid for SIDE_TABLE_RC_PINNED too
        refcnt_result += it->second >> SIDE_TABLE_RC_SHIFT;
    }
    table.unlock();
    return refcnt_result;
}

这里把retainCount方法调用栈的全部代码都贴出来了,主要来看最后一部分代码,也就是sidetable_retainCount()方法的代码。

我们也可以带着一个问题来看这段代码,问题是:

为什么刚创建完的对象,它的retainCount0

在这个方法的实现中,首先会根据对象的内存地址获取到SideTable

SideTable& table = SideTables()[this];

然后紧接着声明了一个局部变量refcnt_result,值为1

size_t refcnt_result = 1;

所以,刚alloc出来的对象,在引用计数表(SideTables)中是没有这个对象的key-value映射的,所以table.refcnts.find(this)读出来的值是0,所以如果这里是0,就将局部变量refcnt_result的值返回,也即是1

如果table.refcnts.find(this)读出来的值不是0,则会把查找的结果做向右偏移的操作然后+1,返回给调用方:

refcnt_result += it->second >> SIDE_TABLE_RC_SHIFT;

以上,就是进行retainCount操作时,系统对获取对象引用计数的具体实现原理。

dealloc


- (void)dealloc {
    _objc_rootDealloc(self);
}

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

    obj->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);
    }
}

以上是dealloc的方法调用栈,从最后一个方法开始看,在这个方法中有一个if判断条件比较多:

  • 首先判断有没有使用非指针型isanonpointer_isa
  • 判断是否有weak指针指向它
  • 判断是否有关联对象
  • 判断内部实现是否涉及到有C++相关的内容
  • 当前对象的引用计数是否是通过SideTable来维护的

只有当当前对象既不是nonpointer_isa,也没有弱引用,还没有涉及到C++、关联对象、没有使用SideTable存储相关引用计数,才会调用C函数free()进行释放,否则,就调用object_dispose()对象清除函数进行清除。

再来看object_dispose()函数的实现:

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

    objc_destructInstance(obj);    
    free(obj);

    return nil;
}


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);
        if (assoc) _object_remove_assocations(obj);
        obj->clearDeallocating();
    }

    return obj;
}

先来看objc_destructInstance函数,如果obj对象存在的话,会先判断当前对象是否有用到涉及到C++相关的东西,如果有,稍后会调用object_cxxDestruct函数进行销毁操作。

还会判断当前对象是否拥有关联对象,如果有的话稍后就会调用_object_remove_assocations函数进行清除操作,所以我们并不需要在dealloc方法中显式的清除关联对象。

最后会调用objclearDeallocating函数,函数实现如下:

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());
}

其会调用两个函数,分别是:

  • sidetable_clearDeallocating()
  • clearDeallocating_slow()

(1)sidetable_clearDeallocating()函数实现如下:

void 
objc_object::sidetable_clearDeallocating()
{
    SideTable& table = SideTables()[this];

    // clear any weak table items
    // clear extra retain count and deallocating bit
    // (fixme warn or abort if extra retain count == 0 ?)
    table.lock();
    RefcountMap::iterator it = table.refcnts.find(this);
    if (it != table.refcnts.end()) {
        if (it->second & SIDE_TABLE_WEAKLY_REFERENCED) {
            weak_clear_no_lock(&table.weak_table, (id)this);
        }
        table.refcnts.erase(it);
    }
    table.unlock();
}

其中还会调用weak_clear_no_lock()函数,实现如下:

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);
}

weak_clear_no_lock函数有两个参数,weak_tablereferent_id

weak_table就是弱引用表,记录了指向该对象的弱引用指针。

referent_id就是当前正在被销毁的对象。

这里会把referent_id强转成objc_object类型的结构体指针,记做referent,根据referentweak_table中获取entry,进而通过weak_entry_t获取弱引用数组referrers,绕后遍历这个referrers数组,将指向该对象的弱引用指针全部置为nil,最后从weak_table中把这个entry删除。

所以,当一个对象有一个弱引用指针指向它的时候,当这个对象被废弃之后它的弱引用指针会被自动置为nil

(2)clearDeallocating_slow()函数实现如下:

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

    SideTable& table = SideTables()[this];
    table.lock();
    if (isa.weakly_referenced) {
        weak_clear_no_lock(&table.weak_table, (id)this);
    }
    if (isa.has_sidetable_rc) {
        table.refcnts.erase(this);
    }
    table.unlock();
}

table.refcnts.erase(this);函数的主要作用是从引用计数表中擦除该对象的引用计数。

总结一下,当对象被释放时,也就是在系统的dealloc方法实现中,系统会销毁该对象所使用的C++相关的内容,还会删除该对象的关联对象,并且将指向该对象的弱引用指针全部置为nil,这些操作完成后,会从全局的引用计数表中擦除该对象的引用计数。

以上,就是dealloc的实现原理。

内存管理方案


分类

  • TaggedPointer
    针对于小对象,如NSNumber、NSDate等。
  • NONPOINTER_ISA
    对于64位架构下的应用程序采用这种内存管理方案,在64位架构下,ISA指针占64个bit位,实际上有32位或40位就够用了,剩余的是浪费的,Apple为了提高内存的利用率,在剩余的bit位当中存储一些关于内存管理的数据内容,也被称为非指针型的isa。
  • 散列表
    包括引用计数表和弱引用表。

NONPOINTER_ISA

arm64架构
arm64架构
  • indexed
    0:代表它是一个纯的isa指针,里面的内容直接代表当前对象的类对象的地址。
    1:代表isa指针里面存储的不仅是类对象的地址,还有一些内存管理的数据。
  • has_assoc
    当前对象是否有关联对象
    0:没有
    1:有
  • has_cxx_dtor
    当前对象是否有使用到C++语言方面的内容
  • 后续33位
    当前对象的类对象的指针地址
  • magic
    略,不影响分析
  • weakly_referenced
    当前对象是否有弱引用指针
  • deallocating
    表示当前对象是否在进行dealloc操作
  • has_sidetable_rc
    指当前isa指针当中如果所存储的引用计数已经达到了上限的话,需要外挂一个sidetable这样的数据结构去存储相关的引用计数内容。
  • extra_rc
    额外的引用计数,当引用计数在一个很小的值得范围内就会存到isa指针当中,而不是由单独的引用计数表去存储引用计数,

散列表方式

struct SideTable {
    spinlock_t slock;
    RefcountMap refcnts;
    weak_table_t weak_table;

    SideTable() {
        memset(&weak_table, 0, sizeof(weak_table));
    }

    ~SideTable() {
        _objc_fatal("Do not delete SideTable.");
    }

    void lock() { slock.lock(); }
    void unlock() { slock.unlock(); }
    void forceReset() { slock.forceReset(); }

    // Address-ordered lock discipline for a pair of side tables.

    template<HaveOld, HaveNew>
    static void lockTwo(SideTable *lock1, SideTable *lock2);
    template<HaveOld, HaveNew>
    static void unlockTwo(SideTable *lock1, SideTable *lock2);
};

在非嵌入式系统中,SideTables管理着64个SideTable,每个SideTable有3个元素:

  • spinlock_t自旋锁
  • RefcountMap引用计数表
  • weak_table_t弱引用表

为什么不是一个SideTable,而是由多个SideTable组成SideTables

如果使用一个SideTable管理系统所有对象的引用计数,那么当我们在多线程中对其中一个对象进行retainrelease等操作时就会对这个SideTable加锁,以此保证数据访问的安全,那么在这个过程中实际上就产生了效率的问题,下一个对象要想进行操作(比如修改引用计数),就必须要等锁释放只会才能操作这张表,如果成千上万个对象同操作一张表,那么效率是极其低下的。

系统为了解决效率低下的问题,系统引入了分离锁的技术方案,我们可以把对象所对应的引用计数表可以分拆成多个部分,比如可以分拆成8个,那么就会对8个表分别加锁,假如A对象属于表1,B对象属于表2,那么此时就可以进行并行操作,提高了访问效率。

如何实现快速分流?

指通过一个对象的指针,如何快速定位到它属于哪张SideTable

SideTable的本质是一张Hash表,这张Hash表中可能有64张具体的SideTable用以存储不同对象的引用计数表和弱引用表。

Hash表的key是对象指针经过hash函数计算出一个值,这个值决定对象所属的SideTable是哪一个,或者说在数组中(SideTables)的位置是第几个。

Hash查找

eg:给定值是对象的内存地址,目标值是数组(SideTables)下标索引。

f(ptr) = (uintptr_t)ptr % array.count

其他涉及到的技术


  • spinlock_t slock;自旋锁
  • RefcountMap refcnts;引用计数表
  • weak_table_t weak_table;弱引用表

spinlock_t

  • 自旋锁是一种忙等的锁,指当前锁已经被其他线程获取,当前线程会不断探测这个锁是否有被释放,如果被释放掉自己会第一时间获取这个锁。
    • 信号量是如果获取不到这个锁的时候,会把自己线程进行阻塞休眠,等到其他线程释放这个锁的时候唤醒当前线程。
  • 适用于轻量访问,因为对于引用计数的操作只是简单的+1 -1操作,这种操作都是轻量的操作,所以在轻量的访问场景下,都可以使用自旋锁。

RefcountMap

实际上是一个Hash表,可以通过对象的指针查找到对应的引用计数,查找的过程也是哈希查找,提高查找效率。

  • size_t共有64位
    • 第一位是weakly_referenced,表示对象是否有弱引用,0就是没有,1就是有。
    • 第二位是deallocating,表示当前对象是否正在dealloc
    • 其余位存储的就是对象的实际引用计数值,具体的引用计数值实际上要偏移两位,因为前面有两位是weakly_referenceddeallocating,我们要把这两位去掉。

weak_table_t

实际上也是一张Hash表,key为对象指针,valueweak_entry_tweak_entry_t是一个结构体数组,数组存储的每一个对象就是弱引用指针,也就是在代码中定义的__weak变量,这个变量的指针就存储在weak_entry_t中。

完。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,393评论 5 467
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,790评论 2 376
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,391评论 0 330
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,703评论 1 270
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,613评论 5 359
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,003评论 1 275
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,507评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,158评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,300评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,256评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,274评论 1 328
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,984评论 3 316
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,569评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,662评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,899评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,268评论 2 345
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,840评论 2 339

推荐阅读更多精彩内容