轉自：http://www.cocoachina.com/ios/20141203/10519.html
雖然iOS 5.0版本之后加入了ARC機制，由于相互引用關系比較復雜時，內存泄露還是可能存在。所以了解原理很重要。
這里講述在沒有ARC的情況下，如何使用Instruments來查找程序中的內存泄露，以及NSZombieEnabled設置的使用。
本文假設你已經比較熟悉Obj-C的內存管理機制。
實驗的開發(fā)環(huán)境：XCode 4.5.2
1、運行Demo
先下載一個實現(xiàn)準備好的內存泄露的Demo吧：leak app
下載下來，打開運行，程序是一個壽司的列表，列出各種壽司卷。試著選擇里面的幾行，應該是選第二行的時候就崩潰了。崩潰截圖：
在崩潰的地方斷住了，知道crash的地方了，但是不知道具體crash的原因。
2、設置NSZombieEnabled
這是一個 “EXC_BAD_ACCESS”錯誤。我們打開XCode的選項：“NSZombieEnabled” 。在crash時可能會給你更多的一些提示信息。
設置步驟：
運行，按剛才的操作選中其中的cell。再次crash，這次在output窗口會看到多了一項錯誤信息：
2012-11-28 13:22:08.911 PropMemFun[2132:11303] *** -[CFString respondsToSelector:]: message sent to deallocated instance 0x713ebc0
大概意思是：向已釋放的內存發(fā)送消息。也就是說使用了已釋放的內存，在C語言相當于使用了“野指針”
看了下crash的這個語句，sushiString應該是沒問題的，它是從stringWithFormat初始化出來的。那就是_lastSushiSelected的問題。
_lastSushiSelected指向了sushiString，sushiString是一個autorelease變量。 在第二次點擊時，使用的是sushiString已經被釋放，所以crash了。那為_lastSushiSelected保留一下，就可以用了。代碼修改如下：
1
_lastSushiSelected = [sushiString retain];
運行，這時候不崩潰。
3、分析內存泄露(shift+command+b)
app不crash了，那看看有沒有內存泄露。用XCode的Analyze就能分析到哪里有內存泄露
5e8b764f9f77f614057cd02723a58f67.jpg
分析之后可以看到：
這里提示alertView沒被釋放，有內存泄露，那我們釋放
再分析，這個問題解決了。
4、使用Instruments的leaks工具
分析內存泄露不能把所有的內存泄露查出來，有的內存泄露是在運行時，用戶操作時才產生的。那就需要用到Instruments了。
按上面操作，build成功后跳出Instruments工具，選擇Leaks選項，這時候壽司程序也運行起來了，選中l(wèi)ist中的項，拖動等操作后，工具顯示效果如下：
大家可能都能猜到，紅色的柱子表示內存泄露了。怎么通過這個工具看到在哪泄露了呢?
先在工具欄按下紅色的圓形按鈕，把工具監(jiān)視內存的活動停下來。選擇Leak，然后點中間十字交叉那，選擇Call Tree.
這時候左下角的Call Tree的可選項可以選了。選中Invert Call Tree 和Hide System Libraries,顯示如下：
這時候內存泄露的具體代碼找到了，在右邊的紅色框框里指定了哪個方法出現(xiàn)了內存泄露。
你只要在這些方法上雙擊，就會跳轉到具體的代碼，哈哈，是不是很方便。
這里應該是提示100%內存會泄露。
6、解決內存泄露問題
問題找到了，那就解決吧
關于：tableView:didSelectRowAtIndexPath ，分析下它的內存過程：
sushiString變量通過autorelease創(chuàng)建，它的引用計數(shù)是1.
這行代碼使得引用計數(shù)增加到2， _lastSushiSelected = [sushiString retain];
這個方法結束時，sushiString的autorelease生效了，這個變量的引用計數(shù)減少為1
當再次執(zhí)行tableView:didSelectRowAtIndexPath這個方法時，_lastSushiSelected被賦值了新指針，老的_lastSushiSelected的引用計數(shù)還是1，沒有被釋放，產生了內存泄露。
怎么解決呢?
在_lastSushiSelected = [sushiString retain];之前把原來的release就ok了:
[_lastSushiSelected release];
_lastSushiSelected = [sushiString retain];
關于：tableView:cellForRowAtIndexPath
這個比較明顯，sushiString被alloc和init之后就沒有釋放，可以用stringWithFormat來調用autorelease，代碼如下：
NSString *sushiString = [NSString stringWithFormat:@"%d: %@", indexPath.row, sushiName];
好了，泄露都fix了，再用工具分析看看，這時候你再點，再拖，再怎么操作，都沒有內存泄露了。表明內存泄露被堵住了。
