调试内存管理问题很令人头疼。大家都知道，向业已回收的对象发送消息是不安全的。这么做有时可以，有时不行。具体可行与否，完全取决于对象所占内存有没有为其他内容所复写。而这块内存有没有移作他用，又无法确定，因此，应用程序只是偶尔崩溃。在没有崩溃的情况下，那块内存可能只复用了其中一部分，所以部分对象中的某些二进制数据依然有效。还有一种可能，就是那块内存恰好为另外一个有效且存货的对象所占据。在这种情况下，运行期系统会把消息转发到新对象那里，而此对象也许能应答，也许不能。如果能，那程序就不崩溃，可你会觉得奇怪：为什么收到消息的对象不是预想的那个呢？若新对象无法响应选择子，则程序依然会崩溃。
所幸Cocoa提供了“僵尸对象“（Zombie Object）这个非常方便的功能。启用这项调试功能之后，运行期系统会把所有已经回收的实例转化为特殊的”僵尸对象“，而不是真正回收他们。这种对象所在的核心内存无法重用，因此不可能遭到复写。僵尸对象收到消息之后，会抛出异常，其中准确说明了发送过来的消息，并描述了回收之前的那个对象。僵尸对象是调试内存管理问题的最佳方式。
将NSZombieEnabled环境变量设为YES，即可开启此功能。给僵尸对象发消息后，控制台会打印消息，而应用程序会终止。打印出来的消息就像这样：
*** -[CFString respondsToSelector:] message sent to deallocated instance 0x7ff9e9c080e0
在xcode 中开启僵尸对象调试如下图所示：
so，关于僵尸对象的工作原理是什么呢？它的实现代码深植于Objective -C的运行期程序库、Foundation框架以及CoreFoundation框架中。系统在即将回收对象时，如果发现通过环境变量启用了僵尸对象功能，那么还将执行一个附加步骤。这一步就是把对象转化为僵尸对象，而不彻底回收。
下列代码有助于理解这一步所执行的操作：
为了便于演示普通对象转化为僵尸对象的过程，这段代码采用了手动引用计数。因为假如使用ARC的话，str对象就会根据代码需要，尽可能多存活一段时间，于是在这个简单的例子中，就不可能变成僵尸对象了。这并不是说对象在ARC下绝不可能转化为僵尸对象。即便用了ARC，也依然会出现这种内存bug，只不过一般要通过稍微复杂些的代码才能表现出来。
范例代码中有个函数，可以根据给定的对象打印出所属的类及其超类名称。此函数没有直接给对象发送Objective-C的class消息，而是调用了运行期库里的object_getClass()函数。因为如果参数已经是僵尸对象了，那么给其发送Objective-C消息后，控制台会打印错误消息，而且应用程序会崩溃。范例代码将输出下面这种消息：
Before release：
=== Zombie ：NSObject ===
After release：
=== _NSZombie_Zombie ：nil ===
对象所属的类已由Zombie变为_NSZombie_Zombie。但是，这个新类是从哪里来的呢？代码中没有定义过这样一个类。而且，在启用僵尸对象后，如果编译器每看到一种可能变成僵尸的对象，就创建一个与之对应的类，那也低效了。_NSZombie_Zombie实际上市在运行期生成的，当首次碰到Zombie类的对象要变成僵尸对象时，就会创建那么一个类。在创建的过程中用到了运行期程序库离得函数，它们的功能很强大，可以操作类列表（class list）。
僵尸类（zombie class）是从名为_NSZombie_的模板类里复制出来的。这些僵尸类没有多少事情可做，只是充当一个标记。接下来介绍它们是怎么充当标记的。首先来看下面这段伪代码，其中演示了系统如何根据需要创建出僵尸类，而僵尸类有如何把待回收的对象转化为僵尸对象。
这个过程其实就是NSObject的dealloc方法所做的事。运行期系统如果发现NSZombieEnabled环境变量已设置，那么就把”dealloc“方法的”调配“（swizzle）成一个会执行上述代码的版本。执行到程序末尾时，对象所属的类已经变为_NSZombie_OriginalClass了，其中OriginalClass指的是原类名。
代码中的关键之处在于：对象所占内存没有（通过调用free()方法）释放，因此，这块内存不可复用。虽说内存泄漏了，但这只是个调试手段，发布正式应用程序时不会把这项功能打开，所以这种泄漏问题无关紧要。
但是，系统为何要给每个变为僵尸的类都创建一个对应的模型呢？这是因为，给僵尸对象发消息之后，系统可由此知道该对象原来所属的类。假如把所有僵尸对象都归到_NSZombie_类里，那原来的类名就丢了。创建新类的工作由运行期函数objc_duplicateClass()来完成，它会把整个_NSZombie_类结构拷贝一份，并赋予其新的名字。副本类的超类、实例变量及方法都和复制前相同。还有种做法也能保留旧类名，那就是不拷贝_NSZombie_，而是创建继承自_NSZombie_的新类，但是用响应的函数完成此功能，其效率不如直接拷贝高。
僵尸类的作用会在消息转发过程中体现出来。_NSZombie_类（以及所有从该类拷贝出来的类）并未实现任何方法。此类没有超类，因此和NSObject一样，也是个”根类“，该类只有一个实例变量，叫做isa，所有Objective-C的根类都必须有此变量。由于这个轻量级的类没有实现任何方法，所以发给它的全部消息都要经过”完整的消息转发机制“。
在完整的消息转发机制中,_ _ _forwarding_ _ _是核心，调试程序时，大家可能在栈回溯消息里看见过这个函数。它首先要做的事情就包括检查接收消息的对象所属的类名。若名称前缀为_NSZombie_，则表明消息接收者是僵尸对象，需要特殊处理。此时会打印一条消息，其中指明了僵尸对象所收到的消息及原来所属的类，然后应用程序就终止了。在僵尸类名中嵌入原始类名的好处，这是就可以看出来了。只要把_NSZombie_从僵尸类中的开头拿掉，剩下的就是原始类名。下列代码演示了这一过程：
把开头那个范例扩充一下，试着给变成僵尸对象的Zombie对象发送description消息：
若是开启了僵尸对象功能，那么控制台会输出如下消息：
Before release：
=== Zombie ：NSObject ===
After release：
===_NSZombie_Zombie ：nil ===
*** - [Zombie description]：message sent to deallocted instance 0x7fc821c02a00
大家可以看到，这段消息明确指出了僵尸对象所收到的选择子及其原来所属的类，其中还包含接收消息的僵尸对象所对应的”指针值“。在调试器中深入分析程序时，也许会用到此消息，而且若能与适当的工具（比如Xcode自带的Instruments）相搭配，则效果更佳。
Above all：
~ 系统在回收对象时，可以不将其真的回收，而是把它转化为僵尸对象。通过环境变量NSZombieEnabled 可开启此功能
~ 系统会修改对象的isa指针，令其指向特殊的僵尸类，从而使改对象变为僵尸对象。僵尸类能够响应所有的选择子，响应方式为：打印一条包含消息内容及其接收者的消息，然后终止应用程序。
