5.内存管理

第29条 理解引用计数

引用计数每次alloc、init之后，引用计数至少增加1，因为init里可能有别的对象也引用了该对象，所以说只能说至少增加1。

setter方法：

- (void)setName:(NSString *)name
{
    [name retain];
    [_name release];
    _name = name;
}

不能先写[_name release];，一定要先retain，因为如果name和_name指向同一块内存，那相当于把name释放掉了，后面retain已经没效果了。

第30条 以ARC简化引用计数

CoreFoundation对象不归ARC管理，开发者需要手动调用CFRetain和CFRelease。

第31条 在dealloc方法里只释放引用并解除监听

不要在dealloc方法里调用一些比较耗时（如异步）的方法，因为对象可能会在方法完成前已经释放了。另外dealloc里的线程可能不是主线程，因为此时对象已经处在回收的状态了。

第32条 编写“异常安全代码”时留意内存管理问题

在try块中，如果一个对象被强引用了，在释放该对象前抛出异常，那么除非catch块能处理此问题，否则对象所占的内存就泄露了。

ARC下问题可能会更严重：

在开启ARC之后正常情况下一切和内存有关的申请和释放操作皆不用你关心了，ARC全全帮你包办了。但是还有极少数的情况下，编译器无法为你生成合适的ARC额外代码，比如obj-c异常就是这么一个例子。

话句话说在ARC中异常可能会导致对象的内存泄露。因为ARC是颗粒化对象为一个文件：即可以在obj-c文件上启用ARC.所以我们可以选择性的在编译某个文件上加上-fobjc-arc-exceptions选项，如果开启了该选项，则ARC会额外为异常中的对象申请和释放操作添加代码，保证异常中ARC管理的对象也不会造成内存泄露。当然这样一来缺点就是可能会生成大量平常可能根本用不到的代码。(只有发生异常才会执行)

所以我们可以只在必要的obj-c文件上启用-fobjc-arc-exceptions标志，而其他文件禁用该标志，这样才可以做到万无一失。

第33条 以弱引用避免保留环

weak和assign的区别

weak和assign的区别

第34条 以自动释放池降低内存峰值

主线程或GCD的线程中，都存在自动释放池，每次执行Event Loop时，就会将其清空。

第35条 用僵尸对象调试内存管理问题

• 向已经被释放的对象发送消息是不安全的，有时会崩溃，有时不会，取决于该对象的内存是否已经被其他内容所覆写。
• 启用了僵尸对象（Zombie object）后，运行期系统会把所有已经被回收的对象转为僵尸对象，而不会真正的回收它们。这种对象所在的核心内存无法重用，因此就无法被遭到覆写。僵尸对象收到消息后，会抛出异常，准确说明了发来的消息，并描述了回收之前的那个对象。
• 具体过程，就是如果检测到僵尸对象已经打开，就通过swizzle方法将dealloc交换，然后在里面copy一份原来的对象，然后改类名为 NSZOmbie_MyClass。
• 系统会修改对象的isa指针，使其指向特殊的僵尸对象，从而使对象变成僵尸对象。僵尸对象能够响应所有的选择子，响应方式为：打印一条包含消息内容及接收者的消息，然后终止程序。

第36条 不要使用 retainCount

此方法即便在调试的时候也没用，原因是：它返回的保留计数只是某个时间点上的值，并未考虑到系统可能稍后就会把自动释放池清空的情况。
如，错误代码：

//问题1：若object已经在自动释放池里了，稍后系统还会清空一次，会造成程序崩溃
//问题2：有时候系统会优化，retainCount为1的时候就把对象释放了，所有可能retainCount永远都不会为0
while ([object retainCount])
{
      [object release];
}