ARC下用块(block)的循环引用问题样例探究
ARC下用块(block)的循环引用问题样例探究
循环引用的原因
众所周知,ARC下用block会产生循环引用的问题,造成泄露的原因是啥呢?
最简单的例子,如下面代码:
1
2
3
|
[self.teacher requestData:^(NSData *data) {
self.name = @ "case" ;
}];
|
此种情况是最常见的循环引用导致的内存泄露了,在这里,self强引用了teacher, teacher又强引用了一个block,而该block在回调时又调用了self,会导致该block又强引用了self,造成了一个保留环,最终导致self无法释放。
self -> teacher -> block -> self
一般性的解决方案
1
2
3
4
5
|
__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,点击Button push到SecondViewController,
-
SecondViewController中有六种情况的Button,每点一个Button会触发一个block,
-
点击返回,回到首页,如果执行了dealloc,证明SecondViewController正常释放,否则,证明内存泄露了。
下面只贴demo里的关键代码了,全的代码请自行下载demo,大家看下面的六种情况,是否会产生内存泄漏。
1
2
3
4
5
6
7
|
//情况一
- (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" ;
});
}
|
1
2
3
4
5
6
7
8
9
|
//情况二
- (void)case2 {
NSLog(@ "case 2 Click" );
__weak typeof (self) weakSelf = self;
[self.teacher requestData:^(NSData *data) {
typeof (weakSelf) strongSelf = weakSelf;
strongSelf.name = @ "case 2" ;
}];
}
|
1
2
3
4
5
6
7
|
//情况三
- (void)case3 {
NSLog(@ "case 3 Click" );
[self.teacher requestData:^(NSData *data) {
self.name = @ "case 3" ;
}];
}
|
1
2
3
4
5
6
7
8
|
//情况四
- (void)case4 {
NSLog(@ "case 4 Click" );
[self.teacher requestData:^(NSData *data) {
self.name = @ "case 4" ;
self.teacher = nil;
}];
}
|
1
2
3
4
5
6
7
8
|
//情况五
- (void)case5 {
NSLog(@ "case 5 Click" );
Teacher *t = [[Teacher alloc] init];
[t requestData:^(NSData *data) {
self.name = @ "case 5" ;
}];
}
|
1
2
3
4
5
6
7
8
9
10
11
|
//情况六
- (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/
参考文章:
-
《Effective Objective-C 2.0 编写高质量iOS与OS X代码的52个高效方法》第40条