轉(zhuǎn)載自：http://www.uml.org.cn/mobiledev/201212123.asp? （或者h(yuǎn)ttp://www.cocoachina.com/bbs/read.php?tid=129734&keyword=instrument）--》那個工程文件就到第二個鏈接里下吧烈涮，我這不知道怎么上傳到文章里
自：寫在前面猪贪，這個Leaks工具貌似也并不總對，我剛才就碰到了多運(yùn)行一會程序后汉矿，顯示有紅柱 了愕乎，但一定位定位到main函數(shù)里了阵苇，問群里一哥們，他說不用太在意感论，可能是系統(tǒng)問題绅项，先知道就行吧！
雖然iOS 5.0版本之后加入了ARC機(jī)制比肄，由于相互引用關(guān)系比較復(fù)雜時快耿，內(nèi)存泄露還是可能存在囊陡。所以了解原理很重要。
這里講述在沒有ARC的情況下掀亥，如何使用Instruments來查找程序中的內(nèi)存泄露撞反，以及NSZombieEnabled設(shè)置的使用。
本文假設(shè)你已經(jīng)比較熟悉Obj-C的內(nèi)存管理機(jī)制搪花。
實驗的開發(fā)環(huán)境：XCode 4.5.2
1遏片、運(yùn)行Demo。
先下載一個實現(xiàn)準(zhǔn)備好的內(nèi)存泄露的Demo吧：leak app
下載下來撮竿，打開運(yùn)行吮便，程序是一個壽司的列表，列出各種壽司卷倚聚。試著選擇里面的幾行线衫，應(yīng)該是選第二行的時候就崩潰了。崩潰截圖：
在崩潰的地方斷住了惑折，知道crash的地方了授账，但是不知道具體crash的原因。
2惨驶、設(shè)置NSZombieEnabled
這是一個 “EXC_BAD_ACCESS”錯誤白热。我們打開XCode的選項：“NSZombieEnabled” 。在crash時可能會給你更多的一些提示信息粗卜。
設(shè)置步驟：1
2：勾上紅色框里的
運(yùn)行屋确，按剛才的操作選中其中的cell。再次crash续扔，這次在output窗口會看到多了一項錯誤信息：
2012-11-28 13:22:08.911 PropMemFun[2132:11303] *** -[CFString respondsToSelector:]: message sent to deallocated instance 0x713ebc0
大概意思是：向已釋放的內(nèi)存發(fā)送消息攻臀。也就是說使用了已釋放的內(nèi)存，在C語言相當(dāng)于使用了“野指針”
看了下crash的這個語句纱昧，sushiString應(yīng)該是沒問題的刨啸，它是從stringWithFormat初始化出來的。那就是_lastSushiSelected的問題识脆。
_lastSushiSelected指向了sushiString设联，sushiString是一個autorelease變量。 在第二次點(diǎn)擊時灼捂，使用的是sushiString已經(jīng)被釋放离例，所以crash了。那為_lastSushiSelected保留一下悉稠，就可以用了宫蛆。代碼修改如下：
01. _lastSushiSelected = [sushiString retain];
02.
運(yùn)行，這時候不崩潰的猛。
3耀盗、分析內(nèi)存泄露(shift+command+b)
app不crash了辑甜，那看看有沒有內(nèi)存泄露。用XCode的Analyze就能分析到哪里有內(nèi)存泄露
分析之后可以看到：
這里提示alertView沒被釋放袍冷，有內(nèi)存泄露磷醋，那我們釋放
[alertView release];
再分析，這個問題解決了胡诗。
4邓线、使用Instruments的leaks工具
分析內(nèi)存泄露不能把所有的內(nèi)存泄露查出來，有的內(nèi)存泄露是在運(yùn)行時煌恢，用戶操作時才產(chǎn)生的骇陈。那就需要用到Instruments了。
按上面操作瑰抵，build成功后跳出Instruments工具你雌，選擇Leaks選項，這時候壽司程序也運(yùn)行起來了二汛，選中l(wèi)ist中的項婿崭，拖動等操作后，工具顯示效果如下：
大家可能都能猜到肴颊，紅色的柱子表示內(nèi)存泄露了氓栈。怎么通過這個工具看到在哪泄露了呢?
先在工具欄按下紅色的圓形按鈕，把工具監(jiān)視內(nèi)存的活動停下來婿着。選擇Leak授瘦，然后點(diǎn)中間十字交叉那，選擇Call Tree.
這時候左下角的Call Tree的可選項可以選了竟宋。選中Invert Call Tree 和Hide System Libraries,顯示如下：
這時候內(nèi)存泄露的具體代碼找到了提完，在右邊的紅色框框里指定了哪個方法出現(xiàn)了內(nèi)存泄露。
你只要在這些方法上雙擊丘侠，就會跳轉(zhuǎn)到具體的代碼徒欣，哈哈，是不是很方便婉陷。
這里應(yīng)該是提示100%內(nèi)存會泄露帚称。
6官研、解決內(nèi)存泄露問題
問題找到了秽澳，那就解決吧
關(guān)于：tableView:didSelectRowAtIndexPath ，分析下它的內(nèi)存過程：
sushiString變量通過autorelease創(chuàng)建戏羽，它的引用計數(shù)是1.
這行代碼使得引用計數(shù)增加到2担神， _lastSushiSelected = [sushiString retain];
這個方法結(jié)束時，sushiString的autorelease生效了始花，這個變量的引用計數(shù)減少為1
當(dāng)再次執(zhí)行tableView:didSelectRowAtIndexPath這個方法時妄讯，_lastSushiSelected被賦值了新指針孩锡，老的_lastSushiSelected的引用計數(shù)還是1，沒有被釋放亥贸，產(chǎn)生了內(nèi)存泄露躬窜。
怎么解決呢?
在_lastSushiSelected = [sushiString retain];之前把原來的release就ok了:
01.[_lastSushiSelected release];
02. _lastSushiSelected = [sushiString retain];
關(guān)于：tableView:cellForRowAtIndexPath
這個比較明顯，sushiString被alloc和init之后就沒有釋放炕置，可以用stringWithFormat來調(diào)用autorelease荣挨，代碼如下：
01.NSString *sushiString = [NSString stringWithFormat:@"%d: %@", indexPath.row, sushiName];
好了，泄露都fix了朴摊，再用工具分析看看默垄，這時候你再點(diǎn)，再拖甚纲，再怎么操作口锭，都沒有內(nèi)存泄露了。表明內(nèi)存泄露被堵住了介杆。
