黑箱中的 retain 和 release

关注仓库,及时获得更新:iOS-Source-Code-Analyze

Follow: Draveness · Github

由于 Objective-C 中的内存管理是一个比较大的话题,所以会分为两篇文章来对内存管理中的一些机制进行剖析,一部分分析自动释放池以及 autorelease 方法,另一部分分析 retainrelease 方法的实现以及自动引用计数。

写在前面

在接口设计时,我们经常要考虑某些意义上的平衡。在内存管理中也是这样,Objective-C 同时为我们提供了增加引用计数的 retain 和减少引用计数的 release 方法。

这篇文章会在源代码层面介绍 Objective-C 中 retainrelease 的实现,它们是如何达到平衡的。

从 retain 开始

如今我们已经进入了全面使用 ARC 的时代,几年前还经常使用的 retainrelease 方法已经很难出现于我们的视野中了,绝大多数内存管理的实现细节都由编译器代劳。

在这里,我们还要从 retain 方法开始,对内存管理的实现细节一探究竟。

下面是 retain 方法的调用栈:

- [NSObject retain]
└── id objc_object::rootRetain()
    └── id objc_object::rootRetain(bool tryRetain, bool handleOverflow)
        ├── uintptr_t LoadExclusive(uintptr_t *src)
        ├── uintptr_t addc(uintptr_t lhs, uintptr_t rhs, uintptr_t carryin, uintptr_t *carryout)
        ├── uintptr_t bits
        │   └── uintptr_t has_sidetable_rc  
        ├── bool StoreExclusive(uintptr_t *dst, uintptr_t oldvalue, uintptr_t value)
        └── bool objc_object::sidetable_addExtraRC_nolock(size_t delta_rc)                
            └── uintptr_t addc(uintptr_t lhs, uintptr_t rhs, uintptr_t carryin, uintptr_t *carryout)

调用栈中的前两个方法的实现直接调用了下一个方法:

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

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

id objc_object::rootRetain(bool tryRetain, bool handleOverflow) 方法是调用栈中最重要的方法,其原理就是将 isa 结构体中的 extra_rc 的值加一。

extra_rc 就是用于保存自动引用计数的标志位,下面就是 isa 结构体中的结构:

objc-rr-isa-struct

接下来我们会分三种情况对 rootRetain 进行分析。

正常的 rootRetain

这是简化后的 rootRetain 方法的实现,其中只有处理一般情况的代码:

id objc_object::rootRetain(bool tryRetain, bool handleOverflow) {
    isa_t oldisa;
    isa_t newisa;

    do {
        oldisa = LoadExclusive(&isa.bits);
        newisa = oldisa;

        uintptr_t carry;
        newisa.bits = addc(newisa.bits, RC_ONE, 0, &carry);
    } while (!StoreExclusive(&isa.bits, oldisa.bits, newisa.bits));

    return (id)this;
}

在这里我们假设的条件是 isa 中的 extra_rc 的位数足以存储 retainCount

  1. 使用 LoadExclusive 加载 isa 的值
  2. 调用 addc(newisa.bits, RC_ONE, 0, &carry) 方法将 isa 的值加一
  3. 调用 StoreExclusive(&isa.bits, oldisa.bits, newisa.bits) 更新 isa 的值
  4. 返回当前对象

有进位版本的 rootRetain

在这里调用 addc 方法为 extra_rc 加一时,8 位的 extra_rc 可能不足以保存引用计数。

id objc_object::rootRetain(bool tryRetain, bool handleOverflow) {
    transcribeToSideTable = false;
    isa_t oldisa = LoadExclusive(&isa.bits);
    isa_t newisa = oldisa;

    uintptr_t carry;
    newisa.bits = addc(newisa.bits, RC_ONE, 0, &carry);

    if (carry && !handleOverflow)
        return rootRetain_overflow(tryRetain);
}

extra_rc 不足以保存引用计数,并且 handleOverflow = false

当方法传入的 handleOverflow = false 时(这也是通常情况),我们会调用 rootRetain_overflow 方法:

id objc_object::rootRetain_overflow(bool tryRetain) {
    return rootRetain(tryRetain, true);
}

这个方法其实就是重新执行 rootRetain 方法,并传入 handleOverflow = true

有进位版本的 rootRetain(处理溢出)

当传入的 handleOverflow = true 时,我们就会在 rootRetain 方法中处理引用计数的溢出。

id objc_object::rootRetain(bool tryRetain, bool handleOverflow) {
    bool sideTableLocked = false;

    isa_t oldisa;
    isa_t newisa;

    do {
        oldisa = LoadExclusive(&isa.bits);
        newisa = oldisa;
        uintptr_t carry;
        newisa.bits = addc(newisa.bits, RC_ONE, 0, &carry);

        if (carry) {
            newisa.extra_rc = RC_HALF;
            newisa.has_sidetable_rc = true;
        }
    } while (!StoreExclusive(&isa.bits, oldisa.bits, newisa.bits));

    sidetable_addExtraRC_nolock(RC_HALF);

    return (id)this;
}

当调用这个方法,并且 handleOverflow = true 时,我们就可以确定 carry 一定是存在的了,

因为 extra_rc 已经溢出了,所以要更新它的值为 RC_HALF

#define RC_HALF (1ULL<<7)

extra_rc 总共为 8 位,RC_HALF = 0b10000000

然后设置 has_sidetable_rc 为真,存储新的 isa 的值之后,调用 sidetable_addExtraRC_nolock 方法。

bool objc_object::sidetable_addExtraRC_nolock(size_t delta_rc) {
    SideTable& table = SideTables()[this];

    size_t& refcntStorage = table.refcnts[this];
    size_t oldRefcnt = refcntStorage;

    if (oldRefcnt & SIDE_TABLE_RC_PINNED) return true;

    uintptr_t carry;
    size_t newRefcnt = 
        addc(oldRefcnt, delta_rc << SIDE_TABLE_RC_SHIFT, 0, &carry);
    if (carry) {
        refcntStorage = SIDE_TABLE_RC_PINNED | (oldRefcnt & SIDE_TABLE_FLAG_MASK);
        return true;
    } else {
        refcntStorage = newRefcnt;
        return false;
    }
}

这里我们将溢出的一位 RC_HALF 添加到 oldRefcnt 中,其中的各种 SIDE_TABLE 宏定义如下:

#define SIDE_TABLE_WEAKLY_REFERENCED (1UL<<0)
#define SIDE_TABLE_DEALLOCATING      (1UL<<1)
#define SIDE_TABLE_RC_ONE            (1UL<<2)
#define SIDE_TABLE_RC_PINNED         (1UL<<(WORD_BITS-1))

#define SIDE_TABLE_RC_SHIFT 2
#define SIDE_TABLE_FLAG_MASK (SIDE_TABLE_RC_ONE-1)

因为 refcnts 中的 64 为的最低两位是有意义的标志位,所以在使用 addc 时要将 delta_rc 左移两位,获得一个新的引用计数 newRefcnt

如果这时出现了溢出,那么就会撤销这次的行为。否则,会将新的引用计数存储到 refcntStorage 指针中。


也就是说,在 iOS 的内存管理中,我们使用了 isa 结构体中的 extra_rcSideTable 来存储某个对象的自动引用计数。

更重要的是,如果自动引用计数为 1,extra_rc 实际上为 0,因为它保存的是额外的引用计数,我们通过这个行为能够减少很多不必要的函数调用。

到目前为止,我们已经从头梳理了 retain 方法的调用栈及其实现。下面要介绍的是在内存管理中,我们是如何使用 release 方法平衡这个方法的。

以 release 结束

与 release 方法相似,我们看一下这个方法简化后的调用栈:

- [NSObject release]
└── id objc_object::rootRelease()
    └── id objc_object::rootRetain(bool performDealloc, bool handleUnderflow)

前面的两个方法的实现和 retain 中的相差无几,这里就直接跳过了。

同样,在分析 release 方法时,我们也根据上下文的不同,将 release 方法的实现拆分为三部分,说明它到底是如何调用的。

正常的 release

这一个版本的方法调用可以说是最简版本的方法调用了:

bool objc_object::rootRelease(bool performDealloc, bool handleUnderflow) {
    isa_t oldisa;
    isa_t newisa;

    do {
        oldisa = LoadExclusive(&isa.bits);
        newisa = oldisa;

        uintptr_t carry;
        newisa.bits = subc(newisa.bits, RC_ONE, 0, &carry);
    } while (!StoreReleaseExclusive(&isa.bits, oldisa.bits, newisa.bits));

    return false;
}
  1. 使用 LoadExclusive 获取 isa 内容
  2. isa 中的引用计数减一
  3. 调用 StoreReleaseExclusive 方法保存新的 isa

从 SideTable 借位

接下来,我们就要看两种相对比较复杂的情况了,首先是从 SideTable 借位的版本:

bool objc_object::rootRelease(bool performDealloc, bool handleUnderflow) {
    isa_t oldisa;
    isa_t newisa;

    do {
        oldisa = LoadExclusive(&isa.bits);
        newisa = oldisa;

        uintptr_t carry;
        newisa.bits = subc(newisa.bits, RC_ONE, 0, &carry);
        if (carry) goto underflow;
    } while (!StoreReleaseExclusive(&isa.bits, oldisa.bits, newisa.bits));
    
    ...

 underflow:
    newisa = oldisa;

    if (newisa.has_sidetable_rc) {
        if (!handleUnderflow) {
            return rootRelease_underflow(performDealloc);
        }

        size_t borrowed = sidetable_subExtraRC_nolock(RC_HALF);

        if (borrowed > 0) {
            newisa.extra_rc = borrowed - 1;
            bool stored = StoreExclusive(&isa.bits, oldisa.bits, newisa.bits);

            return false;
        } 
    }
}

这里省去了使用锁来防止竞争条件以及调用 StoreExclusive 失败后恢复现场的代码。
我们会默认这里存在 SideTable,也就是 has_sidetable_rc = true

你可以看到,这里也有一个 handleUnderflow,与 retain 中的相同,如果发生了 underflow,会重新调用该 rootRelease 方法,并传入 handleUnderflow = true

在调用 sidetable_subExtraRC_nolock 成功借位之后,我们会重新设置 newisa 的值 newisa.extra_rc = borrowed - 1 并更新 isa

release 中调用 dealloc

如果在 SideTable 中也没有获取到借位的话,就说明没有任何的变量引用了当前对象(即 retainCount = 0),就需要向它发送 dealloc 消息了。

bool objc_object::rootRelease(bool performDealloc, bool handleUnderflow) {
    isa_t oldisa;
    isa_t newisa;

 retry:
    do {
        oldisa = LoadExclusive(&isa.bits);
        newisa = oldisa;

        uintptr_t carry;
        newisa.bits = subc(newisa.bits, RC_ONE, 0, &carry);
        if (carry) goto underflow;
    } while (!StoreReleaseExclusive(&isa.bits, oldisa.bits, newisa.bits));

    ...

 underflow:
    newisa = oldisa;

    if (newisa.deallocating) {
        return overrelease_error();
    }
    newisa.deallocating = true;
    StoreExclusive(&isa.bits, oldisa.bits, newisa.bits);

    if (performDealloc) {
        ((void(*)(objc_object *, SEL))objc_msgSend)(this, SEL_dealloc);
    }
    return true;
}

上述代码会直接调用 objc_msgSend 向当前对象发送 dealloc 消息。

不过为了确保消息只会发送一次,我们使用 deallocating 标记位。

获取自动引用计数

在文章的最结尾,笔者想要介绍一下 retainCount 的值是怎么计算的,我们直接来看 retainCount 方法的实现:

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

inline uintptr_t objc_object::rootRetainCount() {
    isa_t bits = LoadExclusive(&isa.bits);
    uintptr_t rc = 1 + bits.extra_rc;
    if (bits.has_sidetable_rc) {
        rc += sidetable_getExtraRC_nolock();
    }
    return rc;
}

根据方法的实现,retainCount 有三部分组成:

  • 1
  • extra_rc 中存储的值
  • sidetable_getExtraRC_nolock 返回的值

这也就证明了我们之前得到的结论。

小结

我们在这篇文章中已经介绍了 retainrelease 这一对用于内存管理的方法是如何实现的,这里总结一下文章一下比较重要的问题。

  • extra_rc 只会保存额外的自动引用计数,对象实际的引用计数会在这个基础上 +1
  • Objective-C 使用 isa 中的 extra_rcSideTable 来存储对象的引用计数
  • 在对象的引用计数归零时,会调用 dealloc 方法回收对象

有关于自动释放池实现的介绍,可以看自动释放池的前世今生

关注仓库,及时获得更新:iOS-Source-Code-Analyze

Follow: Draveness · Github

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

推荐阅读更多精彩内容