如何修复_NSCFNumber导致的iOS内存泄漏？

Question

这是我的代码，在其中重新加载_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）。 此代码也在主线程上运行。

预先感谢您的答复:)

Answer 1

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

当您将对象（例如NSNumber ）添加到集合（即NSArray ， NSSet等）时，该集合将创建对该对象的STRONG引用。 这意味着当NSNumber超出ARC范围时，垃圾收集器将不会出现并释放它。 但是，这可能会导致一些问题，其中一个是保留周期 。

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

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