-retainCountこれまでにどのような状況で使用しましたか、そして最終的にそれを使用して発生する可能性のある問題について知りたいのですが。

ありがとう。

を使用-retainCountすることはできません。何も役に立たないからです。FoundationおよびAppKit / UIKitフレームワークの実装は不透明です。何が保持されているのか、なぜ保持されているのか、誰が保持しているのか、いつ保持されているのかなどはわかりません。

例えば：

• あなたはそれが1で[NSNumber numberWithInt:1]あると思うでしょうretainCount。それはありません。2です。
• あなたはそれが1で@"Foo"あると思うでしょうretainCount。それはありません。1152921504606846975です。
• あなたはそれが1で[NSString stringWithString:@"Foo"]あると思うでしょうretainCount。それはありません。ここでも、1152921504606846975です。

基本的に、何でもオブジェクトを保持できる（したがって、オブジェクトを変更できるretainCount）ため、およびアプリケーションを実行するほとんどのコードのソースがないため、オブジェクトのretainCount意味はありません。

オブジェクトが割り当て解除されない理由を追跡する場合は、InstrumentsのLeaksツールを使用します。オブジェクトの割り当て解除が早すぎる理由を追跡する場合は、InstrumentsのZombiesツールを使用します。

ただし、は使用しないでください-retainCount。それは本当に価値のない方法です。

編集する

誰もがhttp://bugreport.apple.comにアクセスして-retainCount、廃止予定をリクエストしてください。それを求める人が多いほど良い。

編集＃2

更新として、9223372036854775807 [NSNumber numberWithInt:1]のretainCountが追加されました。コードが2であると予期していた場合、コードは壊れています。

絶対に！

真剣に。しないでください。

メモリ管理ガイドラインに従って、自分alloc、newまたはcopy（またはretain最初に呼び出したもの）のみをリリースしてください。

@bbumはここSOで、さらに詳しくは彼のブログでそれを最もよく言った。

自動解放されたオブジェクトは、-retainCountのチェックが有益ではなく、誤解を招く可能性がある1つのケースです。保持カウントは、オブジェクトに対して-autoreleaseが呼び出された回数については何も通知しないため、現在の自動解放プールが空になったときにオブジェクトが解放される回数を示します。

私はない「楽器」を使用してチェックするときに非常に便利retainCountsを見つけます。

「割り当て」ツールを使用して、「レコード参照カウント」がオンになっていることを確認します。任意のオブジェクトに移動して、retainCount履歴を確認できます。

allocsとreleasesをペアにすることで、何が起こっているかをよく把握し、リリースされていない困難なケースを解決できることがよくあります。

これは私を失望させることは決してありません-iOSの初期ベータリリースでバグを見つけることを含みます。

NSObjectに関するAppleのドキュメントを見てください。それはあなたの質問をほとんどカバーしています： NSObject maintainCount

要するに、独自の参照カウントシステムを実装していない限り、retainCountはおそらく役に立たないでしょう（私はあなたがそうしないことをほぼ保証できます）。

Apple自身の言葉で言えば、retainCountは「通常、メモリ管理の問題をデバッグすることに意味はありません」。

もちろん、retainCountメソッドをコードで使用しないでください。その値の意味は、オブジェクトに適用されている自動解放の数によって異なり、予測できないためです。ただし、デバッグには非常に役立ちます。特に、メインイベントループの外側でAppkitオブジェクトのメソッドを呼び出すコードでメモリリークを追跡する場合に役立ちます。非推奨にしないでください。

あなたの主張をするあなたの努力において、あなたは価値の不可分の性質を真剣に誇張しました。常に参照カウントであるとは限りません。フラグに使用される特別な値がいくつかあります。たとえば、オブジェクトの割り当てを解除してはならないことを示します。1152921504606846975のような数値は、16進数で書き込んで0xfffffffffffffffを取得するまで、非常に不思議に見えます。また、9223372036854775807は16進数で0x7fffffffffffffffです。そして、retainCountを1秒あたり100,000,000回インクリメントすると仮定すると、retainCountがより大きな数と同じになるまでにほぼ3000年かかることを考えると、誰かがこれらの値をフラグとして使用することを選択することはそれほど驚くべきことではありません。

あなたはそれを使うことからどんな問題を得ることができますか？オブジェクトの保持カウントを返すだけです。私はそれを一度も電話したことがなく、私がそうする理由を考えることができません。シングルトンでオーバーライドして、割り当てが解除されないようにしました。

アプリが稼働して有用な何かを実行するまで、メモリリークを心配する必要はありません。

それが終わったら、Instrumentsを起動してアプリを使用し、メモリリークが本当に発生するかどうかを確認します。ほとんどの場合、自分でオブジェクトを作成し（したがって、それを所有している）、完了後にオブジェクトを解放するのを忘れていました。

コードを書いているときにコードを最適化しようとしないでください。実際にアプリを実際に使用する場合、メモリリークや時間がかかりすぎると思われることがよくあります。

たとえば、allocなどを使用してオブジェクトを作成する場合は、適切なコードをリリースしてください。

コードでは絶対に使用しないでください。ただし、デバッグ時には確実に役立ちます。

コードで-retainCountを使用しないでください。ただし、使用した場合、ゼロが返されることはありません。その理由を考えてください。:-)

Daveの投稿で使用されている例はNSNumberとNSStrings ...なので、UIViewsなどの他のクラスを使用すると、正しい答えが得られると確信しています（保持数は実装によって異なり、予測可能です）。