如何修复 _NSCFNumber 的 iOS 内存泄漏？答案

【问题标题】：How to fix iOS memory leak from _NSCFNumber?如何修复 _NSCFNumber 的 iOS 内存泄漏？
【发布时间】：2015-07-09 14:30:48
【问题描述】：

这是我重新加载 _collectionView 特定部分的代码。当我在 Xcode 6.3 Instruments 中使用 Leaks 模板检查内存泄漏时，它显示在线泄漏

[_collectionView reloadSections:indexToLoad];

和 _NSCFNumber 作为泄漏对象。这是我的代码：

NSMutableIndexSet* indexToLoad = [NSMutableIndexSet new];
for (NSInteger index in array) {
    if (index != NSNotFound) {
        [indexToLoad addIndex:index];
    }
}
if (indexToLoad.count > 0) {
    [_collectionView reloadSections:indexToLoad];
}

当我在某处读到时，“泄漏工具会向您显示分配泄漏的位置，但不会显示导致泄漏的代码行”，我怎样才能找到泄漏的原因?还有如何解决这个泄漏？

注意：运行此代码的类启用了 ARC（整个项目都启用了 ARC）。此代码也在主线程上运行。

提前感谢您的回答:)

【问题讨论】：

没有发生泄漏的行。当对该对象的所有引用都超出范围但没有人费心收集该对象时，就会发生泄漏。在你的情况下，你的代码甚至没有编译开始，所以你能告诉我们你遇到问题的实际代码吗？
真的，向我们展示实际运行的代码。如果该代码编译，那么你真的需要打开一些编译器警告。

标签： ios objective-c memory-leaks xcode6 xcode-instruments

【解决方案1】：

我注意到您正在迭代一个数组并将其内容封装为NSInteger。由于您不能将 NSInteger 添加到 Objective-C 数组中，我将假设这是一个 NSNumber 的数组，恰好是正在泄漏的类。

当您将对象（例如 NSNumber）添加到集合（例如 NSArray、NSSet 等）时，集合会创建对该对象的 STRONG 引用。这意味着当NSNumber 超出ARC 范围或垃圾收集器不会出现并释放它时。然而，这可能会导致一些问题，例如retain cycles。

我怀疑正在发生的事情（如果没有实际测试您的完整代码，我无法确定）是当 NSMutableIndexSet 超出范围时，ARC 会出现并尝试释放所有 @ 987654330@ 它包含但发现它不能的对象，因为它们仍然由数组保留。如果不是，那么在代码中的某个地方，您将挂在一个或多个 NSNumber 实例上，而 ARC 不喜欢它。

解决方案：在内存管理方面，ARC 并不是灵丹妙药。它使内存管理更加友好，因此人们倾向于假设他们可以编写他们喜欢的任何代码，而 ARC 将负责其余的工作。您仍然需要了解您的参考资料（strong 与 weak）以及何时使用每个参考资料。还要确保你知道默认状态是什么；例如@property NSNumber *num; 相当于@property (nonatomic, strong) NSNumber *num;

【讨论】：