iOS weak源码详解
准备工作
- 请准备好750.1版本的objc4源码一份【目前最新的版本】,打开它,找到文章中提到的方法,类型,对象
- 一切请以手中源码为准,不要轻信任何人,任何文章,包括本篇博客
- 文章中的源码都请过了我的删改,建议还是先看看源码
- 源码建议从Apple官方开源网站获取obj4
- 官网上下载下来需要自己配置才能编译运行,如果不想配置,可以在RuntimeSourceCode中clone
数据模型
SideTables()
- SideTables()是一个全局的哈希表,里面存储了sideTable结构体,根据对象的地址可以在sidetables()找到相应的SideTable
- SideTables()的定义:
static StripedMap<SideTable>& SideTables() {
return *reinterpret_cast<StripedMap<SideTable>*>(SideTableBuf);
}
- 可以大致理解为,该方法会返回一个StripedMap类型的数据结构,里面存储的类型是SideTable
StripedMap
template<typename T>
class StripedMap {
#if TARGET_OS_IPHONE && !TARGET_OS_SIMULATOR
enum { StripeCount = 8 };
#else
enum { StripeCount = 64 };
#endif
struct PaddedT {
T value alignas(CacheLineSize);
//enum { CacheLineSize = 64 };
};
PaddedT array[StripeCount];
//enum { StripeCount = 64 };
static unsigned int indexForPointer(const void *p) {
uintptr_t addr = reinterpret_cast<uintptr_t>(p);
return ((addr >> 4) ^ (addr >> 9)) % StripeCount;
}
public:
//重载
T& operator[] (const void *p) {
return array[indexForPointer(p)].value;
}
const T& operator[] (const void *p) const {
return const_cast<StripedMap<T>>(this)[p];
}
};
- 这里面其实StripedMap里一共就一个PaddedT类型的数组,大小为StripeCount【64】
- SideTables() 返回的 StripedMap, 是一个 value 为 SideTable 的哈希桶(由于 SideTable 内部又在维护数组, 所以这是一个哈希桶结构), 哈希值由对象的地址计算得出
补充知识:哈希桶
- 哈希桶算法就是链地址解决冲突的方法
- 所谓哈希桶,以SideTables与SideTable的方式来举例的话,就是本来数据数量不多的时候,只要有个SideTables就行,但由于数据数量超过了64【SideTables内部数组的长度】,导致出现了哈希冲突,两个对象都有f(key),需要占用同一个空间
- 哈希桶就是将这个数组的单个空间扩展成一个拉链一样的结构,将指向同一个空间的值存到同一条拉链上
- 这里,SideTable就是一条拉链,一个对象根据其地址在SideTables上找到相应的SideTable,存入其中
- 拉链可以用数组/链表组织数据,Apple使用的是数组
SideTable
- SideTable的定义一点都不长,却很麻烦
struct SideTable {
spinlock_t slock; //自旋锁
RefcountMap refcnts; //存放引用计数
weak_table_t weak_table; //weak_table是一个哈希
};
- 这里先来看这三兄弟是干什么的
spinlock_t slock【自旋锁】
补充知识:锁
- 锁是操作系统中的一个概念
- 为了保证数据的一致性,在多线程编程中我们会用到锁,使得在某一时间点,只有一个线程进入临界区代码。虽然不同的语言可能会提供不同的锁接口,但是底层调用的都是操作系统的提供的锁,不同的高级语言只是在操作系统的锁机制基础上进行了些封装而已,要真正理解锁,还是得看操作系统是怎么实现锁的。
- 以引用计数举例,由于我们的程序是多线程的,可能在不同的线程都会对某个对象的应用计数操作,导致混乱
- 这里使用锁,当某次访问开始时,锁就被持有,其余访问就不能进行,当访问结束,锁被空出来,才能轮到其他访问去竞争这把锁
RefcountMap refcnts【存放引用计数】
引用计数存在RefcountMap结构里,也就是上文介绍哈希桶的时候提到的拉链
这也是个hash结构,根据对象地址存储引用计数
//RefcountMap
typedef objc::DenseMap<DisguisedPtr<objc_object>,size_t,true> RefcountMap;
//DenseMap
template<typename KeyT, typename ValueT,
bool ZeroValuesArePurgeable = false,
typename KeyInfoT = DenseMapInfo<KeyT> >
class DenseMap
: public DenseMapBase<DenseMap<KeyT, ValueT, ZeroValuesArePurgeable, KeyInfoT>,
KeyT, ValueT, KeyInfoT, ZeroValuesArePurgeable> {
typedef DenseMapBase<DenseMap, KeyT, ValueT, KeyInfoT, ZeroValuesArePurgeable> BaseT;
//ZeroValuesArePurgeable:ZeroValuesArePurgeable 默认值是 false, 但 RefcountMap 指定其初始化为 true. 这个成员标记是否可以使用值为 0 (引用计数为 1) 的桶.
typedef typename BaseT::BucketT BucketT;
friend class DenseMapBase<DenseMap, KeyT, ValueT, KeyInfoT, ZeroValuesArePurgeable>;
BucketT *Buckets;
//Buckets 指针管理一段连续内存空间, 也就是数组, 数组成员是 BucketT 类型的对象桶的 key 为 EmptyKey 时是空桶
//typedef std::pair<KeyT, ValueT> BucketT;
//桶的数据类型std::pair,将对象地址和对象的引用计数(这里的引用计数类似于 isa, 也是使用其中的几个 bit 来保存引用计数, 留出几个 bit 来做其它标记位)组合成一个数据类型.
unsigned NumEntries;
//NumEntries 记录数组中已使用的非空的桶的个数.
unsigned NumTombstones;
//当一个对象的引用计数为0, 要从桶中取出时, 其所处的位置会被标记为 TombstoneNumTombstones 就是数组中的墓碑的个数. 后面会介绍到墓碑的作用
unsigned NumBuckets;
//NumBuckets 桶的数量, 因为数组中始终都充满桶, 所以可以理解为数组大小.
}
DisguisedPtr
- DisguisedPtr是runtime对于普通对象指针(引用)的一个封装,目的在于隐藏weak_table_t的内部指针。
- 对于这个我了解的也不是很清楚,大概理解就是通过static uintptr_t disguise(T* ptr) {return -(uintptr_t)ptr;}来实现隐藏
DenseMap
- 当你进入DenseMap定义的时候,抬头看下最上方的文件名,发现已经离开objc4了,进入了一个叫llvm-DenseMap.h的里世界,这里面的代码也是开着全局搜索也搜不到的神仙代码【但很奇怪,这里还是可以编辑】
补充知识:LLVM
- LLVM是构架编译器(compiler)的框架系统,以C++编写而成,用于优化以任意程序语言编写的程序的编译时间(compile-time)、链接时间(link-time)、运行时间(run-time)以及空闲时间(idle-time),对开发者保持开放,并兼容已有脚本。
- LLVM计划启动于2000年,最初由美国UIUC大学的Chris Lattner博士主持开展。2006年Chris Lattner加盟Apple Inc.并致力于LLVM在Apple开发体系中的应用。Apple也是LLVM计划的主要资助者。
- 目前LLVM已经被苹果IOS开发工具、Xilinx Vivado、Facebook、Google等各大公司采用。
- 简单来说,把这里的理解成某个第三方库就行
- 这个DenseMap中的操作我只不讲源码,只分析其流程,感兴趣可以自己深入
哈希实现
-
这个DenseMap本质上是std::pair<KeyT, ValueT>,C++中的pair类型,反正也是个键值对
-
DenseMap同样是个hash结构,下面来分析它的流程【很多参数的解释我都在代码注释里写了】
-
这里借用下runtime(二) SideTables大神的图解完全讲清楚了问题,厉害
-
首先我们有一个初始化好的, 大小为 9 的桶数组
- 同时有 a b c d e 五个对象要使用桶数组, 这里我们假设五个对象都被哈希算法分配到下标 0 的位置里. a 第一个进入, 但 b c d e 由于下标 0 处已经不是空桶, 则需要进行下一步哈希算法来查找合适的位置, 假设这 4 个对象又恰巧都被分配到了下标为 1 的位置, 但只有 b 可以存入. 假设每一次哈希计算都只给下标增加了 1, 以此类推我们能得到:
- 假设这个时候 c 对象被释放了, 之前提到过这个时候会把对应的位置的 key 设置为 TombstoneKey:
- 接下来就体现了墓碑的作用:
- 如果 c 对象销毁后将下标 2 的桶设置为空桶, 此时为 e 对象增加引用计数, 根据哈希算法查找到下标为 2 的桶时, 就会直接插入, 无法为已经在下标为 4 的桶中的 e 增加引用计数.
- 如果此时初始化了一个新的对象 f, 根据哈希算法查找到下标为 2 的桶时发现桶中放置了墓碑, 此时会记录下来下标 2. 接下来继续哈希算法查找位置, 查找到空桶时, 就证明表中没有对象 f, 此时 f 使用记录好的下标 2 的桶而不是查找到的空桶, 就可以利用到已经释放的位置.
- 对于DenseMap的分析我们就到这
weak_table_t weak_table
/**
* The global weak references table. Stores object ids as keys,
* and weak_entry_t structs as their values.
*/
struct weak_table_t {
weak_entry_t *weak_entries; //管理所有指向某对象的weak指针,也是一个hash
size_t num_entries; //数组中已占用位置的个数
uintptr_t mask; //数组下标最大值(即数组大小 -1)
uintptr_t max_hash_displacement; //最大哈希偏移值
};
- weak_table并没有直接是个数组存放weak指针,而是使用一个结构体weak_entry_t *weak_entries;去存放weak指针
weak_entry_t *weak_entries【存放weak指针】
struct weak_entry_t {
DisguisedPtr<objc_object> referent; //被指对象的地址。前面循环遍历查找的时候就是判断目标地址是否和他相等。
union {
struct {
weak_referrer_t *referrers; //可变数组,里面保存着所有指向这个对象的弱引用的地址。当这个对象被释放的时候,referrers里的所有指针都会被设置成nil。
//指向 referent 对象的 weak 指针数组
uintptr_t out_of_line_ness : 2; //这里标记是否超过内联边界, 下面会提到
uintptr_t num_refs : PTR_MINUS_2; //数组中已占用的大小
uintptr_t mask; //数组下标最大值(数组大小 - 1)
uintptr_t max_hash_displacement; //最大哈希偏移值
};
struct {
// out_of_line_ness field is low bits of inline_referrers[1]
weak_referrer_t inline_referrers[WEAK_INLINE_COUNT]; //只有4个元素的数组,默认情况下用它来存储弱引用的指针。当大于4个的时候使用referrers来存储指针。
//当指向这个对象的weak指针不超过4个,则直接使用数组inline_referrers,省去hash
};
};
-
这里有见到了我们的老朋友union,也就提示我们Apple同样是使用过同一段内存去存放不同的信息
-
这里有两个数组,一个是weak_referrer_t inline_referrers[WEAK_INLINE_COUNT],数组长度只有4,当某个对象的weak指针个数小于四的时候,会存入这个数组,当大于四的时候才会存到referrers当中
-
至此,所有的数据模型总结完毕
-
是不是感觉有点懵?
结构总结
图片.png- 总之只要是数组的基本都是哈希结构
SideTables以及SideTable的关系
- 这里借用下iOS管理对象内存的数据结构以及操作算法--SideTables、RefcountMap、weak_table_t-二大神的比喻
- 假设有80个学生需要咱们安排住宿,同时还要保证学生们的财产安全。应该怎么安排?
- 显然不会给80个学生分别安排80间宿舍,然后给每个宿舍的大门上加一把锁。那样太浪费资源了锁也挺贵的,太多的宿舍维护起来也很费力气。
- 我们一般的做法是把80个学生分配到10间宿舍里,每个宿舍住8个人。假设宿舍号分别是101、102 、... 110。然后再给他们分配床位,01号床、02号床等。然后给每个宿舍配一把锁来保护宿舍内同学的财产安全。为什么不只给整个宿舍楼上一把锁,每次有人进出的时候都把整个宿舍楼锁上?显然这样会造成宿舍楼大门口阻塞。
- OK假如现在有人要找102号宿舍的2号床的人聊天。这个人会怎么做? 1、找到宿舍楼(SideTables)的宿管,跟他说自己要找10202(内存地址当做key)。 2、宿管带着他SideTables[10202]找到了102宿舍SideTable,然后把102的门一锁lock,在他访问102期间不再允许其他访客访问102了。(这样只是阻塞了102的8个兄弟的访问,而不会影响整栋宿舍楼的访问) 3、然后在宿舍里大喊一声:"2号床的兄弟在哪里?"table.refcnts.find(02)你就可以找到2号床的兄弟了。 4、等这个访客离开的时候会把房门的锁打开unlock,这样其他需要访问102的人就可以继续进来访问了。
- SideTables == 宿舍楼;SideTable == 宿舍;RefcountMap里存放着具体的床位
- 苹果之所以需要创造SideTables的Hash冲突是为了把对象放到宿舍里管理,把锁的粒度缩小到一个宿舍SideTable。RefcountMap的工作是在找到宿舍以后帮助大家找到正确的床位的兄弟。
- 讨论完这些问题之后,我们终于可以开始研究weak调用的方法了
weak相关的方法
objc_initWeak(id *location, id newObj)
id
objc_initWeak(id *location, id newObj)
{
if (!newObj) {
*location = nil;
return nil;
}
return storeWeak<DontHaveOld, DoHaveNew, DoCrashIfDeallocating>
(location, (objc_object*)newObj);
}
- 该方法中的两个参数location是指weak 指针,newObj 是 weak 指针将要指向的对象
storeWeak(id *location, objc_object *newObj)
id oldObj;
SideTable *oldTable;
SideTable *newTable;
// Clean up old value, if any.
if (haveOld) {
weak_unregister_no_lock(&oldTable->weak_table, oldObj, location);
}
// Assign new value, if any.
if (haveNew) {
newObj = (objc_object *)
weak_register_no_lock(&newTable->weak_table, (id)newObj, location,
crashIfDeallocating);
// weak_register_no_lock returns nil if weak store should be rejected
// Set is-weakly-referenced bit in refcount table.
if (newObj && !newObj->isTaggedPointer()) {
newObj->setWeaklyReferenced_nolock();
}
// Do not set *location anywhere else. That would introduce a race.
*location = (id)newObj;
}
else {
// No new value. The storage is not changed.
}
return (id)newObj;
- 这里要先进行haveOld判断,也就是如果该指针有指向的旧值,先要weak_unregister_no_lock(&oldTable->weak_table, oldObj, location);处理旧值
- 之后在weak_register_no_lock(&newTable->weak_table, (id)newObj, location,crashIfDeallocating);进行赋值操作
weak_unregister_no_lock
//从原有的表中先删除这个 weak 指针注销已注册的弱引用。当引用者的存储即将消失,但引用还没有死。(否则,稍后归零引用将是内存访问错误。)如果引用/引用不是当前活动的弱引用,则不执行任何操作。引用不为零。
void
weak_unregister_no_lock(weak_table_t *weak_table, id referent_id,
id *referrer_id)
{
objc_object *referent = (objc_object *)referent_id; //weak 指针指向的对象
objc_object **referrer = (objc_object **)referrer_id; //referrer_id是 weak 指针, 操作时需要用到这个指针的地址
weak_entry_t *entry;
if (!referent) return;
if ((entry = weak_entry_for_referent(weak_table, referent))) { //查找 referent 对象对应的 entry
remove_referrer(entry, referrer); //从 referent 对应的 entry 中删除地址为 referrer 的 weak 指针
bool empty = true;
if (entry->out_of_line() && entry->num_refs != 0) { //如果 entry 中的数组容量大于 4 并且数组中还有元素
empty = false; //entry 非空
}
else {
for (size_t i = 0; i < WEAK_INLINE_COUNT; i++) {
if (entry->inline_referrers[i]) { //否则循环查找 entry 数组, 如果 4 个位置中有一个非空
empty = false; //entry 非空
break;
}
}
}
if (empty) {
weak_entry_remove(weak_table, entry); //从 weak_table 中移除该条 entry
}
}
}
- 这里先是remove_referrer(entry, referrer);从对应的entry中删除该weak记录
- 之后我们需要判断,还有没有指向这个地址的weak指针了,所以有下面的判空操作,如果这个entry已经没有东西了,将整个删除
weak_register_no_lock
id
weak_register_no_lock(weak_table_t *weak_table, id referent_id,
id *referrer_id, bool crashIfDeallocating)
{
objc_object *referent = (objc_object *)referent_id;
objc_object **referrer = (objc_object **)referrer_id;
// now remember it and where it is being stored
weak_entry_t *entry; //如果 weak_table 有对应的 entry
if ((entry = weak_entry_for_referent(weak_table, referent))) {
append_referrer(entry, referrer); //将 weak 指针存入对应的 entry 中
}
else {
weak_entry_t new_entry(referent, referrer); //创建新的 entry
weak_grow_maybe(weak_table); //查看是否需要调整 weak_table 中 weak_entries 数组大小
weak_entry_insert(weak_table, &new_entry); //将新的 entry 插入到 weak_table 中
}
return referent_id;
}
这里如果该地址有对应的entry,在里面存入指针;如果没有entry,就新建entry,在里面插入weak指针,并插入weak_table
weak_entry_for_referent(weak_table_t *weak_table, objc_object *referent)
该方法通过对象的地址,获取到该weak_table中的entry【保存着指向某对象的所有weak指针】
static weak_entry_t *
weak_entry_for_referent(weak_table_t *weak_table, objc_object *referent)
{
assert(referent);
weak_entry_t *weak_entries = weak_table->weak_entries;
if (!weak_entries) return nil;
size_t begin = hash_pointer(referent) & weak_table->mask;
size_t index = begin;
size_t hash_displacement = 0;
while (weak_table->weak_entries[index].referent != referent) {
index = (index+1) & weak_table->mask;
if (index == begin) bad_weak_table(weak_table->weak_entries);
hash_displacement++;
if (hash_displacement > weak_table->max_hash_displacement) {
return nil;
}
}
return &weak_table->weak_entries[index];
}
hash_pointer也是使用指针地址,映射到一个索引。&weak_table->mask这个操作是?这个mask实际值是表的size-1,而size是2的n次方进行扩张的,所以mask的形式就1111 1111 1111这种,索引和mask位与之后的值必定就落在了[0, size]范围内。也就是说,先是通过hash_pointer对地址进行hash映射,得到下标,接下来通过位遮蔽,保证这个映射是在范围内的,不会超出范围
index = (index+1) & weak_table->mask;是在遇到哈希冲突的时候,就一直往下找下一个位置
下面我们看下append_referrer的实现
static void append_referrer(weak_entry_t *entry, objc_object **new_referrer)
{
if (! entry->out_of_line()) { //如果数组大小没超过 4
// Try to insert inline.
for (size_t i = 0; i < WEAK_INLINE_COUNT; i++) {
if (entry->inline_referrers[i] == nil) { //循环查找数组成员
entry->inline_referrers[i] = new_referrer; //把新的 weak 指针插入到空位置
return;
}
}
//也就是说走到这就是刚好之前有四个引用,现在添加第五个
//数组中的 4 个位置都非空, 就要调整策略使用 referrers 了
//从这里开始, 这一段是把 inline_referrers 数组调整为使用 referrers 的形式
// Couldn't insert inline. Allocate out of line.
weak_referrer_t *new_referrers = (weak_referrer_t *)
calloc(WEAK_INLINE_COUNT, sizeof(weak_referrer_t)); //还是开辟 4 个 weak_referrer_t 大小的空间
// This constructed table is invalid, but grow_refs_and_insert
// will fix it and rehash it.
for (size_t i = 0; i < WEAK_INLINE_COUNT; i++) {
new_referrers[i] = entry->inline_referrers[i]; //将 inline_referrers 中的值赋值给 referrers
}
entry->referrers = new_referrers;
entry->num_refs = WEAK_INLINE_COUNT;
entry->out_of_line_ness = REFERRERS_OUT_OF_LINE;
entry->mask = WEAK_INLINE_COUNT-1;
entry->max_hash_displacement = 0;
}
assert(entry->out_of_line());
if (entry->num_refs >= TABLE_SIZE(entry) * 3/4) {
return grow_refs_and_insert(entry, new_referrer);
}
//开始哈希算法
size_t begin = w_hash_pointer(new_referrer) & (entry->mask);
size_t index = begin; //使用哈希算法计算到一个起始下标
size_t hash_displacement = 0; //哈希偏移次数
while (entry->referrers[index] != nil) { //循环找空位置
hash_displacement++;
index = (index+1) & entry->mask;
if (index == begin) bad_weak_table(entry);
}
//这里记录下移位的最大值, 那么数组里的任何一个数据, 存储时的移位次数都不大于这个值
//可以提升查找时的效率, 如果移位次数超过了这个值都没有找到, 就证明要查找的项不在数组中
if (hash_displacement > entry->max_hash_displacement) {
entry->max_hash_displacement = hash_displacement;
}
weak_referrer_t &ref = entry->referrers[index];
ref = new_referrer;
entry->num_refs++;
}
- 这里首先是要判断关联数组里有没有空位【关联数组没有使用哈希】,如果关联数组有空位的话,直接插入
- 没有空位需要使用且是刚好第五个的情况,需要初始化一个weak_referrer_t,将关联数组里的数据先存进去【也就是说不会两个一起用】
- 接下来通过哈希操作存入
赋值操作
weak_referrer_t &ref = entry->referrers[index];
ref = new_referrer;
entry->num_refs++;
- 这个赋值语句之前一直让我百思不得其解,现在感觉还是C语言学的不到位呀
- 首先,现在的index就是我们正确的插入下标,按照我们正常人明显应该这么写
entry->referrers[index] = new_referrer;
entry->num_refs++;
- 这是Apple偏偏没有这么写,写了上面这三行
- 说来惭愧,我之前都觉得weak_referrer_t &ref = entry->referrers[index];明显是错的,哪有初始化一个地址这个说法的
- 现在我的理解可能依然不太对,我觉得是这样,ref依然是个weak_referrer_t类型的变量,现在通过&取地址符,设置这个变量的地址【这里就觉得很迷了,一个结构体的地址怎么可以变呢?或者理解成ref不是一个实际上的变量,只是一个标志符】
- 现在我们把referrers[index]赋给了这个地址,也就相当于ref现在就是referrers[index]【自己都觉得解释的很不清楚。。。】
- 放一段自己做的实验
#include <iostream>
using namespace std;
struct Padd {
int a;
float b;
}bucket[10];
int main(int argc, const char * argv[]) {
// insert code here...
std::cout << "Hello, World!\n";
int j = 0;
float k = 16;
for (Padd &i : bucket) {
i.a = j++;
i.b = k++;
}
for (Padd &i : bucket) {
cout << i.a << "XXX" << i.b << endl;
}
Padd *testPadd = (Padd *)malloc(sizeof(Padd));
testPadd->a = 99;
testPadd->b = 109;
Padd &ref = bucket[4];
ref = *testPadd;
printf("%p\n", &bucket[4]);
printf("%p\n", &ref);
for (Padd &i : bucket) {
cout << i.a << "XXX" << i.b << endl;
}
return 0;
}
dealloc后将weak指针置nil【weak_clear_no_lock(weak_table_t *weak_table, id referent_id) 】
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) {
return;
}
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;
}
}
}
weak_entry_remove(weak_table, entry);
}
- 前面将关联数组和referrers都看作一个数组,获取相应的count,进行nil操作
方法总结
2664540-255e050c9fafa044后续更新
对于weak对象的访问:objc_loadWeakRetained
- 先回看下《iOS高级编程》中的描述
id __weak obj1 = obj0;
NSLog(@"class = %@",[obj1 class]);
id __weak obj1 = obj0;
id __autoreleasing tmp = obj1;
NSLog(@"class = %@",[tmp class]);//实际访问的是注册到自动释放池的对象
- 现在我们有源码了,可以看看具体是怎么实现的
//实验代码
NSObject *obj0 = [[NSObject alloc] init];
NSObject *obj1 __weak = obj0;
printf("retain count = %ld\n",CFGetRetainCount((__bridge CFTypeRef)(obj0))); //结果为1
printf("retain count = %ld\n",CFGetRetainCount((__bridge CFTypeRef)(obj1))); //断点打在这里 结果为2
- 接着跟着方法调用栈往下走,发现来到objc_loadWeakRetained
id
objc_loadWeakRetained(id *location)
{
id obj;
id result;
Class cls;
SideTable *table;
retry:
// fixme std::atomic this load
obj = *location;
if (!obj) return nil;
if (obj->isTaggedPointer()) return obj;
table = &SideTables()[obj];
table->lock();
if (*location != obj) {
table->unlock();
goto retry;
}
result = obj;
cls = obj->ISA();
if (! cls->hasCustomRR()) {
// Fast case. We know +initialize is complete because
// default-RR can never be set before then.
assert(cls->isInitialized());
if (! obj->rootTryRetain()) { //rootTryRetain执行了retain操作
result = nil;
}
}
table->unlock();
return result;
}
- 这过方法里的 if (! obj->rootTryRetain())这一句调用了retain方法,达到了引用计数+1,防止dealloc的作用
- 接着我们给objc_release方法打上断点,发现这句打印一结束,就会调用release方法【是谁调用的,为什么会调用的,我是一问三不知】
- 也就是说对于weak修饰对象的访问都会调用该方法,进行retain【包括NSObject *obj0 = [[NSObject alloc] init];NSObject *obj1 __weak = obj0;NSObject *obj2 = obj1;中的第三句,也算是访问】
- 因此,书上说的autorelease的方式并不是目前真正的实现方式了
- 我个人认为这种方式还要比autorelease更好理解些
isa_t中存放的引用计数
- isa_t中有这两块内容,uintptr_t has_sidetable_rc【是否使用sidetable来存放引用计数】,uintptr_t extra_rc【引用计数】
- 也就是说对于能存的下的引用计数是通过isa来存储的
- 这里我们可观察下retainCount方法来了解下这两块之间的关系
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();
}
- 哇,真的是好久没看到这么简单易懂的源码,在经历了各色妖魔鬼怪,现在这种跟幼儿读物一样的源码我们读起来完全跟割黄油一样easy,丝滑<g-emoji class="g-emoji" alias="v" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/270c.png" style="box-sizing: border-box; font-family: "Apple Color Emoji", "Segoe UI", "Segoe UI Emoji", "Segoe UI Symbol"; font-size: 1.2em; font-weight: 400; line-height: 20px; vertical-align: middle; font-style: normal !important; margin-right: 3px;">✌️</g-emoji>
- 也就是说,最后返回的引用计数会是isa中的加上【如果超过限制】,sideTable中的
为什么weak_entries中referrers要使用hash?
我们来理一理思路,在weak_entries中,已经有referent存储了被指对象的地址,referrers中存放的是所有指向该对象的weak指针的地址
而我们使用了hash的方式存储,我们将weak指针的地址hash出一个index来存放weak指针的地址
有没有觉得怪怪的?一般来说我们用key【一般是对象地址】哈希出一个index作为存放地址,存放的是对象本身,也就是value
但在这里,等于就是用key存key了。因此我之前以为这里没必要hash,因为假如我们希望查询到该weak指针的地址,我们得拿weak指针的地址去找。。。
但其实这里还是因为没有很好的理解他的意义,这张表不是为了查找weak指针的地址而存在的,而是要记录指向某一对象的所有weak指针而存在的,其存在的意义就是在记录上有本身
我们查找某一weak指针往往基本上就是为了把记录这个东西
在这张表上删除,我们的目的在于记录本身,而不是其value本身,以上。