聊聊iOS开发中weak指针的原理
【原创博文,转载请注明出处!】
写在最前面:你们别光看啊,发现我说的不对的地方请指出或留言,希望我们一起进步。
前几天在iOS圈内流传着“一个关于历年来weak的面试题答案”的段子,感觉有点搞怪O(∩_∩)O~~。是的,做技术开发门槛越来越高了。。。
结合objc源码,我写了个简单测试demo,关于对象的三个修饰词__strong
、__weak
、__unsafe_unretained
,测试结果分别用“01__strong指针引用对象.png”、“02__weak指针引用对象.png”、“03__unsafe_unretained指针引用对象.png”三张图表示。
- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event
{
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wunused-variable"
__strong ZYClass *strongZYClass;
__weak ZYClass *weakZYClass;
__unsafe_unretained ZYClass *unsafeZYClass;
#pragma clang diagnostic pop
NSLog(@"test begin");
{
ZYClass *zyClass = [[ZYClass alloc] init];
strongZYClass = zyClass;
// weakZYClass = zyClass;
// unsafeZYClass = zyClass;
}
NSLog(@"test over%@",strongZYClass);
}
01__strong指针引用对象.png
02__weak指针引用对象.png
03__unsafe_unretained指针引用对象.png
"zyClass"定义的作用域如下:
{
ZYClass *zyClass = [[ZYClass alloc] init];
strongZYClass = zyClass;
// weakZYClass = zyClass;
// unsafeZYClass = zyClass;
}
鉴于__strong
指针对对象有强引用关系,所以"zyClass"在出作用域后并没有立即销毁;
__weak
指针对对象是弱引用关系,不持有引用对象。所以"zyClass"在出作用域后就销毁了;
__unsafe_unretained
指针对对象是弱引用关系,不持有引用对象。所以"zyClass"在出作用域后就销毁了。(与__weak不同的是,__weak引用的对象销毁后,系统会将对象置为nil,而__unsafe_unretained不这么做,导致EXC_BAD_ACCESS
错误。)
weak指针帮我们干了啥?
当一个对象释放的时候,会执行"- (void)dealloc {}"方法,在objc源码的“NSObject.mm”中找到了该函数以及相关调用流程,我将它们抽取出来如下:
// Replaced by NSZombies
- (void)dealloc {
_objc_rootDealloc(self);
}
void _objc_rootDealloc(id obj)
{
assert(obj);
obj->rootDealloc();
}
inline void objc_object::rootDealloc()
{
if (isTaggedPointer()) return; // fixme necessary?
if (fastpath(isa.nonpointer &&
!isa.weakly_referenced &&
!isa.has_assoc &&
!isa.has_cxx_dtor &&
!isa.has_sidetable_rc))
{
assert(!sidetable_present());
free(this);
}
else {
object_dispose((id)this);
}
}
id object_dispose(id obj)
{
if (!obj) return nil;
objc_destructInstance(obj);
free(obj);
return nil;
}
/***********************************************************************
* objc_destructInstance
* Destroys an instance without freeing memory.
* Calls C++ destructors.
* Calls ARC ivar cleanup.
* Removes associative references.
* Returns `obj`. Does nothing if `obj` is nil.
**********************************************************************/
void *objc_destructInstance(id obj)
{
if (obj) {
// Read all of the flags at once for performance.
bool cxx = obj->hasCxxDtor();
bool assoc = obj->hasAssociatedObjects();
// This order is important.
//清除对象的成员变量
if (cxx) object_cxxDestruct(obj);
//清除对象的关联对象
if (assoc) _object_remove_assocations(obj);
obj->clearDeallocating();
}
return obj;
}
inline void objc_object::clearDeallocating()
{
if (slowpath(!isa.nonpointer)) {
// Slow path for raw pointer isa.
sidetable_clearDeallocating();
}
else if (slowpath(isa.weakly_referenced || isa.has_sidetable_rc)) {
// Slow path for non-pointer isa with weak refs and/or side table data.
clearDeallocating_slow();
}
assert(!sidetable_present());
}
// Slow path of clearDeallocating()
// for objects with nonpointer isa
// that were ever weakly referenced
// or whose retain count ever overflowed to the side table.
NEVER_INLINE void objc_object::clearDeallocating_slow()
{
assert(isa.nonpointer && (isa.weakly_referenced || isa.has_sidetable_rc));
SideTable& table = SideTables()[this];
table.lock();
if (isa.weakly_referenced) {
weak_clear_no_lock(&table.weak_table, (id)this);
}
if (isa.has_sidetable_rc) {
table.refcnts.erase(this);
}
table.unlock();
}
/**
* Called by dealloc; nils out all weak pointers that point to the
* provided object so that they can no longer be used.
*
* @param weak_table
* @param referent The object being deallocated.
*/
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) {
/// XXX shouldn't happen, but does with mismatched CF/objc
//printf("XXX no entry for clear deallocating %p\n", referent);
return;
}
// zero out references
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;
}
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);
}
/**
* Return the weak reference table entry for the given referent.
* If there is no entry for referent, return NULL.
* Performs a lookup.
*
* @param weak_table
* @param referent The object. Must not be nil.
*
* @return The table of weak referrers to this object.
*/
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];
}
函数inline void objc_object::rootDealloc()
中有一句判断if (isTaggedPointer()) return; // fixme necessary?
,这个地方条件成立就会return ,而不会释放对象,为什么?
实际上苹果在64位系统开始推出了“Tagged Pointer”技术来优化NSNumber、NSString、NSDate等小对象的存储,在没有引入“Tagged Pointer”技术之前,NSNumber等对象需要动态分配内存、维护引用技术,NSNumber指针存储的是NSNumber对象的地址值。iOS引入“Tagged Pointer”技术之后,NSNumber指针里面存储的数据变成了“Tag+Data”,也就是直接将数据存储在指针中。仅当指针不够存储数据时,才会使用动态分配内存的方式来存储数据。
“Tagged Pointer”的好处是:一方面节约计算机内存,另一方面因为可以直接从指针中读取数据,可以节约之前objc_msgSend流程消耗的时间。
那对于下面三个“对象”(这里注意“”修饰,因为a、b本质上属于Tagged Pointer类型,而不是OC对象):
a. NSNumber *number1 = @4;
b. NSNumber *number2 = @5;
c. NSNumber *number3 = @(0xFFFFFFFFFFFFFFF)。
对于a、b,所对应的二级制编码分别为0b0100、0b0101,仅仅占用3 bit,用一个字节(8bit)就足够存储了,而OC的指针*number1、*number2
都占用8个字节,因此我们完全可以将a、b的值存放在指针中,那么a、b实际上就不是真正的对象了,也就不存在执行所谓的- (void) dealloc{}
流程。如果按照64位之前的策略,那存储a、b这样的小对象,需要在堆空间alloc init出一个NSNumber对象,然后将@10放入对象中,这个过程至少占用16字节,然后在栈区用一个指针指向这个NSNumber对象,栈空间指针又占用8字节,所以至少需要24字节存储a、b这样的小对象,很浪费内存。详细请参考谈谈我对Objective-C对象本质的理解。
回到正题:
当一个对象被回收的时候调用流程:
1 -(void)dealloc ->
2 _objc_rootDealloc(id obj) ->
3 objc_object::rootDealloc() ->
4 object_dispose(id obj) ->
5 objc_destructInstance(id obj) ->
6 objc_object::clearDeallocating() ->
7 objc_object::clearDeallocating_slow() ->
8 weak_clear_no_lock(weak_table_t weak_table, id referent_id) ->
**9 weak_entry_for_referent(weak_table_t *weak_table, objc_object *referent)
前面1~6都很好理解。7开始到关键点:从SideTable取出weak_table和当前对象指针"this"当做实参传给函数weak_clear_no_lock(weak_table_t *weak_table, id referent_id)
,该函数利用weak_table
和转换后的referent_id
对象调用weak_entry_t * weak_entry_for_referent(weak_table_t *weak_table, objc_object *referent)
得到一个关于referent_id
对象的weak引用表的数组。
再看一次"weak_entry_t * weak_entry_for_referent(weak_table_t *weak_table, objc_object *referent)"函数实现细节
weak_entry_for_referent(weak_table_t *weak_table, objc_object *referent).png函数内部利用正在被dealloc的对象地址referent 通过哈希函数hash_pointer()计算,再&weak_table->mask获得begin索引,所以可推测weak_table是一个散列表结构,weak_table来自于SideTable对象中的“weak_table”成员,有了这个当前对象在散列表中的索引,就可以通过索引获取当前对象的弱引用数组了(当然根据获取到的begin索引得到的散列结果可能并不是这个“dealloc对象”的,因为存在散列冲突,所以这里面有while ()循环判断当前index散列值的“ referent”与我们传入的“ referent”是否匹配)。
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;
}
}
通过这个while循环,可见这个散列表解决散列冲突采用的是“开放寻址法”。
总结:程序运行时将弱引用存到一个哈希表中,当对象obj要销毁的时候,哈希函数根据obj地址获取到索引,然后从哈希表中取出obj对应的弱引用集合weak_entries,遍历weak_entries并一一清空(也就对应源码中函数void weak_clear_no_lock(weak_table_t *weak_table, id referent_id)
所做的*referrer = nil;
)。