ARC已经出来很久了，自动释放内存的确很方便，但是并非绝对安全绝对不会产生内存泄露。导致iOS对象无法按预期释放的一个无形杀手是——循环引用。循环引用可以简单理解为A引用了B，而B又引用了A，双方都同时保持对方的一个引用，导致任何时候引用计数都不为0，始终无法释放。若当前对象是一个ViewController，则在dismiss或者pop之后其dealloc无法被调用，在频繁的push或者present之后内存暴增，然后APP就duang地挂了。下面列举我们变成中比较容易碰到的三种循环引用的情形。
（1）计时器NSTimer
一方面，NSTimer经常会被作为某个类的成员变量，而NSTimer初始化时要指定self为target，容易造成循环引用。 另一方面，若timer一直处于validate的状态，则其引用计数将始终大于0。先看一段NSTimer使用的例子(ARC模式)：
1 #import <Foundation/Foundation.h>
2 @interface Friend : NSObject
3 - (void)cleanTimer;
4 @end
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 }
在类外部初始化一个Friend对象，并延迟5秒后将friend释放(外部运行在非arc环境下)
1 Friend *f = [[Friend alloc] init];
2 dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5*NSEC_PER_SEC), dispatch_get_main_queue(), ^{
4 [f release];
5 });
我们所期待的结果是，初始化5秒后，f对象被release，f的dealloc方法被调用，在dealloc里面timer失效，对象被析构。但结果却是如此：
|
1
2
3
4
5
6
7
8
9
10
|
2015-03-18 18:00:35.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:36.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:37.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:38.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:39.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:40.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:41.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:42.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:43.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:44.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!<br>.......根本停不下来.....
|
这是为什么呢？主要是因为从timer的角度，timer认为调用方(Friend对象)被析构时会进入dealloc，在dealloc可以顺便将timer的计时停掉并且释放内存；但是从Friend的角度，他认为timer不停止计时不析构，那我永远没机会进入dealloc。循环引用，互相等待，子子孙孙无穷尽也。问题的症结在于-(void)cleanTimer函数的调用时机不对，显然不能想当然地放在调用者的dealloc中。一个比较好的解决方法是开放这个函数，让Friend的调用者显式地调用来清理现场。如下：
|
1
2
3
4
5
|
Friend *f = [[Friend alloc] init];
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5*
NSEC_PER_SEC
), dispatch_get_main_queue(), ^{
[f cleanTimer];
[f release];
});
|
=======================================
（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的这种循环引用会被编译器捕捉到并及时提醒。举例如下，依旧以Friend类为例子：
#import "Friend.h"
@interface Friend ()
@property (nonatomic) NS