本文是对《Objective-C高级编程》中__weak部分的整理，加上一部分自己的体会。

• __weak 修饰表明一种关系“非拥有关系”。弱引用，不决定对象的存亡。即使一个对象被持有无数个弱引用，只要没有强引用指向它，那么还是会被销毁。

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

weak指针如何自动置为 nil

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

{
    // 声明一个weak指针
    id __weak obj1 = obj;
}

  模拟编译器编译后的代码：

id obj1;

objc_initWeak(&obj1, obj);

objc_release(obj);

objc_destroyWeak(&obj1);

  通过objc_initWeak 函数初始化附有__weak修饰符的变量：

/* 编译器的模拟代码 */

id obj1;

obj1 = 0;

objc_storeWeak(&obj1, obj);

  objc_storeWeak函数把第二参数的赋值对象的地址作为键值，将第一参数的附有__weak修饰符的变量的地址注册到weak表中。如果第二参数为0，则把变量的地址从weak表中删除。

  weak 表与引用计数表相同，作为散列表被实现。如果使用weak表，将废弃对象的地址作为键值进行检索，就能高速地获取对应的附有weak修饰符的变量的地址。另外，由于一个对象可同时赋值给多个附有weak修饰符的变量中，所以对于一个键值，可注册多个变量的地址。


  在变量作用域结束时通过 objc_destroyWeak函数释放该变量：

/* 编译器的模拟代码 */

objc_storeWeak(&obj1, 0);

  释放对象时，废弃谁都不持有的对象的同时，程序的动作是怎样的呢？下面我们来跟踪观察。对象将通过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）从weak表中获取废弃对象的地址为键值的记录。
（2）将包含在记录中的所有附有__weak修饰符变量的地址，赋值为nil。
（3）从weak表中删除该记录。
（4）从引用计数表中删除废弃对象的地址为键值的记录。

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

以上就是一个 weak 指针从初始化到被置为nil 的全过程，在写这篇文章之前我一直有疑惑，如果是objc_clear_deallocating函数进行了weak指针置为nil的操作，那objc_destroyWeak函数是干嘛的？我反复推敲，想起来文中早已说明了用途 “在变量作用域结束时通过 objc_destroyWeak函数释放该变量”，也就是说objc_destroyWeak函数是在weak指针被置为nil后，用来将weak释放掉。

__weak立即释放对象

  使用__weak修饰符时，以下源代码会引起编译器警告。

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

  因为该源代码将自己生成并持有的对象赋值给附有__weak修饰符的变量中，所以自己不能持有该对象，这时会被释放并被废弃，因此会引起编译器警告。

warning: Assigning retained object to weak variable; object will be released after assignment

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

/*编译器的模拟代码*/
id obj；

id tmp = objc_msgSend(NSObject, @selector(alloc));

objc_msgSend(tmp, @selector(init));

objc_initweak(&obj, 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修饰符完全相同，编译器判断生成并持有的对象不能继续持有，从而发出警告。

Assigning retained object to unsafe_unretained variable; object will be released after assignment

  该源代码通过编译器转换为以下形式。

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

objc_msgSend(obj,@selector(init))；

objc_release(obj）；

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

  那么如果最初不赋值变量又会如何呢？下面的源代码在MRC时必定会发生内存泄漏。

[[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）；

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

allowsWeakReference/retainWeakReference方法

  实际上还有一种情况也不能使用__weak修饰符。
  就是当allowsWeakReference/retainWeakReference 实例方法返回NO的情况。这些方法的声明如下：

- (BOOL)allowsWeakReference UNAVAILABLE_ATTRIBUTE;
- (BOOL)retainWeakReference UNAVAILABLE_ATTRIBUTE;

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

objc[3514]: Cannot form weak reference to instance (0x6000002020b0) of class TestObject.
 It is possible that this object was over-released, or is in the process of deallocation.

  即对于所有allowsWeakReference方法返回NO的类都绝对不能使用__weak修饰符。这样的类必定在其参考说明中有所记述。
  另外，在使用__weak修饰符的变量时，当被赋值对象的retainWeakReference方法返回NO的情况下，该变量将使用“nil”。下面对retainWeakReference方法进行试验。我们做一个TestObject类，让其继承NSObject类并实现retainWeakReference方法。

#import "TestObject.h"

@interface TestObject(){
    NSInteger count;
}

@end


@implementation TestObject

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

@end

  该例中，当retainWeakReference方法被调用4次或4次以上时返回NO。以下是调用的源代码：

id __strong obj = [[TestObject alloc] init];

id __weak o = obj;

NSLog(@"1 %@", o);
NSLog(@"2 %@", o);
NSLog(@"3 %@", o);
NSLog(@"4 %@", o);
NSLog(@"5 %@", o);

  以下为执行结果：

 1 <TestObject: 0x60000000cd70>
 2 <TestObject: 0x60000000cd70>
 3 <TestObject: 0x60000000cd70>
 4 (null)
 5 (null)

  从第4次起，使用附有__weak修饰符的变量o时，由于所引用对象的retainWeakReference方法返回NO，所以无法获取对象。像这样的类也必定在其参考说明中有所记述。

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

__weak修饰符 与 __unsafe_unretained修饰符

  如上述所讲，__weak固然有很多优点，遗憾的是，__weak修饰符只能用于 iOS5 以上及 OS X Lion 以上版本的应用程序。在 iOS4 以及 OS X Snow Leopard 的应用程序中只能使用__unsafe_unretained修饰符来代替。

  __unsafe_unretained修饰符正如其名unsafe所示，是不安全的所有权修饰符。尽管ARC式的内存管理是编译器的工作，但附有__unsafe_unretained修饰符的变量不属于编译器的内存管理对象。这一点在使用时要注意。

• __weak修饰的指针变量不持有对象，可以避免循环引用

• __unsafe_unretained修饰的指针变量不持有对象，可以避免循环引用

• __weak修饰的指针变量指向的对象被释放后，__weak修饰的指针会自动被置为nil

• __unsafe_unretained修饰的指针变量指向的对象被释放后，__unsafe_unretained修饰的指针不会自动被置为nil，随即变成悬垂指针。