这里的内存泄漏在哪里？答案

【问题标题】：Where's the memory leak here?这里的内存泄漏在哪里？
【发布时间】：2009-07-03 22:23:50
【问题描述】：

Instruments 告诉我这段代码中存在内存泄漏，但我似乎找不到它....有什么帮助吗？对不起或新手问题。

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
    int altoBufferCelda = 26;
    Mensaje *msg = (Mensaje *)[model.mensajes objectAtIndex:indexPath.row];

    CGSize txtSize = [msg.texto sizeWithFont:[UIFont systemFontOfSize:17.0f] constrainedToSize:CGSizeMake(222, 222)  lineBreakMode:UILineBreakModeTailTruncation];

    [alturasDinamicas setObject:[NSNumber numberWithFloat:(txtSize.height + altoBufferCelda)] forKey:[NSNumber numberWithInt:indexPath.row]];

    return txtSize.height + altoBufferCelda;     
}

【问题讨论】：

这是做什么的？发生了什么？什么“仪器”？如果您提供更多信息，它将帮助人们帮助您
marcgg，抱歉信息不足。这是为 iPhone 编写的 Objective-C 代码。该方法是用于控制 iphone 开发人员众所周知的 GUI 控件的委托的一部分。而 Instruments 是一个用于检测内存泄漏和许多其他事情的开发工具
@marcgg 我会说 Cocoa 开发人员都知道“仪器”是包含在开发人员工具中的分析应用程序。至于目的，“heightForRowAtIndexPath:”是不是不够清楚？
@nico：您能否更具体地说明您是如何将泄漏范围缩小到这个特定代码块的？此外，仪器通常指示泄漏对象的类型。这些信息会很有帮助。

标签： objective-c iphone-sdk-3.0 memory-leaks instruments

【解决方案1】：

我会说： [NSNumber numberWithFloat]

它会为你分配一个自动释放的对象。 iPhone 不是垃圾收集，只是参考收集。而且由于您在离开方法之前没有释放分配的内存，因此 Instruments 将其报告为泄漏。

由于这目前已被接受，我会改变我的答案。

仪器不是神圣的法令。这可能是错的。将其用作您应该查看的内容的有力指导，但如果您真的找不到代码有任何错误或漏洞，请继续前进。

【讨论】：

我应该忽略这个泄漏吗？或尝试不同的东西？谢谢！
这不正确。 [NSNumber numberWithFloat:] 返回一个自动释放的对象。没错，iPhone 上没有 GC，但肯定有自动释放池。我在实际代码中没有看到泄漏。可能 UIKit 框架本身存在泄漏。
自动释放池与垃圾收集不同；如果一个自动释放的对象没有被保留，那么它将在当前事件结束时被释放，这在 iPhone 和 OS X 上都是如此。垃圾收集一旦超出范围就会释放对象并且没有其他对象可以可以访问它们（它们无法访问）。 numberWithFloat 将返回一个自动释放的 NSNumber 对象，因此不必释放，因为它没有保留在上面的方法中。
但是自动释放池不是只有在应用退出的时候才会被清空吗？
还不错。我认为它比手动 malloc'ing 和释放内存要好得多。这变得非常复杂。另外，关于自动释放池的另一个注意事项 - 它们和其他任何东西一样都是对象，因此您可以根据需要创建和销毁它们。在处理内存受限的环境（如 iPhone）时，我强烈建议这样做。它们可以显着降低您的整体内存占用。

【解决方案2】：

我在您的代码中看不到任何内存泄漏。正如吐司所指出的，仪器并不总是准确的。这主要是因为即使来自 Apple 框架的代码也包含内存泄漏，仪器也会报告这些泄漏。

如果您使用的是 XCode 3.2，您可以从“构建”菜单中选择“构建和分析”，它会扫描代码以查找编译器通常无法检测到的错误。这将向您展示由于忘记释放对象而导致的许多可能的内存泄漏。

【讨论】：