iOS-内存管理5-引用计数、__weak原理

一. 引用计数

1. 引用计数存储在哪

我们都知道，调用retain会让OC对象的引用计数+1，调用release会让OC对象的引用计数-1，那么引用计数存储在哪里呢？

其实在isa存储信息分析中已经讲过了，在64bit中，引用计数可以直接存储在优化过的isa指针中，也可能存储在SideTable结构体中。

  1. 如果引用计数不大(不大于19)，会存储在isa的extra_rc中，其中rc是retainCount的意思。
  2. 如果引用计数过大，isa中的has_sidetable_rc就为1，引用计数就存储在一个叫SideTable的结构体的refcnts成员中，refcnts是个散列表。

isa_t共用体结构如下：

union isa_t
{
    Class cls;
    uintptr_t bits;
# if __arm64__
#   define ISA_MASK        0x0000000ffffffff8ULL
#   define ISA_MAGIC_MASK  0x000003f000000001ULL
#   define ISA_MAGIC_VALUE 0x000001a000000001ULL
    struct {
        //0，代表普通的指针，存储着Class、Meta-Class对象的内存地址
        //1，代表优化过，使用位域存储更多的信息
        uintptr_t nonpointer        : 1; 
        //是否有设置过关联对象，如果没有，释放时会更快
        uintptr_t has_assoc         : 1;
        //是否有C++的析构函数（.cxx_destruct），如果没有，释放时会更快
        uintptr_t has_cxx_dtor      : 1;
        //存储着Class、Meta-Class对象的内存地址信息
        uintptr_t shiftcls          : 33;
        //用于在调试时分辨对象是否未完成初始化
        uintptr_t magic             : 6;
        //是否有被弱引用指向过，如果没有，释放时会更快
        uintptr_t weakly_referenced : 1;
        //对象是否正在释放
        uintptr_t deallocating      : 1;
        //引用计数是否过大无法存储在isa中
        //如果为1，那么引用计数会存储在一个叫SideTable的结构体的refcnts成员中，refcnts是个散列表
        uintptr_t has_sidetable_rc  : 1;
        //里面存储的值是引用计数减1
        uintptr_t extra_rc          : 19;
    };
};

2. 查看retainCount源码

打开objc4源码，找到NSObject.mm文件，找到 retainCount 方法：

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

objc_object::rootRetainCount()
{
    //如果是TaggedPointer就意味着不是OC对象，就返回它自己
    if (isTaggedPointer()) return (uintptr_t)this;

    sidetable_lock();
    isa_t bits = LoadExclusive(&isa.bits); //拿到isa本身
    ClearExclusive(&isa.bits);
    if (bits.nonpointer) { //如果是非指针类型(就是优化过的isa)
        uintptr_t rc = 1 + bits.extra_rc; //直接将extra_rc加1，然后返回的就是引用计数
        if (bits.has_sidetable_rc) { //如果有SideTable
            rc += sidetable_getExtraRC_nolock(); //就从SideTable拿到引用计数
        }
        sidetable_unlock();
        return rc; //然后返回
    }

    sidetable_unlock();
    return sidetable_retainCount();
}

从上面代码可以看出，如果是优化过的isa，extra_rc+1就是引用计数，如果有SideTable，就从SideTable拿到引用计数，从SideTable拿到的引用计数加上extra_rc+1就是总的引用计数。

再进入sidetable_getExtraRC_nolock()函数，看看是如何在SideTable中拿到引用计数的，如下：

objc_object::sidetable_getExtraRC_nolock()
{
    assert(isa.nonpointer);
    //获取SideTable
    SideTable& table = SideTables()[this]; 
    //拿到table里的的refcnts(就是个散列表)，然后通过find获取一个遍历器
    RefcountMap::iterator it = table.refcnts.find(this); 
    if (it == table.refcnts.end()) return 0;
    //取得遍历器里的second，然后进行一次位运算，之后就把这个值返回了
    else return it->second >> SIDE_TABLE_RC_SHIFT; 
}

进入SideTable：

struct SideTable {
    spinlock_t slock;
    RefcountMap refcnts; //引用计数表(散列表)
    weak_table_t weak_table; //弱引用表(散列表)
}

根据上面两段代码可以知道，先获取SideTable，再拿到SideTable里的refcnts(就是个散列表)，引用计数就存储在这个refcnts散列表中，在refcnts散列表中拿到引用计数，再做一次位运算就获取到引用计数的值了。

3. 查看release源码

再看看 release 方法，从NSObject.mm -> release -> rootRelease -> sidetable_release，进入sidetable_release函数：

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

    bool do_dealloc = false;

    table.lock();
    //拿到table里的的refcnts(就是个散列表)，然后通过find获取一个遍历器
    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)) {
        //引用计数减去SIDE_TABLE_RC_ONE这个值
        it->second -= SIDE_TABLE_RC_ONE;
    }
    table.unlock();
    //如果需要调用dealloc，就给自己发送dealloc消息
    if (do_dealloc  &&  performDealloc) {
        ((void(*)(objc_object *, SEL))objc_msgSend)(this, SEL_dealloc);
    }
    return do_dealloc;
}

上面代码可以看注释。

  1. 先看倒数第二个注释：“引用计数减去SIDE_TABLE_RC_ONE这个值”，说明release方法的确有做引用计数减一的操作。
  2. 再看最后一个注释：“如果需要调用dealloc，就给自己发送dealloc消息”，以前我们说过，如果release之后引用计数为0，对象就会被销毁，这里也从源代码中证明了我们以前说的话是对的。

4. 查看retain源码

再看看 retain 方法，从NSObject.mm -> retain -> rootRetain -> sidetable_retain，进入sidetable_retain函数：

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)) {
        //引用计数加上SIDE_TABLE_RC_ONE这个值
        refcntStorage += SIDE_TABLE_RC_ONE; 
    }
    table.unlock();

    return (id)this;
}

上面代码也可以看出retain方法的确有做引用计数加一的操作。

二. __weak的原理

1. __strong、__weak、__unsafe_unretained的区别

① __strong

运行如下代码：

- (void)viewDidLoad {
    [super viewDidLoad];

    __strong MJPerson *person1;
//    __weak MJPerson *person1;
//    __unsafe_unretained MJPerson *person1;
    
    NSLog(@"111");
    {
        //什么都不加，默认强指针，就相当于加一个__strong
        MJPerson *person = [[MJPerson alloc] init]; 
        //引用计数：1    __strong
        //引用计数：1    __weak
        //引用计数：1    __unsafe_unretained
        
        person1 = person; 
        //引用计数：2    __strong
        //引用计数：1    __weak
        //引用计数：1    __unsafe_unretained


    } //引用计数：1    __strong
      //引用计数：0    __weak
      //引用计数：0    __unsafe_unretained
    NSLog(@"222");

    NSLog(@"%p",person1);
    NSLog(@"%@",person1);
} //引用计数：0    __strong  这行代码之后，对象才被释放

打印：

111
222
0x6000001ed290
<MJPerson: 0x6000001ed290>
-[MJPerson dealloc]

可以发现，当使用强指针指着，viewDidLoad代码执行完，对象才被释放，你也可以看上面引用计数分析的注释，这也和我们预期的结果一样。

② __weak

打开注释，将person1改成__weak类型，重新运行代码，打印：

111
-[MJPerson dealloc]
222
0x0
(null)

dealloc方法在111和222之间打印，说明在{}执行完，对象就被释放了，这时候打印指针的值为0x0，指针指向的内容为null。
这是因为用__weak修饰，引用计数器不会加一，在{}执行完之后，对象的引用计数为0，对象被释放，指针被清空(person1 = nil)。

③ __unsafe_unretained

打开注释，将person1改成__unsafe_unretained类型，重新运行代码后崩溃，提示坏内存访问：

Thread 1: EXC_BAD_ACCESS (code=EXC_I386_GPFLT)

打印：

111
-[MJPerson dealloc]
222
0x6000005382f0
(lldb)

上面打印，前面三行和__weak没什么区别，第四行打印的地址有值，说明指针没被清空，最后一行崩溃了，提示坏内存访问，说明指针指向的地址已经被系统回收了。
这是因为使用__unsafe_unretained修饰，引用计数器不会加一，在{}执行完之后，对象的引用计数为0，对象被释放，对象的内存被回收，指针不会被清空，所以这时候通过指针访问指向的对象就会报坏内存访问错误。

2. 源码分析__weak原理

当一个对象要释放时，会自动调用dealloc，从NSObject.mm ->dealloc ->_objc_rootDealloc ->rootDealloc，进入rootDealloc函数：

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

    if (fastpath(isa.nonpointer  &&  //是优化过的isa
                 !isa.weakly_referenced  &&  //没有被弱引用指向过
                 !isa.has_assoc  &&  //没有设置过关联对象
                 !isa.has_cxx_dtor  &&  //没有C++的析构函数
                 !isa.has_sidetable_rc)) //没有SlideTable
    {
        assert(!sidetable_present());
        free(this); //释放自己
    } 
    else {
        object_dispose((id)this); //如果上面条件不满足，就处理
    }
}

上面代码很容易理解，如果是优化过的isa，并且没有被弱引用指向过、没有设置过关联对象、没有C++的析构函数、没有SlideTable就会直接调用free(this)提前释放掉自己。
如果条件不满足，会进入object_dispose函数：

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

    objc_destructInstance(obj);  //处理对象的其他事情
    free(obj); //然后释放自己

    return nil;
}

这个函数可以看出，如果条件不满足，会先做一些事情，然后释放掉自己。
进入objc_destructInstance函数：

void *objc_destructInstance(id obj) 
{
    if (obj) {
        bool cxx = obj->hasCxxDtor();
        bool assoc = obj->hasAssociatedObjects();

        if (cxx) object_cxxDestruct(obj); //清除成员变量
        if (assoc) _object_remove_assocations(obj);//移除关联对象
        obj->clearDeallocating(); //将指向当前对象的弱指针置为nil
    }

    return obj;
}

看最后一行注释，clearDeallocating函数将指向当前对象的弱指针置为nil。
进入clearDeallocating函数：

objc_object::clearDeallocating()
{
    if (slowpath(!isa.nonpointer)) { //普通isa指针
        sidetable_clearDeallocating();
    }
    //优化过的isa指针
    else if (slowpath(isa.weakly_referenced  ||  isa.has_sidetable_rc)) {
        clearDeallocating_slow();
    }

    assert(!sidetable_present());
}

进入clearDeallocating_slow函数：

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

    //获取SideTable
    SideTable& table = SideTables()[this]; 
    table.lock();
    if (isa.weakly_referenced) {
        //取出SideTable的弱引用表，将当前对象传进去，把当前对象的弱引用清除
        weak_clear_no_lock(&table.weak_table, (id)this); 
    }
    //如果还有引用计数再把引用计数清除
    if (isa.has_sidetable_rc) {
        table.refcnts.erase(this);
    }
    table.unlock();
}

weak_clear_no_lock函数就是清空当前对象的弱引用，后面就不往下跟了。

可以发现，当一个对象要销毁，会自动调用dealloc，就会取出对象的SideTable中的弱引用表(散列表)，然后将弱引用表里面存储的弱引用都给清除掉。

SideTable结构如下：

struct SideTable {
    spinlock_t slock;
    RefcountMap refcnts; //引用计数表(散列表)
    weak_table_t weak_table; //弱引用表(散列表)
}

三. 面试题

1. __weak指针的实现原理？

当一个对象要销毁，会自动调用dealloc，就会取出对象的SideTable中的弱引用表(散列表)，然后将弱引用表里面存储的弱引用都给清除掉。

2. ARC都帮我们做了什么？

① ARC是LLVM编译器和Runtime系统相互协作的一个结果。
② ARC利用LLVM编译器自动帮我们生成retain、release这些代码。
③ __weak弱引用这样的存在是需要Runtime的支持的，是在程序运行过程中监控到对象要销毁的时候就会把这个对象对应的弱引用都给清除掉，这个我们从Runtime源码也能看出来。

Demo地址：__weak

3. 解释一下，什么时候用weak，什么时候用assgin？
  1. ARC之后才有weak，weak是弱指针，当使用weak关键字修饰成员变量的时候，成员变量内部是用__weak修饰的，不会让引用计数器+1，如果指向对象被销毁，指针会自动清空，就不会报坏内存访问了。
  2. 当使用assgin修饰的时候，内部是用__unsafe_unretained修饰的，不会让引用计数器+1，如果指向对象被销毁，指针不会清空，如果这时候访问对象的指针，就会有坏内存访问错误，如下图;
坏内存访问错误.png

示例代码如下：

#import "ViewController.h"
 
@interface ViewController ()
@property (nonatomic, assign 或 weak ) UIView *redView;
@end
 
@implementation ViewController
 
- (void)viewDidLoad {
    [super viewDidLoad];
   
    UIView *view = [[UIView alloc] init];
    view.backgroundColor = [UIColor redColor];
    _redView = view;

    // 如果注释掉下面的代码，点击屏幕的时候是不会有view出现的，因为view是局部变量，{}之后就被销毁了
    [self.view addSubview:view];
}

// 如果使用weak修饰，点击屏幕不会报错，因为view被销毁之后，指针也会自动清空，所以不会报坏内存访问错误
// 如果是assign修饰，view被销毁之后，指针不会被清空，点击屏幕，执行代码_redView.frame = CGRectMake(50, 50, 200, 200);通过指针访问对象，但是这时候对象已经被销毁了，所以就会报坏内存访问错误
- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event
{
    _redView.frame = CGRectMake(50, 50, 200, 200);
}
@end
4. weak内部实现原理？

Runtime维护了一个weak表（SideTable中的弱引用表，是个散列表），用于存储指向某个对象的所有weak指针。weak表其实是一个hash（哈希）表，Key是所指对象的地址，Value是weak指针的地址（这个地址的值是所指对象的地址）数组。

  1. 初始化时：runtime会调用objc_initWeak函数，初始化一个新的weak指针指向对象的地址。
  2. 添加引用时：objc_initWeak函数会调用 objc_storeWeak() 函数， objc_storeWeak() 的作用是更新指针指向，创建对应的弱引用表。
  3. 释放时，调用clearDeallocating函数。clearDeallocating函数首先根据对象地址获取所有weak指针地址的数组，然后遍历这个数组把其中的数据设为nil，最后把这个entry从weak表中删除，最后清理对象的记录。

SideTable结构如下：

struct SideTable {
    spinlock_t slock;
    RefcountMap refcnts; //引用计数表(散列表)
    weak_table_t weak_table; //弱引用表(散列表)
}

追问：当weak引用指向的对象被释放时，又是如何去处理weak指针的呢？

  1. 当一个对象要释放时，会自动调用dealloc
  2. 在dealloc中，调用了_objc_rootDealloc函数
  3. 在_objc_rootDealloc中，调用了object_dispose函数
  4. 调用objc_destructInstance函数
  5. 最后调用clearDeallocating函数，将指向当前对象的弱指针置为nil，详细过程如下：
    a：从weak表中获取废弃对象的地址为键值的记录
    b：将包含在记录中的所有附有weak修饰符变量的地址，赋值为nil
    c：将weak表中该记录删除
    d：从引用计数表中删除废弃对象的地址为键值的记录
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念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

推荐阅读更多精彩内容