垃圾收集泄漏？脚本桥泄漏？答案

【问题标题】：Garbage Collection leak? Scripting Bridge leak?垃圾收集泄漏？脚本桥泄漏？
【发布时间】：2011-02-12 05:51:21
【问题描述】：

我对内存泄漏总是很挑剔，我不明白为什么我的垃圾收集应用程序会泄漏。我的代码完全是内存管理的，它在没有垃圾收集的情况下运行良好，没有一次泄漏。但是，一旦我打开垃圾收集，它就会泄漏！

为了证明一点，为什么垃圾收集应用程序会泄漏？（将此虚拟代码放在 applicationDidFinishLaunching 处：）

NSOpenPanel *panel = [NSOpenPanel openPanel];
[panel beginSheetModalForWindow:window completionHandler:^(NSInteger result) {NSBeep();}];

另外，有没有办法防止使用 Scripting Bridge 的应用程序（垃圾收集或其他）泄漏？似乎它们都泄漏了，即使是 xcode 中的示例也是如此。

谢谢大家！

【问题讨论】：

您使用什么来测量泄漏？什么是泄漏？

标签： objective-c cocoa xcode macos memory-leaks

【解决方案1】：

对不起，我忘了提及，我使用 Instruments 中的“Leaks”工具。那里是我看到泄漏的地方。我还没有尝试过“GC Monitor”仪器。泄漏很小，我无法使用扩展细节将它们追溯到我的代码。

我一直以老式的方式进行内存管理，所以本质上我是一个 GC 新手。

所以这与 GC 模式是正常的吗？我应该忽略它吗？

【讨论】：

【解决方案2】：

这是部分答案。

在大多数托管语言中，每个能够保存对另一个对象的引用的结构都嵌入了偏移量可以保存内存地址的信息。例如，在每个堆栈帧中，都有一个地方告诉垃圾收集器去哪里寻找地址。

Objective-C 等基于 C 的语言没有。

为了程序的正确性，对象过多比过早释放对象要好。因此，Objective-C 中的垃圾收集器会寻找看起来像地址的模式，但不能确定它们是否确实是地址。这可能（并且几乎必然）导致引用的误报（并且与您可以与 C 一起使用的某些内存管理技术不兼容）。因此，在某个随机整数不复存在之前，某些对象的寿命可能会超过它们的用处。

另外，你怎么知道什么是泄漏？您只是比较了内存占用，还是通过“泄漏”工具检查了它们？您是否尝试过“GC Monitor”仪器？

【讨论】：