Objective-C 引用计数原理

前言

  • 本文所使用的源码为 objc4-647 和 CF-1153.18
  • 不讲用法，只说原理。

引用计数如何存储

有些对象如果支持使用 TaggedPointer，苹果会直接将其指针值作为引用计数返回；如果当前设备是 64 位环境并且使用 Objective-C 2.0，那么“一些”对象会使用其isa指针的一部分空间来存储它的引用计数；否则 Runtime 会使用一张散列表来管理引用计数。

其实还有一种情况会改变引用计数的存储策略，那就是是否使用垃圾回收（用UseGC属性判断），但这种早已弃用的东西就不要管了，而且初始化垃圾回收机制的 void gc_init(BOOL wantsGC)方法一直被传入 NO。

TaggedPointer

判断当前对象是否在使用 TaggedPointer 是看标志位是否为 1 ：

#if SUPPORT_MSB_TAGGED_POINTERS
#   define TAG_MASK (1ULL<<63)
#else
#   define TAG_MASK 1

inline bool 
objc_object::isTaggedPointer() 
{
#if SUPPORT_TAGGED_POINTERS
    return ((uintptr_t)this & TAG_MASK);
#else
    return false;
#endif
}

id其实就是objc_object *的简写（typedef struct objc_object *id;），它的 isTaggedPointer()方法经常会在操作引用计数时用到，因为这决定了存储引用计数的策略。

isa 指针（NONPOINTER_ISA）

用64 bit存储一个内存地址显然是种浪费，毕竟很少有那么大内存的设备。
于是可以优化存储方案，用一部分额外空间存储其他内容。
isa指针第一位为 1即表示使用优化的isa 指针，这里列出不同架构下的 64位环境中 isa 指针结构：

union isa_t 
{
    isa_t() { }
    isa_t(uintptr_t value) : bits(value) { }

    Class cls;
    uintptr_t bits;

#if SUPPORT_NONPOINTER_ISA
# if __arm64__
#   define ISA_MASK        0x00000001fffffff8ULL
#   define ISA_MAGIC_MASK  0x000003fe00000001ULL
#   define ISA_MAGIC_VALUE 0x000001a400000001ULL
    struct {
        uintptr_t indexed           : 1;
        uintptr_t has_assoc         : 1;
        uintptr_t has_cxx_dtor      : 1;
        uintptr_t shiftcls          : 30; // MACH_VM_MAX_ADDRESS 0x1a0000000
        uintptr_t magic             : 9;
        uintptr_t weakly_referenced : 1;
        uintptr_t deallocating      : 1;
        uintptr_t has_sidetable_rc  : 1;
        uintptr_t extra_rc          : 19;
#       define RC_ONE   (1ULL<<45)
#       define RC_HALF  (1ULL<<18)
    };

# elif __x86_64__
#   define ISA_MASK        0x00007ffffffffff8ULL
#   define ISA_MAGIC_MASK  0x0000000000000001ULL
#   define ISA_MAGIC_VALUE 0x0000000000000001ULL
    struct {
        uintptr_t indexed           : 1;
        uintptr_t has_assoc         : 1;
        uintptr_t has_cxx_dtor      : 1;
        uintptr_t shiftcls          : 44; // MACH_VM_MAX_ADDRESS 0x7fffffe00000
        uintptr_t weakly_referenced : 1;
        uintptr_t deallocating      : 1;
        uintptr_t has_sidetable_rc  : 1;
        uintptr_t extra_rc          : 14;
#       define RC_ONE   (1ULL<<50)
#       define RC_HALF  (1ULL<<13)
    };

# else
    // Available bits in isa field are architecture-specific.
#   error unknown architecture
# endif

// SUPPORT_NONPOINTER_ISA
#endif

};

SUPPORT_NONPOINTER_ISA 用于标记是否支持优化的isa指针，其字面含义意思是 isa 的内容不再是类的指针了，而是包含了更多信息，
比如引用计数，析构状态，被其他 weak 变量引用情况。判断方法也是根据设备类型：

// Define SUPPORT_NONPOINTER_ISA=1 to enable extra data in the isa field.
#if !__LP64__  ||  TARGET_OS_WIN32  ||  TARGET_IPHONE_SIMULATOR  ||  __x86_64__
#   define SUPPORT_NONPOINTER_ISA 0
#else
#   define SUPPORT_NONPOINTER_ISA 1
#endif

综合看来目前只有 arm64 架构的设备支持，下面列出了 isa 指针中变量对应的含义：

在 64 位环境下，优化的 isa指针并不是就一定会存储引用计数，毕竟用 19bit （iOS 系统）保存引用计数不一定够。需要注意的是这 19 位保存的是引用计数的值减一。has_sidetable_rc 的值如果为 1，那么引用计数会存储在一个叫 SideTable的类的属性中，后面会详细讲。

散列表 （Hash table）

散列表来存储引用计数具体是用DenseMap 类来实现，这个类中包含好多映射实例到其引用计数的键值对，并支持用 DenseMapIterator迭代器快速查找遍历这些键值对。

接着说键值对的格式：键的类型为DisguisedPtr<objc_object>，DisguisedPtr 类是对 objc_object *指针及其一些操作进行的封装，目的就是为了让它给人看起来不会有内存泄露的样子（真是心机裱），其内容可以理解为对象的内存地址；值的类型为__darwin_size_t，在 darwin 内核一般等同于 unsigned long。其实这里保存的值也是等于引用计数减一。使用散列表保存引用计数的设计很好，即使出现故障导致对象的内存块损坏，只要引用计数表没有被破坏，依然可以顺藤摸瓜找到内存块的位置。

之前说引用计数表是个散列表，这里简要说下散列的方法。有个专门处理键的 DenseMapInfo 结构体，它针对 DisguisedPtr做了些优化匹配键值速度的方法：

struct DenseMapInfo<DisguisedPtr<T>> {
  static inline DisguisedPtr<T> getEmptyKey() {
    return DisguisedPtr<T>((T*)(uintptr_t)-1);
  }
  static inline DisguisedPtr<T> getTombstoneKey() {
    return DisguisedPtr<T>((T*)(uintptr_t)-2);
  }
  static unsigned getHashValue(const T *PtrVal) {
      return ptr_hash((uintptr_t)PtrVal);
  }
  static bool isEqual(const DisguisedPtr<T> &LHS, const DisguisedPtr<T> &RHS) {
      return LHS == RHS; 
  }
};

当然这里的哈希算法会根据是否为 64 位平台来进行优化，算法具体细节就不深究了，我总觉得苹果在这里的 hardcode 是随便写的：

#if __LP64__
static inline uint32_t ptr_hash(uint64_t key)
{
    key ^= key >> 4;
    key *= 0x8a970be7488fda55;
    key ^= __builtin_bswap64(key);
    return (uint32_t)key;
}
#else
static inline uint32_t ptr_hash(uint32_t key)
{
    key ^= key >> 4;
    key *= 0x5052acdb;
    key ^= __builtin_bswap32(key);
    return key;
}
#endif
SideTable
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);
};

再介绍下 SideTable这个类，它用于管理引用计数表和weak表，并使用 spinlock_lock自旋锁来防止操作表结构时可能的竞态条件。它用一个 64*128 大小的 uint8_t 静态数组作为 buffer 来保存所有的 SideTable 实例。并提供三个公有属性：

spinlock_t slock;//保证原子操作的自选锁
RefcountMap refcnts;//保存引用计数的散列表
weak_table_t weak_table;//保存 weak 引用的全局散列表

还提供了一个工厂方法，用于根据对象的地址在 buffer 中寻找对应的 SideTable 实例：

static SideTable *tableForPointer(const void *p)

weak表的作用是在对象执行 dealloc的时候将所有指向该对象的weak 指针的值设为 nil，避免悬空指针。这是 weak 表的结构：

struct weak_table_t {
    weak_entry_t *weak_entries;
    size_t    num_entries;
    uintptr_t mask;
    uintptr_t max_hash_displacement;
};

苹果使用一个全局的 weak表来保存所有的 weak引用。并将对象作为键，weak_entry_t作为值。weak_entry_t中保存了所有指向该对象的weak指针。

获取引用计数

在非 ARC 环境可以使用retainCount 方法获取某个对象的引用计数，其会调用objc_object 的rootRetainCount()方法：

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

在 ARC 时代除了使用Core Foundation库的CFGetRetainCount()方法，也可以使用 Runtime 的 _objc_rootRetainCount(id obj)方法来获取引用计数，此时需要引入 <objc/runtime.h>头文件。这个函数也是调用 objc_object的rootRetainCount()方法：

uintptr_t
objc_object::sidetable_retainCount()
{
    SideTable *table = SideTable::tableForPointer(this);

    size_t refcnt_result = 1;
    
    spinlock_lock(&table->slock);
    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;
    }
    spinlock_unlock(&table->slock);
    return refcnt_result;
}

sidetable_retainCount()方法的逻辑就是先从 SideTable 的静态方法获取当前实例对应的SideTable 对象，其refcnts属性就是之前说的存储引用计数的散列表，这里将其类型简写为RefcountMap：

typedef objc::DenseMap<DisguisedPtr<objc_object>,size_t,true> RefcountMap;

然后在引用计数表中用迭代器查找当前实例对应的键值对，获取引用计数值，并在此基础上 +1 并将结果返回。这也就是为什么之前说引用计数表存储的值为实际引用计数减一。

需要注意的是为什么这里把键值对的值做了向右移位操作（it->second >> SIDE_TABLE_RC_SHIFT）:

#ifdef __LP64__
#   define WORD_BITS 64
#else
#   define WORD_BITS 32
#endif

// The order of these bits is important.
#define SIDE_TABLE_WEAKLY_REFERENCED (1UL<<0)
#define SIDE_TABLE_DEALLOCATING      (1UL<<1)  // MSB-ward of weak bit
#define SIDE_TABLE_RC_ONE            (1UL<<2)  // MSB-ward of deallocating bit
#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)RefcountMap

可以看出值的第一个bit表示该对象是否有过weak 对象，如果没有，在析构释放内存时可以更快；
第二个bit表示该对象是否正在析构。
从第三个bit开始才是存储引用计数数值的地方。所以这里要做向右移两位的操作，而对引用计数的 +1 和 -1 可以使用 SIDE_TABLE_RC_ONE,还可以用 SIDE_TABLE_RC_PINNED 来判断是否引用计数值有可能溢出。

当然不能够完全信任这个 _objc_rootRetainCount(id obj) 函数，对于已释放的对象以及不正确的对象地址，有时也返回 “1”。它所返回的引用计数只是某个给定时间点上的值，该方法并未考虑到系统稍后会把自动释放池清空，因而不会将后续的释放操作从返回值里减去。clang 会尽可能把NSString实现成单例对象，其引用计数会很大。如果使用了 TaggedPointer，NSNumber 的内容有可能就不再放到堆中，而是直接写在宽敞的64位栈指针值里。其看上去和真正的 NSNumber 对象一样，只是使用 TaggedPointer 优化了下，但其引用计数可能不准确。

修改引用计数

retain 和 release

在非 ARC环境下可以使用retain和release 方法对引用计数进行加一减一操作，它们分别调用了 _objc_rootRetain(id obj) 和 _objc_rootRelease(id obj)函数，不过后两者在 ARC 环境下也可使用。最后这两个函数又会调用objc_object的下面两个方法：

inline id 
objc_object::rootRetain()
{
    assert(!UseGC);

    if (isTaggedPointer()) return (id)this;
    return sidetable_retain();
}

inline bool 
objc_object::rootRelease()
{
    assert(!UseGC);

    if (isTaggedPointer()) return false;
    return sidetable_release(true);
}

这样的实现跟获取引用计数类似，先是看是否支持 TaggedPointer（毕竟数据存在栈指针而不是堆中，栈的管理本来就是自动的），否则去操作 SideTable 中的 refcnts 属性，这与获取引用计数策略类似。sidetable_retain()将 引用计数加一后返回对象，sidetable_release() 返回是否要执行 dealloc 方法：

bool 
objc_object::sidetable_release(bool performDealloc)
{
#if SUPPORT_NONPOINTER_ISA
    assert(!isa.indexed);
#endif
    SideTable *table = SideTable::tableForPointer(this);

    bool do_dealloc = false;

    if (spinlock_trylock(&table->slock)) {
        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;
        }
        spinlock_unlock(&table->slock);
        if (do_dealloc  &&  performDealloc) {
            ((void(*)(objc_object *, SEL))objc_msgSend)(this, SEL_dealloc);
        }
        return do_dealloc;
    }

    return sidetable_release_slow(table, performDealloc);
}

看到这里知道为什么在存储引用计数时总是真正的引用计数值减一了吧。因为release本来是要将引用计数减一，所以存储引用计数时先预留了个“一”，在减一之前先看看存储的引用计数值是否为 0 （it->second < SIDE_TABLE_DEALLOCATING），如果是，那就将对象标记为“正在析构”（it->second |= SIDE_TABLE_DEALLOCATING）,并发送 dealloc消息，返回 YES；否则就将引用计数减一（it->second -= SIDE_TABLE_RC_ONE）。这样做避免了负数的产生。
除此之外，Core Foundation库中也提供了增减引用计数的方法。比如在使用 Toll-Free Bridge 转换时使用的 CFBridgingRetain 和 CFBridgingRelease 方法，其本质是使用 __bridge_retained 和 __bridge_transfer 告诉编译器此处需要如何修改引用计数：

NS_INLINE CF_RETURNS_RETAINED CFTypeRef __nullable CFBridgingRetain(id __nullable X) {
    return (__bridge_retained CFTypeRef)X;
}

NS_INLINE id __nullable CFBridgingRelease(CFTypeRef CF_CONSUMED __nullable X) {
    return (__bridge_transfer id)X;
}

此外 Objective-C 很多实现是靠Core Foundation Runtime 来实现， Objective-C Runtime源码中有些地方明确注明：”// Replaced by CF“，那就是意思说这块任务被 Core Foundation库接管了。当然Core Foundation 有一部分是开源的。还有一些Objective-C Runtime函数的实现被诸如 ObjectAlloc和 NSZombie这样的内存管理工具所替代：

// Replaced by ObjectAlloc
+ (id)allocWithZone:(struct _NSZone *)zone {
    return _objc_rootAllocWithZone(self, (malloc_zone_t *)zone);
}

// Replaced by CF (throws an NSException)
+ (id)init {
    return (id)self;
}

// Replaced by NSZombies
- (void)dealloc {
    _objc_rootDealloc(self);
}

alloc, new, copy, mutableCopy

根据编译器的约定，这以这四个单词开头的方法都会使引用计数加一。而 new 相当于调用alloc后再调用 init：

id
_objc_rootAlloc(Class cls)
{
    return callAlloc(cls, false/*checkNil*/, true/*allocWithZone*/);
}
+ (id)alloc {
    return _objc_rootAlloc(self);
}
+ (id)new {
    return [callAlloc(self, false/*checkNil*/) init];
}

可以看出 alloc 和 new 最终都会调用callAlloc，默认使用 Objective-C 2.0 且忽视垃圾回收和 NSZone，那么后续的调用顺序依次是为：

class_createInstance()
_class_createInstanceFromZone()
calloc()

calloc() 函数相比于 malloc()函数的优点是它将分配的内存区域初始化为0，相当于 malloc() 后再用 memset() 方法初始化一遍。

copy 和mutableCopy都是基于NSCopying 和NSMutableCopying 方法约定，分别调用各类自己实现的 copyWithZone:和 mutableCopyWithZone:方法。这些方法无论实现方式是深拷贝还是浅拷贝，都会增加引用计数。（有些类的策略是懒拷贝，只增加引用计数但并不真的拷贝，等对象内容发生变化时再拷贝一份出来，比如 NSArray）。

在retain方法加符号断点会发现alloc, new,copy, mutableCopy 这四个方法都会通过Core Foundation 的CFBasicHashAddValue() 函数来调用retain方法。其实 CF 有个修改和查看引用计数的入口函数 __CFDoExternRefOperation，在CFRuntime.c文件中实现。

autorelease

本想贴上一堆 Runtime 中关于自动释放池的源码然后说上一大堆，然后发现了太阳神的这篇黑幕背后的Autorelease把我想说的都说了，把我不知道的也说了，简直太屌了。

其实通过看源码可以知道好多细节，没事点进去各种宏定义往往会得到惊喜：哇，原来是这么回事，XX 就是 XX 之类。。。

http://www.sealiesoftware.com/blog/archive/2013/09/24/objc_explain_Non-pointer_isa.html

http://www.opensource.apple.com

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 205,033评论 6赞 478
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 87,725评论 2赞 381
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 151,473评论 0赞 338
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,846评论 1赞 277
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,848评论 5赞 368
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,691评论 1赞 282
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 38,053评论 3赞 399
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,700评论 0赞 258
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 42,856评论 1赞 300
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,676评论 2赞 323
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,787评论 1赞 333
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,430评论 4赞 321
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 39,034评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,990评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,218评论 1赞 260
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 45,174评论 2赞 352
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,526评论 2赞 343