本文使用的 runtime 版本为 objc4-706。
__weak
修饰的指针最重要的特性是其指向的对象销毁后,会自动置为 nil
,这个特性的实现完全是依靠运行时的。实现思路是非常简单的,对于下面的语句来说:
id __weak weakObj = strongObj;
便是用 strongObj
当作 key,weakObj
当作 value 存入一个表里。当 strongObj
销毁时,从表里找到所有的 __weak
引用,将其置为 nil
。
当然,实际的实现肯定是要比这要充斥着更多的细节。
变量的创建和销毁
还是上面那个例子,实际上编译器会进行一些变动:
{
id __weak weakObj = strongObj;
}
objc_initWeak
和 objc_destroyWeak
都可以在 NSObject.mm
文件中找到:
id
objc_initWeak(id *location, id newObj)
{
if (!newObj) {
*location = nil;
return nil;
}
return storeWeak<false
可以看到都是对 storeWeak
函数模板的调用(为什么要使用模板呢?会更快吗?C++ 小白内心的问题…… )。
赋值
当已有的 __weak
变量被重新赋值时会怎么样呢?
weakObj = anotherStrongObj;
它的实现如下:
id
objc_storeWeak(id *location, id newObj)
{
return storeWeak<true
但实际上也还是对 storeWeak
函数模板的封装。
storeWeak
storeWeak
的实现还是有点长的,一点一点来分析:
函数前的注释表明了三个模板参数的作用,当然在后面的代码里也能直观的看到。函数一开始进行了变量的声明,可以注意到 SideTable
这个类型,SideTable
是现在的运行时中用来存放引用计数和弱引用的结构体,它的结构是这样的(省略了结构体函数):
struct SideTable {
spinlock_t slock;
RefcountMap refcnts;
weak_table_t weak_table;
}
其中 slock
是一个自旋锁,用来对 SideTable
实例进行操作时的加锁。refcnts
则是存放引用计数的地方。weak_table
则是存放弱引用的地方(后面将详细分析 weak_table_t
)。
回到 storeWeak
函数:
这一段即获取 oldObj
、oldTable
和 newTable
,并将获取的两个表上锁。注意到获取 oldTable
和 newTable
时,其实是用对象的地址当作 key 从 SideTables
获取的,SideTables
返回的就是一个哈希表,存储着若干个 SideTable
,一般是 64 个。
上面这一段代码也有着很好的注释,就是要确保对象的类已经走过 +initialize
流程了。
最后一段的逻辑也是很清晰的。首先,如果有旧的值(HaveOld
),则使用 weak_unregister_no_lock
函数将其从 oldTable
的 weak_table
中移除。其次,如果有新的值(HaveNew
),则使用 weak_register_no_lock
函数将其注册到 newTable
的 weak_table
中,并使用 setWeaklyReferenced_nolock
函数将对象标记为被弱引用过。
storeWeak
的实现就告一段落了,其重点就在 weak_register_no_lock
和 weak_unregister_no_lock
函数上。
weak_table_t
在分析这两个函数之前,先看看 weak_table_t
是一个怎么样的结构:
-
weak_entries
便是存放弱引用的数组;
-
num_entries
是存放的 weak_entry_t
条目的数量;
-
mask
则是动态申请的弱引用数组 weak_entries
长度减 1 的值,用来对哈希后的值取余和记录数组大小;
-
max_hash_displacement
则是哈希碰撞后最大的位移值。
其实 weak_table_t
就是一个动态增长的哈希表。
继续看看其相关的操作,首先是对整个表的扩大:
#define TABLE_SIZE(entry) (entry->mask ? entry->mask + 1 : 0)
可以看到,当 weak_table
里的弱引用条目达到它容量的四分之三时,便会将容量拓展为两倍。值得注意的是第一次拓展也就是是 mask
为 0 的情况,初始值是 64。实际对弱引用表大小的操作则交给了 weak_resize
函数。
除了扩大,当然也还有缩小:
缩小的话则是需要表本身大于等于 1024 并且存放了不足十六分之一的条目时,直接缩小 8 倍。实际工作也是交给了 weak_resize
函数:
static void weak_resize(weak_table_t *weak_table, size_t new_size)
{
size_t old_size = TABLE_SIZE(weak_table);
weak_entry_t *old_entries = weak_table->weak_entries;
weak_entry_t *new_entries = (weak_entry_t *)
calloc(new_size, sizeof(weak_entry_t));
weak_table->mask = new_size - 1;
weak_table->weak_entries = new_entries;
weak_table->max_hash_displacement = 0;
weak_table->num_entries = 0;
weak_resize
函数的过程就是新建一个数组,将老数组里的值使用 weak_entry_insert
函数添加进去,注意到代码中间 mask
在这里被赋值为新数组的大小减去 1,max_hash_displacement
和 num_entries
也都清零了,因为 weak_entry_insert
函数会对这两个值进行操作。接着对 weak_entry_insert
函数进行分析:
这个函数就是个很正常的哈希表插入的过程,hash_pointer
函数是对指针地址进行哈希,哈希后的值之所以要和 mask
进行 &
操作,是因为弱引用表的大小永远是 2 的幂(一开始是 64,之后不断乘以 2),mask
则是大小减去 1 即为一个 0b111...11
这么一个数,和它进行 &
运算相当于取余。hash_displacement
则是记录了哈希相撞后偏移的大小。
既然有插入,也就有删除:
很直接的清零 entry
,并给 weak_table
的 num_entries
减 1,最后检查看是否需要缩小。
最后还有一个根据指定对象查找存在条目的函数:
也是很正常的哈希表套路。
weak_entry_t
那弱引用是怎么存储的呢,继续分析 weak_entry_t
:
#define WEAK_INLINE_COUNT 4
#define REFERRERS_OUT_OF_LINE 2
struct weak_entry_t {
DisguisedPtr<objc_object> referent;
union {
struct {
weak_referrer_t *referrers;
uintptr_t out_of_line_ness : 2;
uintptr_t num_refs : PTR_MINUS_2;
uintptr_t mask;
uintptr_t max_hash_displacement;
};
struct {
首先 DisguisedPtr<T>
类型和 T*
的行为是一模一样的,这个类型存在的目的是为了躲过内存泄漏工具的检查(注释原文:「DisguisedPtr<T>
acts like pointer type T*
, except the stored value is disguised to hide it from tools like leaks
.」)。所以 DisguisedPtr<objc_object> referent
可以看作是 objc_object *referent
。
referent
这个指针记录的便是被弱引用的对象。接下来的联合里有两种结构体,先分析第一种:
-
referrers
:referrers
是一个 weak_referrer_t
类型的数组,用来存放弱引用变量的地址,weak_referrer_t
的定义是这样的:typedef DisguisedPtr<objc_object *> weak_referrer_t;
;
-
out_of_line_ness
:2 bit 标记位,用来确定联合里的内存是第一个结构体还是第二个结构体;
-
num_refs
:PTR_MINUS_2
便是字长减去 2 位,和 out_of_line_ness
一起组成一个字长,用来存储 referrers
的大小;
-
mask
和 max_hash_displacement
:和前面分析的一样,做哈希表用到的东西。
可以发现第一种结构体也是一个哈希表,第二种结构体则是一个和第一种结构体一样大的数组,所谓的 inline 存储。存放思路则是首先 inline 存储,当超过 WEAK_INLINE_COUNT
也就是 4 时,再变成第一种的动态哈希表存储。代码下方的构造函数便体现了这个思路。
可以注意到 weak_entry_t
重载了赋值操作符,将赋值变成了一个拷贝内存的操作。
相关操作也是和上面 weak_table_t
的类似,只不过加上了 inline 存储情况的变化,就不详细分析了。
weak_register_no_lock
开始分析 weak_register_no_lock
函数:
第一段,约等于什么都没干。referent
是被弱引用的对象,referrer
则是弱引用变量的地址。
这一段很有意思,如果对象没有自定义的内存管理方法(hasCustomRR
),则将 deallocating
变量赋值为 rootIsDeallocating
也就是是否正在销毁。但是如果有自定义的内存管理方法的话,发送的是
allowsWeakReference
这个消息,即是否允许弱引用。不管怎么样,我们得到了一个 deallocating
变量。
if (deallocating) {
if (crashIfDeallocating) {
_objc_fatal("Cannot form weak reference to instance (%p) of "
"class %s. It is possible that this object was "
"over-released, or is in the process of deallocation.",
(void*)referent, object_getClassName((id)referent));
} else {
return nil;
}
}
从上面一段可以知道,deallocating
为 true
的话肯定是有问题的,所以这一段处理一下。
最后一段终于做了正事了!首先先用 weak_entry_for_referent
函数搜索对象是否已经有了 weak_entry_t
类型的条目,有的话则使用 append_referrer
添加一个变量位置进去,没有的话则新建一个 weak_entry_t
条目,使用 weak_grow_maybe
函数扩大(如果需要的话)弱引用表的大小,并使用 weak_entry_insert
将弱引用插入表中。
weak_unregister_no_lock
接下来是 weak_unregister_no_lock
函数:
void
weak_unregister_no_lock(weak_table_t *weak_table, id referent_id,
id *referrer_id)
{
objc_object *referent = (objc_object *)referent_id;
objc_object **referrer = (objc_object **)referrer_id;
weak_entry_t *entry;
if (!referent) return;
if ((entry = weak_entry_for_referent(weak_table, referent))) {
remove_referrer(entry, referrer);
bool empty = true;
if (entry->out_of_line() && entry->num_refs != 0) {
empty = false;
}
else {
for (size_t i = 0; i < WEAK_INLINE_COUNT; i++) {
if (entry->inline_referrers[i]) {
empty = false;
break;
}
}
}
if (empty) {
weak_entry_remove(weak_table, entry);
}
}
主要功能实现思路很简单,使用 weak_entry_for_referent
函数找到对应的弱引用条目,并用 remove_referrer
将对应的弱引用变量位置从中移除。最后判断条目是否为空,为空则使用 weak_entry_remove
将其从弱引用表中移除。
自动置为 nil
对象销毁后,弱引用变量被置为 nil
是因为在对象 dealloc
的过程中调用了 weak_clear_no_lock
函数:
首先初始化一下,获取到弱引用条目,顺便处理没有弱引用的情况。
获取弱引用变量位置数组和个数。
for (size_t i = 0; i < count; ++i) {
objc_object **referrer = referrers[i];
if (referrer) {
if (*referrer == referent) {
*referrer = nil;
}
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);
}
循环将它们置为 nil
,最后移除整个弱引用条目。
访问弱引用
在访问一个弱引用时,ARC 会对其进行一些操作:
obj = weakObj;
objc_loadWeakRetained
函数的主要作用就是调用了 rootTryRetain
函数:
ALWAYS_INLINE bool
objc_object::rootTryRetain()
{
return rootRetain(true, false) ? true : false;
}
实际上就是尝试对引用计数加 1,让弱引用对象在使用时不会被释放掉。
有关 rootRetain
的实现:《Objective-C 小记(7)retain & release》
总结
存放一个弱引用还真是哈希了很多次:
-
SideTable
哈希一次,这里分开来应该是为了性能原因;
-
weak_table_t
哈希一次;
-
weak_entry_t
哈希一次。
对于开销,直观感受上也并没有什么很大开销,想用就用呗……
请发表评论