对象'尽管故意过度释放，保留计数永远不会低于 1
我正在检查某些对象的保留计数
NSLog(@"r = %d", [aObject retainCount];
似乎我能得到的最低值是“r = 1”，即使我故意添加额外的“release”调用
[aObject release];
即使我尝试将“r = 1”限制保持不变对象的dealloc方法中的“release”和“NSLog”测试代码。
Cocoa 运行时似乎忽略了我的额外版本，直到“r = 1”，然后在示例程序的最后（没有 GC）因“EXC_BAD_ACCESS”崩溃。
我唯一的解释（猜测）是我们需要 r >= 1 才能访问对象。 Cocoa 运行时只是试图避免让任何对象的保留计数过早变为 0。
如果我错了，有人可以确认或纠正我吗？
I am checking on the retain count of some objects
NSLog(@"r = %d", [aObject retainCount];
It seems that the lowest value I can get is "r = 1", even if I deliberately add extra "release" calls
[aObject release];
The "r = 1" limit holds even if I try to put the "release" and "NSLog" test codes in the object's dealloc method.
The Cocoa run-time just seems to neglect my extra releases up to "r = 1" before crashing with an "EXC_BAD_ACCESS" at the very end of the sample program (without GC).
My only explanation (a guess) is that we need r >= 1 for the object to be accessed. And the Cocoa run-time just tries to refrain from letting any object's retain count from getting to 0 prematurely.
Can somebody confirm or correct me if I am wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
当一个对象的保留计数即将达到0时（即它的保留计数为1，并且再次调用了release），它会被释放，而不是费心做最后的减量。
When the retain count of an object is about to reach 0 (i.e. its retain count is 1, and release has been called again), it's deallocated instead of bothering to do the final decrement.
正如我从 bbum（和其他人）那里学到的，不要使用
retainCount。它并不是为了提供有关对象的保留状态的信息。只需阅读内存管理编程指南并且不要偏离其做法。不要尝试使用retainCount进行内存管理。请参阅我有多少次释放已分配或保留的对象？、
何时使用 -retainCount？
等。
As I've learned from bbum (and others), don't use
retainCount. It isn't intended to be informative as to the retain state of an object. Just read the Memory Management Programming Guide and do not deviate from its practices. Don't try to useretainCountfor your memory management.See How many times do I release an allocated or retained object?,
When to use -retainCount?,
etc.
如果retainCount == 0，则奇点已经实现！
鸡遇上蛋。或者是先有鸡还是先有蛋。
根据定义，释放一个带有单个剩余保留的对象意味着该对象被释放。任何后续方法调用都将导致未定义的行为。
If retainCount ever == 0, the singularity has been achieved!
Chicken meet egg. Or is it egg meet chicken.
By definition, releasing an object with a single remaining retain means the object is deallocated. Any subsequent method calls will result in undefined behavior.
Instruments 工具提供了 Zombie 检测，这比尝试自己调试 Cocoa 的引用计数更有效。使用 Xcode 的 Run >使用性能工具运行>僵尸指挥。它会检测您何时对已释放的对象调用方法，并显示该对象整个生命周期的保留/释放历史记录。自从苹果添加了这个工具后，生活变得好多了。
The Instruments tool provides Zombie detection, which is more effective than trying to debug Cocoa's reference counting yourself. Use Xcode's Run > Run with Performance Tool > Zombies command. It detects when you are calling a method on a released object and shows the retain/release history for the complete lifecycle of the object. Life is much better since Apple added this tool.
基于引用计数的内存管理的理念是，当对象被引用 >=1 次时，它就存在。 retainCount = 0 理论上意味着该对象不再被引用，这就是为什么你无法获取
[aObject keepCount] == 0;因为如果你仍然可以传递消息，对象存在并保持被aObject引用，因此至少有 retainCount = 1。The philosophy of a memory management based on reference counting is that an object exists while it referenced >=1 times. retainCount = 0 theoretically means that the object not referenced anymore, that's why you can't obtain
[aObject retainCount] == 0;because if you still can pass messages, the object exists and remains referenced byaObject, thus has at least retainCount = 1.当一个对象的引用变成 0 时，这个对象就变成了“僵尸对象”，但是你仍然可以向它发送retainCount消息，这是因为Xcode默认没有在内存管理中“启用僵尸对象”，这意味着Xcode没有检查僵尸对象。
如果您让 Xcode 在“编辑方案 -> 运行 -> 诊断 -> 启用僵尸对象”中勾选“启用僵尸对象”来检查僵尸对象，当您在引用对象后继续向对象发送消息时，您将收到错误消息变为 0。
快照：
When an object's reference becomes 0 ,this object becomes "zombie object", but you can still send retainCount message to it that's because Xcode by default didn't "Enable Zombie Objects" in Memory Management, which means Xcode didn't check zombie objects.
If you make Xcode check zombie objects by tick on "Enable Zombie Objects" in "Edit Scheme->Run->Diagnostics->Enable Zombie Objects", you will receive error message when you continue send message to object after it's reference become 0.
The snapshot: