标签：
一、内存管理可以追溯到手动内存管理（Manual Retain Release，简称 MRR）。在 MRR，开发者创建的每一个对象，需要声明其拥有权，从而保持对象存在于内存中，当对象不再需要的时候撤销拥有权释放它。MRR 通过引用计数系统实现这套拥有权体系，也就是说每个对象有个计数器，通过计数加1表明被一个对象拥有，减1表明不再持有。当计数为零，对象将被释放。由于手动管理内存实在太烦人，因此苹果推出了自动引用计数（ARC）来解放开发者，不再需要开发者手动添加 retain 和 release 操作，从而可以专注于 App 开发。在 ARC，开发者将会定义一个变量为“strong”或“weak”。一个 weak 弱引用无法 retain 对象，而 strong 引用会 retain 这个对象，并将其引用计数加一。
二、ARC 令许多开发者（包括我）感到失望的地方之一是苹果保留了用 ARC 来进行内存管理。ARC 很不幸地没有包括一个循环引用检测器，所以很容易就会产生循环引用，因此迫使开发者在写代码的时候采取一些特别的防范措施。
三、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模式)：
#import <Foundation/Foundation.h>
2@interface Friend : NSObject
3- (void)cleanTimer;
4@end
1#import "Friend.h"
2@interface Friend ()
3{
4NSTimer *_timer;
5}
6@end
7
8@implementation Friend
9-(id)init
10{
11if(self =[super init]) {
12_timer = [NSTimer scheduledTimerWithTimeInterval:1target:self selector:@selector(handleTimer:)
13userInfo:nil repeats:YES];
14}
15returnself;
16}
17
18- (void)handleTimer:(id)sender
19{
20NSLog(@"%@ say: Hi!", [self class]);
21}
22- (void)cleanTimer
23{
24[_timer invalidate];
25_timer =nil;
26}
27- (void)dealloc
28{
29[self cleanTimer];
30NSLog(@"[Friend class] is dealloced");
31}
在类外部初始化一个Friend对象，并延迟5秒后将friend释放(外部运行在非arc环境下)
1Friend *f =[[Friend alloc] init];
2dispatch_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!//运行了5次后没按照预想的停下来
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"
@interfaceFriend () @property (nonatomic) NSArray *arr;
@end
@implementationFriend
- (id)init { if(self =[super init]) { self.arr = @[@111, @222, @333]; self.block = ^(NSString *name){ NSLog(@"arr:%@", self.arr); }; } returnself; }
我们看到，在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的版本)
1self.arr = @[@111, @222, @333];
2__weak typeof(self) weakSelf=self;
3self.block = ^(NSString *name){
4NSLog(@"arr:%@", weakSelf.arr);
5};
2)MRC环境下：解决方式与上述基本一致，只不过将__weak关键字换成__block即可，这样的意思是告诉block：小子，不要在内部对self进行retain了！
=========================================================
（3）委托delegate
在委托问题上出现循环引用问题已经是老生常谈了，本文也不再细讲，规避该问题的杀手锏也是简单到哭，一字诀：声明delegate时请用assign(MRC)或者weak(ARC)，千万别手贱玩一下retain或者strong，毕竟这基本逃不掉循环引用了！
=======================================================
原创文章，转载请注明 编程小翁@博客园，邮件zilin_weng@163.com，微信Jilon，欢迎各位与我在C/C++/Objective-C/机器视觉等领域展开交流!
=======================================================
内存管理引出的问题
标签：
原文地址：http://www.cnblogs.com/zhuyiios/p/4954055.html
