ios - 使用 block 、集合和 ARC 时发生泄漏

Question

我试图理解为什么这段代码会泄漏，使用 ARC:

- (IBAction)block2:(id)sender {
    NSMutableString *aString = [[NSMutableString alloc] init];

    void (^aBlock)() = ^{
        NSMutableString __unused *anotherString = aString;
    };

    NSMutableDictionary *dict = [NSMutableDictionary dictionaryWithObject:aBlock forKey:@"Key"];

}

如您所见，我将一个 block 放在一个集合中(NSMutableDictionary，但如果我使用 NSDictionary、NSArray ecc... 也是一样的)，然后该方法返回并释放字典。然后应该释放该 block 。但是，使用仪器，我看到了泄漏

“只是为了确定”该 block 没有其他引用，我在方法末尾添加了这一行:

[dict setObject:[NSNull null] forKey:@"Key"];

相同的结果。

我找到了这篇文章，但答案指向另一个问题: Blocks inside NSMutableArray leaking (ARC)

然后，这就是魔法:如果我改变这一行:

NSMutableDictionary *dict = [NSMutableDictionary dictionaryWithObject:aBlock forKey:@"Key"];

到:

NSMutableDictionary *dict = [NSMutableDictionary dictionaryWithObject:[aBlock copy] forKey:@"Key"];

泄漏消失了。

我知道，在非ARC下，在传递 block 字面量的引用之前，我必须复制它(当声明字面量时，它在堆栈上，所以我需要在传递到范围之外之前将它复制到堆中声明的函数)...但是使用 ARC 我不应该关心它。有什么迹象吗？从 5.0 到 6.1 的所有版本都会发生这种情况。

编辑:我做了一些测试，试图了解我是否做错了什么或者是否存在错误...

首先:我读错了仪器信息吗？我不认为，泄漏是真实的，而不是我的错误。看这张图片...执行该方法 20 次后:

第二:如果我尝试在非 arc 环境中做同样的事情会发生什么？这增加了一些奇怪的行为:

NON-ARC 环境下的相同功能:

- (IBAction)block2:(id)sender {
    NSMutableString *aString = [[NSMutableString alloc] init];

    void (^aBlock)() = ^{
        NSMutableString __unused *anotherString = aString;
    };

    [aString release];

    NSMutableDictionary *dict = [NSMutableDictionary dictionaryWithObject:[[aBlock copy] autorelease] forKey:@"Key"];
}

对于之前的非弧形实现，我只对 block 有泄漏(不是对字符串)更改实现以在声明的可变字符串上使用自动释放解决了泄漏!!!我不明白为什么，我不确定它是否与主要帖子问题有关

// version without leak
- (IBAction)block2:(id)sender {
    NSMutableString *aString = [[[NSMutableString alloc] init] autorelease];

    void (^aBlock)() = ^{
        NSMutableString __unused *anotherString = aString;
    };

    NSMutableDictionary *dict = [NSMutableDictionary dictionaryWithObject:[[aBlock copy] autorelease] forKey:@"Key"];
}

结论:

经过各种回答和进一步调查，我明白了一些事情:

1- Apple 文档说当您将 block 传递给集合时，您必须使用 [^{} copy]。这是因为 ARC 本身不添加副本。如果你不这样做，集合(数组、字典..)会在堆栈分配的对象上发送一个保留——什么都不做。当方法结束时， block 超出范围并变得无效。使用它时，您可能会收到错误的访问权限。但请注意:这不是我的情况，我遇到了不同的问题

2- 我遇到的问题是不同的:该 block 被过度保留(相反的问题 --> 该 block 仍然存在，即使它不应该存在)。为什么？我发现了这一点:在我的示例中，我使用的是这段代码

void (^aBlock)() = ^{
    NSMutableString __unused *anotherString = aString;
};

此代码在 NON-ARC 下存储对文字 block 的引用 (aBlock)。该 block 是在堆栈上分配的，因此如果您使用 NSLog(@"%p", aBlock) -> 您将看到一个堆栈内存地址

但是，这是“奇怪的”(我没有在 Apple 文档中找到任何指示)，如果您在 ARC 和 NSLog aBlock 地址下使用相同的代码，您会看到它现在在 HEAP 上!由于这个原因，行为是不同的(没有错误的访问)

因此，两者都是不正确但不同的行为:

// this causes a leak
- (IBAction)block2:(id)sender {
    NSMutableString *aString = [[NSMutableString alloc] init];

    void (^aBlock)() = ^{
        NSMutableString __unused *anotherString = aString;
    };

    NSMutableDictionary *dict = [NSMutableDictionary dictionaryWithObject:aBlock forKey:@"Key"];

}

// this would cause a bad access trying to retrieve the block from the returned dictionary
- (NSMutableDictionary *)block2:(id)sender {
    NSMutableString *aString = [[NSMutableString alloc] init];

    return [NSMutableDictionary dictionaryWithObject:^{
        NSMutableString __unused *anotherString = aString;
    } forKey:@"Key"];

}

3 - 关于我上次在 NON-ARC 下的测试，我认为发布的地方不对。我在使用 copy-autorelease 将 block 添加到字典之前释放了字符串。该 block 自动保留 block 内引用的变量，但保留消息是在复制时发送的，而不是在声明时发送的。所以，如果我在 复制 block 之前释放 aString，它的保留计数变为 0，然后 block 将保留消息发送到“僵尸”对象(具有意外行为，它可能会泄漏 block ，崩溃, ecc ecc)

Answer 1

引用这个问题iOS 5 Blocks ARC bridged cast ;它展示了 Blocks 和 ARC 的噩梦。

通常，如果您将 block 分配给超出当前范围的变量，编译器将自动能够将该 block 复制到堆中。这意味着当你超出范围时，你仍然有 block 悬空。同样， block 参数也是如此。编译器知道它需要制作这些参数的副本，因此这样做了。

NSArray 类的问题在于它们通常不需要复制对象来正确保存它；通常他们只保留对象。超出范围的对象是语言的一部分(因此它会复制)，而将其保留在像 NSArray 这样的对象中是应用程序级别的操作。因此，编译器还不够聪明，无法确定该 block 是否需要复制(毕竟 block 是标准的 Obj-C 对象，它认为它需要做的就是保留它)。类似地，这就是为什么任何包含 block 的属性都需要指定 copy 关键字的原因。属性方法的自动合成并不知道正在存储一个 block ，并且需要在设置时进行微调以复制它们。

这说明了为什么当你在你的代码块上使用 - copy 时整个事情都有效，你正在做编译器应该做的事情，但还不够聪明，不能这样做......苹果甚至在其 Transitioning to ARC 中推荐该技术文档，请参阅常见问题解答。

引导说明:如果您想知道为什么我要保留，即使您使用的是 ARC，这是因为这就是 ARC 在幕后所做的事情。内存管理模型仍然和以前一样，但是现在系统有责任根据命名和约定为我们管理它，而以前有责任正确管理他们的内存的开发人员。只是对于 block ，系统无法对其进行充分管理，因此开发人员需要不时介入。