转自:http://blog.csdn.net/totogo2010/article/details/8233565
虽然iOS 5.0版本之后加入了ARC机制，由于相互引用关系比较复杂时，内存泄露还是可能存在。所以了解原理很重要。
这里讲述在没有ARC的情况下，如何使用Instruments来查找程序中的内存泄露，以及NSZombieEnabled设置的使用。
本文假设你已经比较熟悉Obj-C的内存管理机制。
实验的开发环境：XCode 4.5.2
1、运行Demo。先下载一个实现准备好的内存泄露的Demo吧：leak app
下载下来，打开运行，程序是一个寿司的列表，列出各种寿司卷。试着选择里面的几行，应该是选第二行的时候就崩溃了。崩溃截图：
在崩溃的地方断住了，知道crash的地方了，但是不知道具体crash的原因。
2、设置NSZombieEnabled这是一个 “EXC_BAD_ACCESS”错误。我们打开XCode的选项：“NSZombieEnabled” 。在crash时可能会给你更多的一些提示信息。
设置步骤：1
2：勾上红色框里的
运行，按刚才的操作选中其中的cell。再次crash，这次在output窗口会看到多了一项错误信息：
2012-11-28 13:22:08.911 PropMemFun[2132:11303] *** -[CFString respondsToSelector:]: message sent to deallocated instance 0x713ebc0
大概意思是：向已释放的内存发送消息。也就是说使用了已释放的内存，在C语言相当于使用了“野指针”
看了下crash的这个语句，sushiString应该是没问题的，它是从stringWithFormat初始化出来的。那就是_lastSushiSelected的问题。
_lastSushiSelected指向了sushiString，sushiString是一个autorelease变量。 在第二次点击时，使用的是sushiString已经被释放，所以crash了。那为_lastSushiSelected保留一下，就可以用了。代码修改如下：
- <span style="font-size:14px;"> _lastSushiSelected = [sushiString retain];
- </span>
运行，这时候不崩溃。
3、分析内存泄露(shift+command+b)app不crash了，那看看有没有内存泄露。用XCode的Analyze就能分析到哪里有内存泄露
分析之后可以看到：
这里提示alertView没被释放，有内存泄露，那我们释放
[alertView release];
再分析，这个问题解决了。
4、使用Instruments的leaks工具
关于：tableView:didSelectRowAtIndexPath ，分析下它的内存过程：
- sushiString变量通过autorelease创建，它的引用计数是1.
- 这行代码使得引用计数增加到2， _lastSushiSelected = [sushiString retain];
- 这个方法结束时，sushiString的autorelease生效了，这个变量的引用计数减少为1
- 当再次执行tableView:didSelectRowAtIndexPath这个方法时，_lastSushiSelected被赋值了新指针，老的_lastSushiSelected的引用计数还是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了，再用工具分析看看，这时候你再点，再拖，再怎么操作，都没有内存泄露了。表明内存泄露被堵住了。
这是本文修复好的app代码：no LeakApp