許多新人開發不太注意引用 和釋放的問題,這篇blog 比較 早,
不過寫的很簡單 易懂.mark
一下
（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!//運行了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" @interface Friend () @property (nonatomic) NSArray *arr; @end @implementation Friend - (id)init { if (self = [super init]) { self.arr = @[@111, @222, @333]; self.block = ^(NSString *name){ NSLog(@"arr:%@", self.arr); }; } return self; }
我們看到，在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
在委託問題上出現循環引用問題已經是老生常談了，本文也不再細講，規避該問題的殺手鐗也是簡單到哭，一字訣：聲明delegate時請用assign(MRC)或者weak(ARC)，千萬別手賤玩一下retain或者strong，畢竟這基本逃不掉循環引用了