如果您使用的是Leopard (Mac OS X 10.5)或更高版本，则可以使用Instruments应用程序来查找和跟踪内存泄漏。在Xcode中构建程序后，选择使用性能工具> Leaks运行>。

即使你的应用程序没有显示任何泄漏，你可能把对象保存得太久了。在Instruments中，您可以为此使用ObjectAlloc工具。在Instruments文档中选择ObjectAlloc乐器，并通过选择View > detail(它旁边应该有一个复选标记)来显示乐器的详细信息(如果还没有显示的话)。在ObjectAlloc详细信息中的“分配生命周期”下，确保选择“已创建和仍然存在”旁边的单选按钮。

现在，每当您停止记录应用程序时，选择ObjectAlloc工具将在“# Net”列中显示对应用程序中每个仍然活动的对象的引用数。确保不仅要查看自己的类，还要查看NIB文件的顶级对象的类。例如，如果你在屏幕上没有窗口，而你看到一个仍然存在的NSWindow的引用，你可能没有在你的代码中释放它。

黄金法则:如果你分配了，那么你就释放了!

更新:除非你正在使用ARC

使用LLVM/Clang静态分析仪

注意:在Xcode 4中，这是内置在IDE中。

你可以使用Clang Static Analyzer在Mac OS X 10.5上分析你的C和Objective-C代码(还没有c++)。安装和使用起来很简单:

从本页下载最新版本。 从命令行，cd到您的项目目录。 执行scan-build -k -V xcodebuild。

(还有一些额外的限制等等，特别是你应该在“调试”配置中分析一个项目——详情请参阅http://clang.llvm.org/StaticAnalysisUsage.html——但这或多或少就是它的总结。)

分析器然后为您生成一组网页，显示可能的内存管理和编译器无法检测的其他基本问题。

在dealloc中清理。

这是最容易忘记的事情之一——尤其是在以150英里/小时的速度编码时。总是，总是，总是清理dealloc中的属性/成员变量。

我喜欢使用Objc 2属性-新的点表示法-所以这使得清理变得无痛。通常很简单:

- (void)dealloc
{
    self.someAttribute = NULL;
    [super dealloc];
}

这将为您处理发布，并将属性设置为NULL(我认为这是防御性编程——以防dealloc中的另一个方法再次访问成员变量——很少，但也可能发生)。

在10.5中打开GC后，就不再需要这么多了——但是你可能仍然需要清理你创建的其他资源，你可以在finalize方法中做这件事。

这是一个微妙但很方便的方法。如果你将自己作为委托传递给另一个对象，在dealloc之前重置该对象的委托。

- (void)dealloc
{
self.someObject.delegate = NULL;
self.someObject = NULL;
//
[super dealloc];
}

这样做可以确保不再发送更多的委托方法。当您即将dealloc并消失在以太中时，您希望确保没有任何东西可以意外地向您发送更多消息。还记得自己。someObject可以被另一个对象保留(它可以是一个单例对象或在自动释放池中或其他任何对象)，直到您告诉它“停止向我发送消息!”，它才会认为您即将被释放的对象是公平的游戏。

养成这种习惯将使您避免大量令人痛苦的调试的奇怪崩溃。

同样的原理也适用于键值观察和NSNotifications。

编辑:

更有防御性的改变:

self.someObject.delegate = NULL;

成:

if (self.someObject.delegate == self)
    self.someObject.delegate = NULL;

使用NSAssert和朋友。 我一直使用nil作为有效对象…特别是发送消息给nil在Obj-C中是完全有效的。 然而，如果我真的想确定一个变量的状态，我使用NSAssert和NSParameterAssert，这有助于轻松跟踪问题。