weak指针的线程安全和自动置nil的深度探讨

前言：

请思考两个问题。
1. weak指针置为nil是线程安全的吗？问详细点就是：当一个对象正在delloc时，如果在另一个线程获取了weak指针，这时获取weak怎么保证线程安全？
2.weak指针会自动置为nil的原因就是在一个对象的delloc中会去弱引用表里面查找所存储weak指针的数组，然后去遍历置为nil。相信这个结论家都比较认同。但是，如果一个类重写delloc方法，且设置为MRC并不调用super delloc。也就是说这个类必定不能顺利的完成delloc，并不能把指针置为nil，但是当获取weak指针的时候，weak指针却神奇地为nil。难道之前的结论是错误的？

---

第二个问题是由这篇博客最后遗留下的问题，很感谢博主这样的优质文章，第一个问题是之前有朋友问过我，我在查找第二个问题时发现的。

---

先上测试代码。YYEobject继承NSObject，重写delloc不调用super，一定要设置YYEobject为MRC，故意发生内存泄漏

-(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
    __weak YYEobject* weakObj = nil;
    @autoreleasepool{
        YYEobject *obj = [[YYEobject alloc] init];
        weakObj = obj;
    }
    NSLog(@"weakObj:%@", weakObj);//断点打在这
}

按正常思路分析，YYEobject由于没有调用super，所以不能有效的清除弱指针，发生内存泄漏，所以，应该能打印出weakObj，但是打印结果却是weakObj:(null)。结果不按套路出牌，这里不应该置nil才对的。
首先看一下汇编代码，略懂即可，不懂也能看出个大概。Debug-->Debug workflow -->Always show Disassembli。

    0x1089a2a78 <+184>: callq  0x1089a3184               ; symbol stub for: objc_autoreleasePoolPop
    0x1089a2a7d <+189>: jmp    0x1089a2a82               ; <+194> at ViewController.m
    0x1089a2a82 <+194>: leaq   -0x28(%rbp), %rdi
->  0x1089a2a86 <+198>: callq  0x1089a31ae               ; symbol stub for: objc_loadWeakRetained
    0x1089a2a8b <+203>: movq   %rax, %rdi
    0x1089a2a8e <+206>: leaq   0x28bb(%rip), %rcx        ; @"weakObj:%@"

断点打在打印weak指针地那个一行。通过注释，可也看出weak指针的获取是通过objc_loadWeakRetained这个函数来获取的，并非直接获取weak指针。猜想问题应该就出现在这个函数，之前也做过一些论证，比如给obj关联一个对象，发现关联对象也没有被清除，所以排除了delloc里面清空了弱指针，这里没有delloc什么事，所以跟以前delloc清空弱指针的逻辑没有关系。

锁定了objc_loadWeakRetained这个函数，然后来到runtime源码，去查看一下该函数。

/*
  Once upon a time we eagerly cleared *location if we saw the object 
  was deallocating. This confuses code like NSPointerFunctions which 
  tries to pre-flight the raw storage and assumes if the storage is 
  zero then the weak system is done interfering. That is false: the 
  weak system is still going to check and clear the storage later. 
  This can cause objc_weak_error complaints and crashes.
  So we now don't touch the storage until deallocation completes.
*/

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()) {
            result = nil;
        }
    }
    else {
        // Slow case. We must check for +initialize and call it outside
        // the lock if necessary in order to avoid deadlocks.
        if (cls->isInitialized() || _thisThreadIsInitializingClass(cls)) {
            BOOL (*tryRetain)(id, SEL) = (BOOL(*)(id, SEL))
                class_getMethodImplementation(cls, SEL_retainWeakReference);
            if ((IMP)tryRetain == _objc_msgForward) {
                result = nil;
            }
            else if (! (*tryRetain)(obj, SEL_retainWeakReference)) {
                result = nil;
            }
        }
        else {
            table->unlock();
            _class_initialize(cls);
            goto retry;
        }
    }
        
    table->unlock();
    return result;
}

结论1：weak置nil是线程安全

相信很多同学仔细阅读这个函数。开头我提地第一个问题也就有了答案，weak置nil是线程安全的，因为，每次获取weak指针通过这个函数，函数里面如果判断有值或者是非TaggedPointer指针，会去弱引用表里面取值，同时对引用计数表枷锁，保证线程安全，所以这就是苹果保证获取weak线程安全的解决方案。

第二个问题依然存在，前期猜测，是弱引用表的weak指针并没有被置为nil，objc_loadWeakRetained函数里面有几处会直接返回nil，但是才疏学浅，我无法确定具体哪返回地nil。这是还要回到汇编代码，结合LLDB动态调试，希望能抓到蛛丝马迹，发现走了retainWeakReference这个函数。结合源码也可以看出，如果tryRetain返回为NO，将会直接返回nil对象

LXDZombieSniffer`-[YYEobject retainWeakReference]:
->  0x102611510 <+0>:  pushq  %rbp
    0x102611511 <+1>:  movq   %rsp, %rbp
    0x102611514 <+4>:  movb   $0x1, %al
    0x102611516 <+6>:  movq   %rdi, -0x8(%rbp)
    0x10261151a <+10>: movq   %rsi, -0x10(%rbp)
    0x10261151e <+14>: andb   $0x1, %al
    0x102611520 <+16>: movzbl %al, %eax
    0x102611523 <+19>: popq   %rbp
    0x102611524 <+20>: retq   

，retainWeakReference函数是可以重写地，在YYEobject里面重写retainWeakReference方法，直接返回YES。

然后重新运行了代码。果然weak指针没有置为nil，也打印出了值。问题得到了定位。

weakObj://weak没有被置为nil，打印正常了

结论2：获取weak的指向为nil，其真是的弱引用表可能没有清空，或者正在被清空，但我们取值weak指针地值是nil，始作俑者是objc_loadWeakRetained方法。会直接返回nil给我们使用，其真正的弱指针还是存在的，还是指向该对象的。

在runtime源码里面追踪retainWeakReference地实现，最终来的了objc_object::rootRetain函数，猜想

应该是isa指针的是否正在被delloc的位域起了作用。如果一个对象
被标记为正在被delloc，那么获取其weak指针会被直接返回nil。与其weak指针的真身无关。