多くのメッセージを nil に送信しているため、保持カウントが 0 になっています。
ここで、変数が変更されたときに変数の新しい値を使用して、コードを再度書き留めました。
str1 と str2 は nil です
self.str1=[[NSString alloc]init];
str1 は空の文字列です
self.str1=self.str2;
str1 はゼロです
self.str2=[self.str1 retain];
self.str2=[[NSString alloc]init];
str2 は空の文字列です
self.str2=self.str1;
str2 はゼロです
self.str1=[self.str2 retain];
self.str2=[self.str1 retain];
最後に、str1 と str2 の両方が nil であり、保持カウントがゼロになります。
しかし、毎回新しい文字列を nil で上書きしなくても、期待どおりの結果が得られません。これを考えてみましょう:
self.str1 = [[NSString alloc] init]
self.str2 = [[NSString alloc] init]
それらの保持カウントを見ると、それぞれに対して 18446744073709551615 (Mac OS X、64 ビットの場合) が得られます。次に、ポインターの値を見ると、両方が等しいことがわかります。したがって、両方の呼び出しで同じ空の NSString オブジェクトが得られます[[NSString alloc] init]
。
それは実際に理にかなっています。NSString オブジェクトはimmutableです。つまり、いったん作成されると変更できません。したがって、空の文字列の複数の同一のコピーでメモリを浪費しても意味がありません。
これらの共有インスタンスの一部は、retainCount メソッドから可能な最大値を返し、それらがシングルトンであることを示しています。しかし、それらすべてではありません。
したがって、オブジェクトの保持カウントはあまり役に立ちません。いくつかのオブジェクトはそれについて嘘をついています。そして、実際のアプリでは、期待したものではないことがよくあります。自分でオブジェクトを保持していなくても、システムがしばらくオブジェクトを保持することがあります。
しかし、保持/解放メモリ モデルがどのように機能するかを学習しようとしていると思います (これは、ARC を使用している場合でも必要です)。このために、保持カウントを照会することで回避できます。NSObject
ただし、保持カウンターで特別なトリックを実行しないため、基本クラスを直接使用する必要があります。また、テスト オブジェクトをいくつかのシステム メソッドに渡すとすぐに、保持カウントが後で予期しないものになる可能性があることに注意する必要があります。実際のアプリで保持カウントをクエリしないように常に注意してください。これは役に立ちません。