循环引用的原因
众所周知，ARC下用block会产生循环引用的问题，造成泄露的原因是啥呢？
最简单的例子，如下面代码：
[self.teacher requestData:^(NSData *data) {
self.name = @"case";
}];
此种情况是最常见的循环引用导致的内存泄露了，在这里，self强引用了teacher, teacher又强引用了一个block，而该block在回调时又调用了self，会导致该block又强引用了self，造成了一个保留环，最终导致self无法释放。
self -> teacher -> block -> self
一般性的解决方案
__weak typeof(self) weakSelf = self;
[self.teacher requestData:^(NSData *data) {
typeof(weakSelf) strongSelf = weakSelf;
strongSelf.name = @"case";
}];
通过__weak的修饰，先把self弱引用（默认是强引用，实际上self是有个隐藏的__strong修饰的），然后在block回调里用weakSelf，这样就会打破保留环，从而避免了循环引用，如下：
self -> teacher -> block -> weakSelf
PS：一般会在block回调里再强引用一下weakSelf（typeof(weakSelf) strongSelf = weakSelf;），因为__weak修饰的都是存在栈内，可能随时会被系统释放，造成后面调用weakSelf时weakSelf可能已经是nil了，后面用weakSelf调用任何代码都是无效的。
通过demo证明哪些情况下有泄漏
虽然说用block时会产生循环引用，但并不是所有情况下都会有内存泄露的问题，看个demo。
先发demo地址：https://github.com/yuedong56/BlockRetainCycleDemo
- 进入demo，有个
Button，点击Buttonpush到SecondViewController， -
SecondViewController中有六种情况的Button，每点一个Button会触发一个block， - 点击返回，回到首页，如果执行了
dealloc，证明SecondViewController正常释放，否则，证明内存泄露了。
下面只贴demo里的关键代码了，全的代码请自行下载demo，大家看下面的六种情况，是否会产生内存泄漏。
//情况一
- (void)case1 {
NSLog(@"case 1 Click");
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.3 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
self.name = @"case 1";
});
}
//情况二
- (void)case2 {
NSLog(@"case 2 Click");
__weak typeof(self) weakSelf = self;
[self.teacher requestData:^(NSData *data) {
typeof(weakSelf) strongSelf = weakSelf;
strongSelf.name = @"case 2";
}];
}
//情况三
- (void)case3 {
NSLog(@"case 3 Click");
[self.teacher requestData:^(NSData *data) {
self.name = @"case 3";
}];
}
//情况四
- (void)case4 {
NSLog(@"case 4 Click");
[self.teacher requestData:^(NSData *data) {
self.name = @"case 4";
self.teacher = nil;
}];
}
//情况五
- (void)case5 {
NSLog(@"case 5 Click");
Teacher *t = [[Teacher alloc] init];
[t requestData:^(NSData *data) {
self.name = @"case 5";
}];
}
//情况六
- (void)case6 {
NSLog(@"case 6 Click");
[self.teacher callCase6BlackEvent];
self.teacher.case6Block = ^(NSData *data) {
self.name = @"case 6";
//下面两句代码任选其一
self.teacher = nil;
// self.teacher.case6Block = nil;
};
}
分析
- 情况一：执行了dealloc，不泄露，此情况虽然是block，但未形成保留环block -> self
- 情况二：执行了dealloc，不泄露，此情况就是内存泄漏后的一般处理了 self ->teacher ->block ->strongSelf，后面那个strongSelf和原来的self并没有直接关系，因为strongSelf是通过weakSelf得来的，而weakSelf又没有强引用原来的self
- 情况三：未执行dealloc，内存泄漏，此情况就是最典型的循环引用了，形成保留环无法释放，self ->teacher ->block ->self
- 情况四：执行了dealloc，不泄露，虽然也是保留环，但通过最后一句，使self不再强引用teacher，打破了保留环
- 情况五：执行了dealloc，不泄露，未形成保留环 t ->block ->self
- 情况六：执行了dealloc，不泄露，最后两句代码任选其一即可防止内存泄漏，self.teacher 或者 case6Block 置为空都可以打破 retain cycle
PS: 虽然情况四、情况六的写法都可以防止内存泄漏，不过为了统一，个人建议最好还是按照普通写法即情况二的写法。
大家有什么问题可以参考demo，以上纯属个人理解，有不正确的地方，希望大家指出，我的新浪微博：http://weibo.com/1905373741/
参考文章：
- Swift与OC真正去理解Block解决循环引用的技巧http://www.cocoachina.com/ios/20160831/17438.html#0-tsina-1-4636-397232819ff9a47a7b7e80a40613cfe1
- 《Effective Objective-C 2.0 编写高质量iOS与OS X代码的52个高效方法》第40条
- 到底什么时候才需要在ObjC的Block中使用weakSelf/strongSelf http://www.cnblogs.com/walkerwang/p/4190042.html
- http://tanqisen.github.io/blog/2013/04/19/gcd-block-cycle-retain/
