##ARC下的內存泄漏

ARC全稱叫 ARC(Automatic Reference Counting)。在編譯期間，編譯器會判斷對象的使用情況，并適當的加上retain和release，使得對象的內存被合理的管理。所以，從本質上說ARC和MRC在本質上是一樣的，都是通過引用計數的內存管理方式。ARC 的出現大大節省了程序員手動管理內存的時間成本，But，世上沒有完美的事物，我們也不要把任何事想的那么美好，在 ARC 環境下如果不注意的話也會引起內存泄漏。

目前在項目中引入了MLeaksFinder,能比較清晰的找到內存泄漏的位置。

##分析一下內存泄漏的主要原因

####循環引用（Retain Cycle）

什么是引用循環（retain cycle） ?假設我們有兩個實例A和B，B是A的一個strong型的property，則B的引用計數是1，當A的需要釋放的時候，A則會調用[B release]來釋放B，B的引用計數則減為0，釋放。

?可如果這時候將B的一個strong型property指向A，則A與B互相為強引用，問題就來了。因為B強引用A，A的引用計數永遠不會減為0，當A原本的強引用對象被釋放以后，A和B成為了一個相互引用的孤島，永遠不會被釋放了，這就會引起內存泄漏。

?在上面的例子中，就是一種非常普遍的引用循環情況，加入如上代碼的VC在dismiss或者pop以后，并不會執行dealloc方法，證明內存泄漏了。而引起泄漏的原因就是在作為self的property的block中，使用self指針導致self被block強引用，形成引用循環。

1、Delegate 我們在使用代理設計模式的時候，一定要注意將 delegate 變量聲明為 weak 類型，像這樣 @property (nonatomic, weak) id<xxxx> delegate; 如使用strong或別的類型修飾的話將會導致循環引用，導致dealloc()不會被調用。從而觸發一些意想不到的后果。

2、Block 目前在項目中出現的內存泄漏大部分是因為block的問題。 在 ARC 下，當 block 獲取到外部變量時，由于編譯器無法預測獲取到的變量何時會被突然釋放，為了保證程序能夠正確運行，讓 block 持有獲取到的變量，向系統聲明：我要用它，你們千萬別把它回收了！然而，也正因 block 持有了變量，容易導致變量和 block 的循環引用，造成內存泄露！

? ? [_sortButton setButtonSpreadPreAction:^BOOL{if (_resultItems.count == 0) {[progressHUD showText:@"xxxx"];return NO;}return YES;}];
復制代碼

這個例子的問題就在于在使用 block 的過程中形成了循環引用：self 持有 sortButton；sortButton 持有 block；block 持有 self。三者形成循環引用，內存泄露。

GCD已經一些系統級的API并不會提示循環引用的警告，但通過測試發現，大部分系統提供block也是需要弱引用的__weak typeof(self) weakSelf = self; 項目中除了AFN的第三方組件在調用block時都是需要弱引用的，如MJRefresh。

3、NSTimer ?NSTimer在VC釋放前，一定要調用[timer invalidate]，不調用的后果就是NSTimer無法釋放其target，如果target正好是self，則會導致引用循環。

?這里要補充一點，引用循環不是只能有兩個對象，三個四個更多都是可以的，甚至環數也不一定只有一個，所以要養成良好的代碼習慣，在NSTimer停用前調用invalidate方法。

關于performSelector:afterDelay的問題

- (void)performSelector:(SEL)aSelector withObject:(id)anArgument afterDelay:(NSTimeInterval)delay
復制代碼

我們還是看看官方文檔怎么說的。 This method sets up a timer to perform the aSelector message on the current thread’s run loop. The timer is configured to run in the default mode (NSDefaultRunLoopMode). When the timer fires, the thread attempts to dequeue the message from the run loop and perform the selector. It succeeds if the run loop is running and in the default mode; otherwise, the timer waits until the run loop is in the default mode.

大概意思是系統依靠一個timer來保證延時觸發，但是只有在runloop在default mode的時候才會執行成功，否則selector會一直等待run loop切換到default mode。根據我們之前關于timer 的說法，在這里其實調用performSelector:afterDelay:同樣會造成系統對target強引用，也即retain住。這樣子，如果selector一直無法執行的話（比如runloop不是運行在default model下）,這樣子同樣會造成target一直無法被釋放掉，發生內存泄露。怎么解決這個問題呢？其實很簡單，我們在適當的時候取消掉該調用就行了，系統提供了接口:

+ (void)cancelPreviousPerformRequestsWithTarget:(id)aTarget
復制代碼