循环引用的浅谈

简介

ARC已经出来很久了，自动释放内存的确很方便，但是并非绝对安全绝对不会产生内存泄露。导致iOS对象无法按预期释放的一个无形杀手是——循环引用。循环引用可以简单理解为A引用了B，而B又引用了A，双方都同时保持对方的一个引用，导致任何时候引用计数都不为0，始终无法释放。若当前对象是一个ViewController，则在dismiss或者pop之后其dealloc无法被调用，在频繁的push或者present之后内存暴增，然后APP就挂了。

*注：全文提到的析构指的是析构函数，oc中特有的函数，析构函数声明为“－（void）dealloc”这个函数我们不能通过对象去人为的调用它，析构函数会在对像快要死的时候自己运行，析构函数只能有一个

下面举例说明在mrc下循环引用出现的情况：

1.在People.h类中声明一个Student类型的属性

#import <Foundation/Foundation.h>
@class Student;

@interface People : NSObject

//这里不用retain,如果使用retain的话，会形成循环引用
@property(nonatomic,assign,readwrite) Student *stu;

@end

2.在People.m类中的dealloc析构方法

#import People.h
//#import "Student.h"
 
@implementation People
 
- (void)dealloc{
   // [_stu release];
    [super dealloc];
}
 
@end

3.在Student.h类中声明一个People类型的属性

#import <Foundation/Foundation.h>
@class People;
 
@interface Student : NSObject
 
@property(nonatomic,retain,readwrite) People *people;
 
@end

4.在Student.m类中的dealloc析构方法

#import "Student.h"
#import "People.h"
 
@implementation Student
 
- (void)dealloc{
    [_people release];
    [super dealloc];
}
 
@end

5.在main.m中测试其代码

#import "Student.h"
#import "People.h"
 
//循环引用
//是一个很麻烦的一件事，完全靠经验
int main(int argc, const char * argv[]) {
     
    People *p = [[People alloc] init];
    Student *stu = [[Student alloc] init];
     
    [p setStudent:stu];//stu计数:2
     
    [stu setPeople:p];//people计数:2
     
    [p release]; //people计数：1
    [stu release];//stu计数：1
     
    //没有释放的原因是dealloc方法中没有被执行，里面的释放代码也就没执行了，stu和people各自在等待，形成环状了
    //解决版本就是切断他们之间的联系
    //@property中不使用retain,使用assgin
     
    return 0;
}

我们分别定义了一个People对象和Student对象，然后相互引用了，但是当我们调用他们的release方法的时候，这两个对象并没有被释放
原因很简单：
People和Student的相互引用了，当执行release方法的时候引用计数都还是1，所以就不会调用dealloc方法了
dealloc方法中没有被执行，里面的释放代码也就没执行了，Student和People各自在等待，形成环状了

解决的办法是：
切断他们之间的联系
在一方中定义属性的时候，@property中不使用retain,使用assgin
同时在dealloc方法中不再调用release方法了
上面的例子中，我们可以看到People类中就是使用assgin

下面举例说明在arc下循环引用出现的情况：

1. 定时器的使用有时会导致循环引用
   一方面，NSTimer经常会被作为某个类的成员变量，而NSTimer初始化时要指定self为target，容易造成循环引用。 另一方面，若timer一直处于validate的状态，则其引用计数将始终大于0。比如当定时器销毁的时机不对，在dealloc里面销毁的时候,内存就不会释放，就会造成循环引用
   NSTimer使用的例子
   Friend.h文件

1 #import <Foundation/Foundation.h>
2 @interface Friend : NSObject
3 - (void)cleanTimer;
4 @end

Friend.m文件

 1 #import "Friend.h"
 2 @interface Friend ()
 3 {
 4     NSTimer *_timer;
 5 }
 6 @end
 7 
 8 @implementation Friend
 9 - (id)init
10 {
11     if (self = [super init]) {
12         _timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(handleTimer:)
13                                                 userInfo:nil repeats:YES];
14     }
15     return  self;
16 }
17 
18 - (void)handleTimer:(id)sender
19 {
20     NSLog(@"%@ say: Hi!", [self class]);
21 }
22 - (void)cleanTimer
23 {
24     [_timer invalidate];
25     _timer = nil;
26 }
27 - (void)dealloc
28 {
29     [self cleanTimer];
30     NSLog(@"[Friend class] is dealloced");
31 }

在main.m中声明并且调用，通过函数让Friend类延时5秒后引用计数减一

1 #import "Friend.h"
2
3 //循环引用
4 //是一个很麻烦的一件事，完全靠经验
5 int main(int argc, const char * argv[]) {
 6    
 7     Friend *friend = [[Friend alloc] init];
 8     dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 95*NSEC_PER_SEC), dispatch_get_main_queue(), ^{
10             [friend release];
11    });
12
13    return 0;
14 }

我们所期待的结果是，初始化5秒后，friend对象被release，friend的dealloc方法被调用，在dealloc里面timer失效，对象被析构。但结果却是如此：

这是为什么呢？主要是因为从timer的角度，timer认为调用方(Friend对象)被析构时会进入dealloc，在dealloc可以顺便将timer的计时停掉并且释放内存；但是从Friend的角度，他认为timer不停止计时不析构，那我永远没机会进入dealloc。循环引用，互相等待，无穷尽。问题的症结在于-(void)cleanTimer函数的调用时机不对，显然不能想当然地放在调用者的dealloc中。一个比较好的解决方法是开放这个函数，让Friend的调用者显式地调用来清理现场。如下：

2. block的使用有时会导致循环引用
   block在copy时都会对block内部用到的对象进行强引用(ARC)或者retainCount增1(非ARC)。在ARC与非ARC环境下对block使用不当都会引起循环引用问题，一般表现为，某个类将block作为自己的属性变量，然后该类在block的方法体里面又使用了该类本身，简单说就是self.someBlock = ^(Type var){[self dosomething];或者self.otherVar = XXX;或者_otherVar = ...};block的这种循环引用会被编译器捕捉到并及时提醒。
   block使用的例子
   Friend.m文件

1 #import "Friend.h"
2 
3 @interface Friend ()
4 @property (nonatomic) NSArray *arr;
5 @end
6 
7 @implementation Friend
8 - (id)init
9 {
10    if (self = [super init]) {
11        self.arr = @[@111, @222, @333];
12        self.block = ^(NSString *name){
13           NSLog(@"arr:%@", self.arr);
14        };
15    }
16    return  self;
17}

我们看到，在block的实现内部又使用了Friend类的arr属性，xcode给出了warning， 运行程序之后也证明了Friend对象无法被析构：

网上大部分帖子都表述为"block里面引用了self导致循环引用"，但事实真的是如此吗？我表示怀疑，其实这种说法是不严谨的，不一定要显式地出现"self"字眼才会引起循环引用。我们改一下代码，不通过属性self.arr去访问arr变量，而是通过实例变量_arr去访问，如下

由此我们知道了，即使在你的block代码中没有显式地出现"self"，也会出现循环引用！只要你在block里用到了self所拥有的东西！但对于这种情况，目前我不知道该如何排除掉循环引用，因为我们无法通过加__weak声明或者__block声明去禁止block对self进行强引用或者强制增加引用计数。对于self.arr的情况，我们要分两种环境去解决

1. ARC环境下：ARC环境下可以通过使用_weak声明一个代替self的新变量代替原先的self，我们可以命名为weakSelf。通过这种方式告诉block，不要在block内部对self进行强制strong引用：(如果要兼容ios4.3，则用__unsafe_unretained代替__weak，不过目前基本不需考虑这么low的版本)

1          self.arr = @[@111, @222, @333];
2         __weak typeof(self) weakSelf=self;
3         self.block = ^(NSString *name){
4             NSLog(@"arr:%@", weakSelf.arr);
5         };

2. MRC环境下：解决方式与上述基本一致，只不过将__weak关键字换成__block即可，这样的意思是告诉block：小子，不要在内部对self进行retain了！

3. 代理的使用有时会导致循环引用
   声明delegate时请用assign(MRC)或者weak(ARC)，千万别手贱玩一下retain或者strong，毕竟这基本逃不掉循环引用了