問題タブ [retaincount]

私が知りたかったのは、オブジェクトが Objective-C の配列または辞書に追加された場合、オブジェクトの保持カウントが増加するかどうかです。特定のオブジェクトを配列またはディクショナリに追加した直後に解放できますか?

私のコードを確認してください：

23行目を見てください。 NSLog(@"%d", (int)[[objA objB] retainCount]);

結果は 3 ではなく 2 になるはずですが、呼び出すたび[objA objB]に保持カウントが 1 ずつ増えるようです。何が起こっているのかわかりません。誰が教えてくれますか？ありがとう！

retainCountまたは、夏休みに使わなかった理由

この投稿は、SO の周りに浮かんでいる関連情報を統合するために、その悪名高いメソッドの理由と理由についての詳細な記事を募集することを目的としていretainCountます。*

1. 基本: を使用しない公式の理由は何retainCountですか? それが役立つかもしれない状況はまったくありますか？代わりに何をすべきですか?**自由に編集してください。

2. 歴史的/説明的:使用を意図していないのに、Apple がNSObjectプロトコルでこのメソッドを提供するのはなぜですか? retainCountApple のコードは何らかの目的で に依存していますか? もしそうなら、なぜどこかに隠されていませんか？

3. 理解を深めるために: オブジェクトの保持カウントがユーザー コードから想定されるものと異なる理由は何ですか? このような違いを引き起こすフレームワーク コードで使用される可能性のある標準的な手順の例を挙げていただけますか? 保持カウントが新しいユーザーが期待するものと常に異なる既知のケースはありますか?

4. 他に言及する価値があると思われるものはありますretainCountか?

_{* Objective-C と Cocoa を初めて使用するコーダーは、参照カウント スキームに取り組むか、少なくとも誤解することがよくあります。チュートリアルの説明では、(これらの説明によると) 、 、 などを呼び出すと 1 ずつ増加し、呼び出すと 1 ずつ減少する保持カウントについて言及しているretain場合allocがcopyありますrelease(将来のある時点で を呼び出すとautorelease)。}

_{新進の Cocoa ハッカーであるクリスは、オブジェクトの保持カウントをチェックすることがメモリの問題を解決するのに役立つという考えを非常に簡単に得ることができましたretainCount。クリスはretainCountいくつかのオブジェクトを呼び出しましたが、これは高すぎて、あれは低すぎて、一体何が起こっているのでしょうか?! それで、Kris は SO に投稿します。そして、<bold>、<large> の文字の群れが降りてきて、「そんなことはやめてください! 結果に頼ることはできません.」と言っています。}

_{これが FAQ に変わることを願っています。それは、新しいココア ヘッズがretainCount.}

_{** 私はこれをあまり広くしたくありませんが、経験からの具体的なヒントや、保持とリリースのペアリングの検証/デバッグに関するドキュメントがここで適切かもしれません.}

_{***ダミーコードで; 明らかに、一般大衆は Apple の実際のコードにアクセスできません。}

次のようなオブジェクトを割り当てました。

その場合、オブジェクトの保持カウントは 1 です。

そしたら、こうなりました……。

その後、保持カウントが 2 に増加しました。なぜですか?

これは私のコードです.オブジェクトobを解放した後でも、メモリリークが発生します.なぜですか？

2 つのオブジェクトが互いに保持されている場合、クロス保持状況をどのように回避しますか?

このクラス構造を考えてみましょう:

Container.h

コンテナ.m

次に、メモリ保持カウントをテストする場合:

したがって、私の理解では、保持カウントは正しいカウントを示しているはずです。しかし、実際にオブジェクトの割り当てを解除するにはどうすればよいでしょうか。このコード ブロックの後、これら 2 つのオブジェクトはメモリ内にとどまるからです。

ビュー/ビューコントローラーの大規模な階層があります。
メインコントローラーには、aViewController が MyClass のメンバーである次のコードがあります。

これを実行すると、解放されないことがわかりますaViewController-保持カウントは最後に1のままです。
ただし、 dealloc に追加[aViewController_.view removeFromSuperview];すると、すべて正常に動作します。

どうしてこれなの？[super dealloc]ビューのリリースを処理する必要はありませんか? ビューがコントローラーの後に解放されていることは重要ですか?

簡単なテストアプリケーションで再現しようとしましたが、うまくいきませんでした。

Zombies インストゥルメントによると、一部のディクショナリ値の過剰リリースが原因で、時折発生するクラッシュに混乱しています。Instruments でこれらのオーバーリリースされたオブジェクトの 1 つのオブジェクト履歴を見ると、その保持カウントが 1 つの段階で +2 から 0 に直接低下していることがわかります。（投稿の最後にあるスクリーンショットを見てください）。これがどのように可能であるかは私には明らかではありません。

このクラッシュは、Instruments でプロファイリングしているときにしか見られないため、Apple のバグであると考えられますが、Instruments が明らかにしているだけのパイロット エラーであると想定する方がおそらく安全です。

とにかく、いくつかの Core Foundation オブジェクト (CFStrings および CFNumbers) を含む CFDictionary を構築しています。次に、これを NSDictionary* にキャストして、Objective-C メソッドに渡します。私のコードの簡略版は以下のとおりです。

と はObjective-C オブジェクトと見なされるため、呼び出しによってブロックがコピーされるとキャプチャされて自動的に保持str1され、そのブロックが解放されると解放されると考えていました。実際、これらの変数はブロックによってキャプチャおよび保持されているようです。しかし、Instruments でオーバーリリースされた CFString のオブジェクト履歴を調べると、ブロックがコピーされると参照カウントが増加していることがわかります。困ったことに、ブロックが解放されると保持カウントが +2 から直接 0 に低下します (記事の最後にあるスクリーンショットを参照)。スタック トレースから、これがどのブロックかを判断する方法がわかりません。ブロック内の辞書で呼び出されるまでにstr2num1-receiveDictionary:dispatch_asyncCFReleasedoStuff()、その値の一部は既に割り当てが解除されており、プログラムがクラッシュします。

では、追加のリリース コールはどこから来たのでしょうか。Instruments が示すように、オブジェクトの保持カウントが +2 から 0 に直接低下するのはなぜでしょうか?

気まぐれで、次のように、2 番目のブロックに辞書全体を強制的に保持させました。

これにより、クラッシュが消えたようです。少なくとも、インストゥルメントはゾンビの報告を停止します。ただし、これが機能する理由は一生わかりません。確かに、ブロックが辞書全体ではなく、関心のある辞書の値を保持していることを確認するだけです。どうしたの？

Instruments は、オブジェクトの保持カウントとともに、ゾンビ CFString の次のオブジェクト履歴を一覧表示します。興味深いイベントのスクリーンショットを含めました。

#0 +1 CFString を作成
#1 +2 CFString をディクショナリに追加
#2 +1 CFString を解放
#3 +2のブロックを-receiveDictionary:コピー
しても CFString を保持 #4 +0なに…？オブジェクトのリテイン カウントが +2 から 0 に急降下しました!
#5 -1 CFDictionary が解放され、クラッシュする

プロパティが (非アトミック、保持) である NSMutableArray があり、何らかの理由で解放されています。これを割り当てるときのコードは次のとおりです (tableData は NSMutableArray です)。

それを割り当てると、保持カウントは 1 になります。tableData に割り当てると、保持カウントは 2 になります。次に、自動解放を使用すると、runloop の最後に 1 になります (これが必要です)。しかし、これは起こりません。後でそれを参照してメソッドを実行すると、ランダムなオブジェクトが取得され (前回は UITabBarSwappableImageView でした)、認識されないセレクターが送信されたと表示されます。どちらが理にかなっていますか...オブジェクトが解放され、他のオブジェクトがその場所を占めています...しかし、なぜ解放されているのでしょうか? ありがとう。

Cocoa / Obj-Cの初心者である私は、AaronHillegassによる「CocoaProgrammingfor Mac OS X」の本を読んでいますが、GCを使用してこのような理由をすべて回避する機会もあるという事実は別として、私はそうではありません。確かに私はそれらの保持のいくつかの理由を理解しています。

特に、例の1つでは、アーロンは優れたプログラミング手法として次のように示しています。

メソッドの最初の行にxインスタンスを保持する理由がわかりません。

このインスタンスのスコープは、setメソッドだけですよね？メソッドスコープを終了するとき、xインスタンスはとにかく割り当てを解除する必要がありますか？さらに、次の方法でxをfooに割り当てる場合：

fooはとにかくx個のメモリセルを指しているので、ポイントされたオブジェクトの保持カウントをインクリメントします。これにより、メモリの割り当てが解除されないようにする必要があります。

それで、ポイントは何ですか？もちろん、何かが足りないと思いますが、正確にはわかりません。

ありがとう、ファブリツィオ