__weak 修饰符

就像前面咱们看到的同样，__weak 修饰符提供的功能如同魔法通常。

1,若附有__weak 修饰符的变量所引用的对象被废弃，则将nil 赋值给该变量。

2,使用附有__weak 修饰符的变量，便是使用注册到autoreleasepool 中的对象。

1,若附有__weak 修饰符的变量所引用的对象被废弃，则将nil 赋值给该变量。

这些功能像魔法同样，到底发生了什么，咱们一无所知。因此下面咱们来看看它们的实现。

{   
     id __weak obj1 = obj;
}

假设变量obj 附加__strong 修饰符且对象被赋值。

/* 编译器的模拟代码 */
id obj1;
objc_initWeak(&obj1, obj);
objc_destroyWeak(&obj1);

经过objc_initWeak 函数初始化附有_ _ weak 修饰符的变量，在变量做用域结束时经过objc_destroyWeak 函数释放该变量。

如如下源代码所示，objc_initWeak 函数将附有_ _ weak 修饰符的变量初始化为0 后，会将赋值的对象做为参数调用objc_storeWeak 函数。

obj1 = 0;
objc_storeWeak(&obj1, obj);

//objc_destroyWeak 函数将0 做为参数调用objc_storeWeak 函数。
objc_storeWeak(&obj1, 0);

即前面的源代码与下列源代码相同。

/* 编译器的模拟代码 */
id obj1;obj1 = 0;
objc_storeWeak(&obj1, obj);
objc_storeWeak(&obj1, 0);

objc_storeWeak 函数把第二参数的赋值对象的地址做为键值，将第一参数的附有_ _ weak 修饰符的变量的地址注册到weak 表中。

若是第二参数为0，则把变量的地址从weak 表中删除。

weak 表与引用计数表（参考1.2.4 节）相同，做为散列表被实现。若是使用weak 表，将废弃对象的地址做为键值进行检索，就能高速地获取对应的附有_ _ weak 修饰符的变量的地址。

另外，因为一个对象可同时赋值给多个附有_ _ weak 修饰符的变量中，因此对于一个键值，可注册多个（weak）变量的地址。

释放对象时，废弃谁都不持有的对象的同时，程序的动做是怎样的呢？下面咱们来跟踪观察。对象将经过objc_release 函数释放。

（1）objc_release

（2）由于引用计数为0 因此执行dealloc

（3）_objc_rootDealloc

（4）object_dispose

（5）objc_destructInstance

（6）objc_clear_deallocating

对象被废弃时最后调用的objc_clear_deallocating 函数的动做以下：

1. （1）从weak 表中获取废弃对象的地址为键值的记录。

2. （2）将包含在记录中的全部附有_ _ weak 修饰符变量的地址，赋值为nil。

3. （3）从weak 表中删除该记录。

4. （4）从引用计数表中删除废弃对象的地址为键值的记录。

根据以上步骤，前面说的若是附有_ _ weak 修饰符的变量所引用的对象被废弃，则将nil 赋值给该变量这一功能即被实现。由此可知，若是大量使用附有_ _ weak 修饰符的变量，则会消耗相应的CPU 资源。良策是只在须要避免循环引用时使用_ _ weak 修饰符。

使用_ _ weak 修饰符时，如下源代码会引发编译器警告。

{
    id __weak obj = [[NSObject alloc] init];
}

由于该源代码将本身生成并持有的对象赋值给附有_ _ weak 修饰符的变量中，因此本身不能持有该对象，这时会被释放并被废弃，所以会引发编译器警告。

warning: assigning retained obj to weak variable; obj will be
      released after assignment [-Warc-unsafe-retained-assign]
        id __weak obj = [[NSObject alloc] init];
                  ^     ~~~~~~~~~~~~~~

编译器如何处理该源代码呢？

/* 编译器的模拟代码 */
id obj;
id tmp = objc_msgSend(NSObject, @selector(alloc));
objc_msgSend(tmp, @selector(init));
objc_initWeak(&obj, tmp);
objc_release(tmp); // 由于此时只有一个强引用，因此对象被释放了
objc_destroyWeak(&object);

虽然本身生成并持有的对象经过objc_initWeak 函数被赋值给附有_ _ weak 修饰符的变量中，但编译器判断其没有持有者（即 强引用），故该对象当即经过objc_release 函数被释放和废弃。

这样一来，nil 就会被赋值给引用废弃对象的附有_ _ weak 修饰符的变量中。

下面咱们经过NSLog 函数来验证一下。

{
    id __weak obj = [[NSObject alloc] init];
    NSLog(@"obj=%@", obj);
}

如下为该源代码的输出结果，其中用%@ 输出nil。

obj=(null)

关于“当即释放对象”

如前所述，如下源代码会引发编译器警告。

id __weak obj = [[NSObject alloc] init];

这是因为编译器判断生成并持有的对象不能继续持有。附有__unsafe_unretained修饰符的变量又如何呢？

id __unsafe_unretained obj = [[NSObject alloc] init];

与__weak修饰符彻底相同，编译器判断生成并持有的对象不能继续持有，从而发出警告。
warning: assigning retained object to unsafe_unretained variable;
      obj will be released after assignment [-Warc-unsafe-retained-assign]
    id __unsafe_unretained obj = [[NSObject alloc] init];
                           ^     ~~~~~~~~~~~~~~~~~~~~~~~

该源代码经过编译器转换为如下形式。

/* 编译器的模拟代码 */
id obj = objc_msgSend(NSObject, @selector(alloc));
objc_msgSend(obj, @selector(init));
objc_release(obj);

objc_release函数当即释放了生成并持有的对象，这样该对象的悬垂指针被赋值给变量obj中。

那么若是最初不赋值变量又会如何呢？下面的源代码在ARC无效时一定会发生内存泄漏。
[[NSObject alloc] init];

因为源代码不使用返回值的对象，因此编译器发出警告。
warning: expression result unused [-Wunused-value]
    [[NSObject alloc] init];
    ^~~~~~~~~~~~~~~~~~~~~~~

可像下面这样经过向void型转换来避免发生警告。
(void)[[NSObject alloc] init];

不论是否转换为void，该源代码都会转换为如下形式
/* 编译器的模拟代码 */
id tmp = objc_msgSend(NSObject, @selector(alloc));
objc_msgSend(tmp, @selector(init));
objc_release(tmp);

虽然没有指定赋值变量，但与赋值给附有__unsafe_unretained修饰符变量的源代码彻底相同。因为不能继续持有生成并持有的对象，因此编译器生成了当即调用objc_release函数的源代码。而因为ARC的处理，这样的源代码也不会形成内存泄漏。

另外，能调用被当即释放的对象的实例方法吗？
(void)[[[NSObject alloc] init] hash];

该源代码可变为以下形式：
/* 编译器的模拟代码 */
id tmp = objc_msgSend(NSObject, @selector(alloc));
objc_msgSend(tmp, @selector(init));
objc_msgSend(tmp, @selector(hash));
objc_release(tmp);

在调用了生成并持有对象的实例方法后，该对象被释放。看来“由编译器进行内存管理”这句话应该是正确的。

2，此次咱们再用附有_ _ weak 修饰符的变量来确认另外一功能：使用附有_ _ weak 修饰符的变量，便是使用注册到autoreleasepool 中的对象。

{
    id __weak obj1 = obj;
    NSLog(@"%@", obj1);
}

该源代码可转换为以下形式：

/* 编译器的模拟代码 */
id obj1;
objc_initWeak(&obj1, obj);
id tmp = objc_loadWeakRetained(&obj1);
objc_autorelease(tmp);
NSLog(@"%@", tmp);
objc_destroyWeak(&obj1);

与被赋值时相比，在使用附有_ _ weak 修饰符变量的情形下，增长了对objc_loadWeakRetained函数和objc_autorelease 函数的调用。这些函数的动做以下。

（1）objc_loadWeakRetained 函数取出附有_ _ weak 修饰符变量所引用的对象并retain。

（2）objc_autorelease 函数将对象注册到autoreleasepool 中。

由此可知，由于附有_ _ weak 修饰符变量所引用的对象像这样被注册到autoreleasepool 中，因此在@autoreleasepool 块结束以前均可以放心使用。可是，若是大量地使用附有_ _ weak 修饰符的变量，注册到autoreleasepool 的对象也会大量地增长，所以在使用附有_ _ weak 修饰符的变量时，最好先暂时赋值给附有_ _ strong 修饰符的变量后再使用。

好比，如下源代码使用了5 次附有_ _ weak 修饰符的变量o。

{
    id __weak o = obj;
    NSLog(@"1 %@", o);
    NSLog(@"2 %@", o);
    NSLog(@"3 %@", o);
    NSLog(@"4 %@", o);
    NSLog(@"5 %@", o);
}

相应地，变量o 所赋值的对象也就注册到autoreleasepool 中5 次。

objc[14481]: ##############
objc[14481]: AUTORELEASE POOLS for thread 0xad0892c0
objc[14481]: 6 releases pending.
objc[14481]: [0x6a85000]  ................  PAGE  (hot) (cold)
objc[14481]: [0x6a85028]  ################  POOL 0x6a85028
objc[14481]: [0x6a8502c]         0x6719e40  NSObject
objc[14481]: [0x6a85030]         0x6719e40  NSObject
objc[14481]: [0x6a85034]         0x6719e40  NSObject
objc[14481]:  [0x6a85038]         0x6719e40  NSObject
objc[14481]: [0x6a8503c]         0x6719e40  NSObject
objc[14481]: ##############

将附有_ _ w e a k 修饰符的变量o 赋值给附有_ _ s t r o n g 修饰符的变量后再使用能够避免此类问题。

{
    id __weak o = obj;
    id tmp = o;
    NSLog(@"1 %@", tmp);
    NSLog(@"2 %@", tmp);
    NSLog(@"3 %@", tmp);
    NSLog(@"4 %@", tmp);
    NSLog(@"5 %@", tmp);
}

在“tmp = o;”时对象仅登陆到autoreleasepool 中1 次。

objc[14481]: ##############
objc[14481]: AUTORELEASE POOLS for thread 0xad0892c0
objc[14481]: 2 releases pending.
objc[14481]: [0x6a85000]  ................  PAGE  (hot) (cold)
objc[14481]: [0x6a85028]  ################  POOL 0x6a85028
objc[14481]: [0x6a8502c]         0x6719e40  NSObject
objc[14481]: ##############

在iOS4 和OS  X  Snow  Leopard 中是不能使用_ _ weak 修饰符的，而有时在其余环境下也不能使用。实际上存在着不支持_ _ weak 修饰符的类。

例如NSMachPort 类就是不支持_ _ weak 修饰符的类。这些类重写了retain/release 并实现该类独自的引用计数机制。可是赋值以及使用附有_ _ weak 修饰符的变量都必须恰当地使用objc4运行时库中的函数，所以独自实现引用计数机制的类大多不支持_ _ weak 修饰符。

不支持_ _ weak 修饰符的类，其类声明中附加了“_ _ attribute_ _ （（objc_arc_weak_reference_unavailable））”这一属性，同时定义了NS_AUTOMATED_REFCOUNT_WEAK_UNAVAILABLE。

若是将不支持_ _ weak 声明类的对象赋值给附有_ _ weak 修饰符的变量，那么一旦编译器检验出来就会报告编译错误。并且在Cocoa 框架类中，不支持_ _ weak 修饰符的类极为罕见，所以没有必要太过担忧。

专栏allowsWeakReference/retainWeakReference 方法实际上还有一种状况也不能使用__weak修饰符。

就是当allowsWeakReference/retainWeakReference实例方法（没有写入NSObject接口说明文档中）返回NO的状况。这些方法的声明以下：
- (BOOL)allowsWeakReference;
- (BOOL)retainWeakReference;

在赋值给__weak修饰符的变量时，若是赋值对象的allowsWeakReference方法返回NO，程序将异常终止。

cannot form weak reference to instance (0x753e180) of class MyObject即对于全部allowsWeakReference方法返回NO的类都绝对不能使用__weak修饰符。这样的类一定在其参考说明中有所记述。

另外，在使用__weak修饰符的变量时，当被赋值对象的retainWeakReference方法返回NO的状况下，该变量将使用“nil”。如如下的源代码：

{
    id __strong obj = [[NSObjectalloc] init];
    id __weak o = obj;
    NSLog(@"1 %@", o);
    NSLog(@"2 %@", o);
    NSLog(@"3 %@", o);
    NSLog(@"4 %@", o);
    NSLog(@"5 %@", o);
}

因为最开始生成并持有的对象为附有__strong修饰符变量obj所持有的强引用，因此在该变量做用域结束以前都始终存在。所以以下所示，在变量做用域结束以前，能够持续使用附有__weak修饰符的变量o所引用的对象。
1 <NSObject: 0x753e180>
2 <NSObject: 0x753e180>
3 <NSObject: 0x753e180>
4 <NSObject: 0x753e180>
5 <NSObject: 0x753e180>

下面对retainWeakReference方法进行试验。咱们作一个MyObject类，让其继承NSObject类并实现retainWeakReference方法。

@interfaceMyObject : NSObject
{
    NSUInteger count;
}
@end

@implementationMyObject
- (id)init
{
    self = [super init];
    return self;
}

- (BOOL)retainWeakReference
{
    if (++count > 3)
        return NO;
    return [super retainWeakReference];
}

@end

该例中，当retainWeakReference方法被调用4次或4次以上时返回NO。在以前的源代码中，将从NSObject类生成并持有对象的部分更改成MyObject类。
{
    id __strong obj = [[MyObject alloc] init];
    id __weak o = obj;
    NSLog(@"1 %@", o);
    NSLog(@"2 %@", o);
    NSLog(@"3 %@", o);
    NSLog(@"4 %@", o);
    NSLog(@"5 %@", o);
}
如下为执行结果。
1 <MyObject: 0x753e180>
2 <MyObject: 0x753e180>
3 <MyObject: 0x753e180>
4 (null)
5 (null)
从第4次起，使用附有__weak修饰符的变量o时，因为所引用对象的retainWeakRef-erence方法返回NO，因此没法获取对象。像这样的类也一定在其参考说明中有所记述。

另外，运行时库为了操做__weak修饰符在执行过程当中调用allowsWeakReference/retainWeakReference方法，所以从该方法中再次操做运行时库时，其操做内容会永久等待。本来这些方法并无记入文档，所以应用程序编程人员不可能实现该方法群，但若是因某些缘由而不得不实现，那么仍是在所有理解的基础上实现比较好。