iOS Dealloc流程解析 Dealloc 实现原理

当对象的引用计数为0时, 系统会调用对象的dealloc方法释放

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

在内部

void
_objc_rootDealloc(id obj)
{
    assert(obj);
    obj->rootDealloc();
}

继续调用了rootDealloc方法

显然调用顺序为:先调用当前类的dealloc,然后调用父类的dealloc,最后到了NSObject的dealloc.

inline void
objc_object::rootDealloc()
{
    //判断对象是否采用了Tagged Pointer技术
    if (isTaggedPointer()) return;  // fixme necessary?
    //判断是否能够进行快速释放
    //这里使用了isa指针里的属性来进行判断.
    if (fastpath(isa.nonpointer  &&  //对象是否采用了优化的isa计数方式
                 !isa.weakly_referenced  &&  //对象没有被弱引用
                 !isa.has_assoc  &&  //对象没有关联对象
                 !isa.has_cxx_dtor  &&  //对象没有自定义的C++析构函数
                 !isa.has_sidetable_rc  //对象没有用到sideTable来做引用计数
                 ))
    {
        //如果以上判断都符合条件,就会调用C函数 free 将对象释放
        assert(!sidetable_present());
        free(this);
    } 
    else {
        //如果以上判断没有通过,做下一步处理
        object_dispose((id)this);
    }
}

内部做了一些判断, 如果满足这五个条件,直接调用free函数,进行内存释放.

当一个最简单的类(没有任何成员变量,没有任何引用的类),这五个判断条件都是成立的,直接free.

id 
object_dispose(id obj)
{
    if (!obj) return nil;
    
    objc_destructInstance(obj);    
    free(obj);
    
    return nil;
}

调用objc_destructInstance函数来析构对象obj,再free(obj)释放内存.

objc_destructInstance内部函数会销毁C++析构函数以及移除关联对象的操作.

继续调用objc_object的clearDeallocating函数做下一步处理

objc_object::clearDeallocating()
{
    if (slowpath(!isa.nonpointer)) {
        // Slow path for raw pointer isa.
        // 如果要释放的对象没有采用了优化过的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.
        // 如果要释放的对象采用了优化过的isa引用计数,并且有弱引用或者使用了sideTable的辅助引用计数
        clearDeallocating_slow();
   }
    assert(!sidetable_present());
}

根据是否采用了优化过的isa做引用计数分为两种:

  1. 要释放的对象没有采用优化过的isa引用计数:

会调用sidetable_clearDeallocating() 函数做进一步处理

void 
objc_object::sidetable_clearDeallocating()
{
    // 在全局的SideTables中,以this指针(要释放的对象)为key,找到对应的SideTable
    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();
    //在散列表SideTable中找到对应的引用计数表RefcountMap,拿到要释放的对象的引用计数
    RefcountMap::iterator it = table.refcnts.find(this);
    if (it != table.refcnts.end()) {
        //如果要释放的对象被弱引用了,通过weak_clear_no_lock函数将指向该对象的弱引用指针置为nil
        if (it->second & SIDE_TABLE_WEAKLY_REFERENCED) {
            weak_clear_no_lock(&table.weak_table, (id)this);
        }
        //从引用计数表中擦除该对象的引用计数
        table.refcnts.erase(it);
    }

    table.unlock();
}
  1. 如果该对象采用了优化过的isa引用计数

并且该对象有弱引用或者使用了sideTable的辅助引用计数,就会调用clearDeallocating_slow()函数做进一步处理.

NEVER_INLINE void

objc_object::clearDeallocating_slow()

{
    assert(isa.nonpointer  &&  (isa.weakly_referenced || isa.has_sidetable_rc));

    // 在全局的SideTables中,以this指针(要释放的对象)为key,找到对应的SideTable
    SideTable& table = SideTables()[this];
    table.lock();
    if (isa.weakly_referenced) {
        //要释放的对象被弱引用了,通过weak_clear_no_lock函数将指向该对象的弱引用指针置为nil
        weak_clear_no_lock(&table.weak_table, (id)this);
    }
    //使用了sideTable的辅助引用计数,直接在SideTable中擦除该对象的引用计数
    if (isa.has_sidetable_rc) {
        table.refcnts.erase(this);
    }
    table.unlock();
}

以上两种情况都涉及weak_clear_no_lock函数, 它的作用就是将被弱引用对象的弱引用指针置为nil.

void 

weak_clear_no_lock(weak_table_t *weak_table, id referent_id) 

{
    //获取被弱引用对象的地址
    objc_object *referent = (objc_object *)referent_id;
    // 根据对象地址找到被弱引用对象referent在weak_table中对应的weak_entry_t
    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;
    
    // 找出弱引用该对象的所有weak指针地址数组
    if (entry->out_of_line()) {
        referrers = entry->referrers;
        count = TABLE_SIZE(entry);
    } 
    else {
        referrers = entry->inline_referrers;
        count = WEAK_INLINE_COUNT;
    }
    // 遍历取出每个weak指针的地址
    for (size_t i = 0; i < count; ++i) {
        objc_object **referrer = referrers[i]; 
        if (referrer) {
            // 如果weak指针确实弱引用了对象 referent,则将weak指针设置为nil
            if (*referrer == referent) { 
                *referrer = nil;
            }
            // 如果所存储的weak指针没有弱引用对象 referent,这可能是由于runtime代码的逻辑错误引起的,报错
            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修饰的对象在释放时, 所有弱引用该对象的指针都被设置为nil.
dealloc整个方法释放流程如下图:


img

看流程图发现,如果五个条件不满足.内存无法进行快速释放.在上面中,我看到博客里关于 objc_destructInstance 这个方法只是概述而过,所以我找了相关资料来了解一下.

void *objc_destructInstance(id obj) 
{
    if (obj) {
        Class isa_gen = _object_getClass(obj);
        class_t *isa = newcls(isa_gen);


        // Read all of the flags at once for performance.
        bool cxx = hasCxxStructors(isa);
        bool assoc = !UseGC && _class_instancesHaveAssociatedObjects(isa_gen);


        // This order is important.
        if (cxx) object_cxxDestruct(obj);
        if (assoc) _object_remove_assocations(obj);
        
        if (!UseGC) objc_clear_deallocating(obj);
    }
    return obj;
}

总共干了三件事::

  1. 执行了object_cxxDestruct 函数
  2. 执行_object_remove_assocations,去除了关联对象.(这也是为什么category添加属性时,在释放时没有必要remove)
  3. 就是上面写的那个,清空引用计数表并清除弱引用表,将weak指针置为nil
    object_cxxDestruct是由编译器生成,这个方法原本是为了++对象析构,ARC借用了这个方法插入代码实现了自动内存释放的工作.

这个释放.
现象:

  1. 当类拥有实例变量时,这个方法会出现,且父类的实例变量不会导致子类拥有这个方法.
  2. 出现这个方法和变量是否被赋值,赋值成什么没有关系.

所以, 我们可以认为这个方法就是用来释放该类中的属性的. weak修饰的属性应该不包含在内。

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

推荐阅读更多精彩内容

  • 前言 我们知道一个对象即将释放的时候会进入到dealloc方法中,通常也是通过dealloc是否回调来检测循环引用...
    初心丶可曾记阅读 2,294评论 0 3
  • 我们知道weak是弱引用,指向的对象的计数器不会加一,并且在该对象释放的时候会被置为nil。通常用来解决循环引用的...
    丶啊桑阅读 652评论 0 1
  • 本文源自本人的学习记录整理与理解,其中参考阅读了部分优秀的博客和书籍,尽量以通俗简单的语句转述。引用到的地方如有遗...
    水中的蓝天阅读 5,189评论 3 16
  • 我是前言 目前正在看 oc 底层的东西,看了许多大牛的博客,发现有一些小问题: runtime 的版本可能跟作者当...
    kikido阅读 692评论 0 1
  • 前言 今天我们大致分析下内存管理相关的底层原理等知识点,分为包括内存布局和内存管理方案两大块,其中内存管理方案会重...
    深圳_你要的昵称阅读 388评论 0 2