-retainCount 到底有多不可靠？ [关闭]

Posted 2023-03-05

【中文标题】-retainCount 到底有多不可靠？ [关闭]

【英文标题】：Just how unreliable is -retainCount, exactly? [closed]

【发布时间】：2017-03-02 05:40:20

【问题描述】：

我希望创建一个不需要消费者手动释放对象的对象池。相反，每次请求一个新对象时，它都会检查池中的所有对象以查看它们的保留计数是否为 1（仅由池拥有）。如果是，则返回它。

需要多少技巧才能使这个总体计划生效？

示例： 我知道一些无法释放的 NSString 的保留计数始终为 -1，并且标记的指针无法被释放（我也不希望它们在对象中水池）。不属于基本集合（NSString、NSArray、NSDate 和其他一些）的类，例如UIView，对保留的优化较少，因此保留计数更可靠？

【参考方案1】：

retainCount 对于它提供的信息是可靠的，但对于您描述的用途来说也可能无用。

retainCount 告诉您一个对象存在多少个保留（大多数情况下，正如您所指出的，有几个无法释放的对象例外）。然而，它并没有告诉你这些保留物的所有者是谁。特别是，您不能使用它来确定这些现有保留中的任何一个是否属于自动释放池。

一个对象可能会报告retainCount 或1，但唯一保留分配它的保留可能是自动释放池的一部分，该池将在当前运行循环结束时释放并因此释放它。 一个对象可能会报告 retainCount 或 10，但您建议的对象池可能只有在自动释放池之外保留​​，因此在当前运行循环结束时它将返回到 1。 对象可能会报告 retainCount 或 10，但它们都可以从自动释放池中保留，并且在池耗尽时仍会被释放。

此外，从您的问题来看，您还不清楚为什么您认为需要这种行为。您通常可以将自动释放的对象返回给您的使用者。如果消费者打算重用它，则应保留该对象，但无论他们是否这样做，您的池都可以选择保留和重用该对象（或不）。

【讨论】：

性能增益将避免 UIView 的 init 方法的开销，因为不必不断地销毁和重新创建视图。对于你提到的问题，我认为没关系，因为这只是意味着我们会认为它在运行循环的其余部分被保留，但是对于那个视图来说事情会是正确的吗？

retainCount 听起来像是您尝试提供的行为的错误工具。听起来您想创建一个对象池并允许在池中没有使用者已经在使用该特定对象的情况下重用而不重新分配池中的对象？如果是这种情况，我将让池返回代理或包装对象，池对其保持归零弱引用。然后，您的消费者将是唯一保留这些代理的对象，因此您将能够检查代理是否为 nil 以确定它所包装的对象是否未使用。

这是一个很酷的想法，但它仍然需要在每次使用时打开包装

这在一定程度上取决于您的游泳池需要多么通用，您没有提供太多细节。非通用解决方案的消费者应该只能与包装器类型进行交互，并且永远不需要了解池内部更长寿命的版本。 developer.apple.com/reference/foundation/nsproxy 可能允许您构建更通用的解决方案。

好电话！我可能会这样做，只要它的转发性能很好