I used to verify that some of my variables had the expected retain count using [myVar retainCount] under the debugger, especially for var that did not have a custom dealloc.
How do you do this in ARC mode? How do you ensure that there are no memory leaks?
Note: I understand that ARC should handle this for me, but life is far from being perfect, and in real life you have objects that are sometimes allocated by third party libraries (using retain?) and never deallocated.
Image that I do this:
MyObj *myObj=[[MyObj alloc] init];
then I call
[somethingElse doSomethingWithMyObj:myObj];
and later, I do
myObj=NULL;
If my program is working fine, my expectation is that myObj is being destroyed, but it appears not to be the case...
So how can I track this, especially if somethingElse is not managed by me?
Now, about the tools: it seems extremely hard to run memory tools on my mac (with 5 Meg) without rebooting the mac and starting from scratch. This is really annoying! Instruments keep crashing even before the program has started, so is there an alterante solution?
You can use CFGetRetainCount with Objective-C objects, even under ARC:
NSLog(@"Retain count is %ld", CFGetRetainCount((__bridge CFTypeRef)myObject));
This is not particularly useful for debugging, though, for reasons amply described elsewhere. If you need to understand where an object is being retained and released, check out this answer for help using the Allocations instrument.
The only case I've found where examining the retain count is actually useful is in a dealloc method, when something retains and autoreleases the object being deallocated. This will cause a crash later when the autorelease pool is drained. You can pinpoint the cause of this by checking the retain count before and after each message. In this way I discovered that the observationInfo method (which is itself usually only useful for debugging) retains and autoreleases self. However, even this sort of problem can usually be solved without examining the retain count, simply by wrapping the entire body of dealloc in an @autoreleasepool block.
However, the retain count can be used to learn about the implementation of some classes. (Only do this for entertainment or curiosity! Never rely on undocumented implementation details in production code!)
For example, try this immediately inside the @autoreleasepool in main:
NSNumber *n0 = [[NSNumber alloc] initWithInt:0];
NSLog(@"0 reference count = %ld", CFGetRetainCount((__bridge CFTypeRef)n0));
// Prints 2 in my test
So NSNumber likely caches (or at least reuses) some instances. But not others:
n0 = [[NSNumber alloc] initWithInt:200];
NSLog(@"n0 reference count = %ld", CFGetRetainCount((__bridge CFTypeRef) n0));
// Prints 1 - I am the sole owner of this instance. There could be weak
// or unretained references to it, but no other strong references.
NSNumber *n1 = [[NSNumber alloc] initWithInt:200];
NSLog(@"n1 reference count = %ld", CFGetRetainCount((__bridge CFTypeRef) n1));
// Prints 1 again. New instance with same value as prior instance.
// You could of course compare pointers to see that they are separate
// instances.
You can even discover that NSNumber returns a singleton if you alloc but don't initialize:
n1 = [NSNumber alloc];
NSLog(@"n1 reference count = %ld", CFGetRetainCount((__bridge CFTypeRef) n1));
// Prints -1.
(Note that you can also learn many details about NSNumber by looking at the Core Foundation source code, which is available at http://opensource.apple.com. But who knows what you might find if you look at the retain count of objects that aren't toll-free-bridged with objects in Core Foundation?)
You don't. ARC handles the memory management for you and does not allow you to call retainCount and even if you could see it, the number it returns is meaningless for you. If you want to you should be doing memory profiling in Instruments with the Leaks and Allocations instruments. That is the best way to look and see how your application is allocating memory and catch any improper use of memory there.
You should never use retainCount for anything, with or without ARC.
Use Instruments and locate the object you want to track by searching for the class name or pointer address if you have it while in in "Objects List".
When you have located it, hit the disclosure arrow on the instance. This brings you to a history view for retains and relases.
If you expand the right side detail view you will also see the callstack for each retain/release.
I believe the only way is to profile your application using the Allocations instrument. You will need to click on the info descriptor (the 'i' next to Allocation in the left pane) and click on "Record Reference Counts". You can then profile your app and do a search for the specific class you're looking to inspect. From there you can find the retain count in the Extended Detail pane for each instance of the class.
You can also do this using Leaks as well (since I believe it's a variation of the Allocations instrument).
Get the object's retainCount?
You can just make a breakpoint and input the command below to get the object's retainCount
po object.retainCount
You don't. Apple say you don't need to as ARC will handle it for you.
来源：https://stackoverflow.com/questions/8863269/how-do-i-verify-reference-count-in-arc-mode