スキップしてメイン コンテンツに移動

Objective-Cのメモリー管理

最近はJavaをまずプログラム言語として始める人が多いだろうから、Objective-Cを使いだした際メモリー管理でつまずくことが多いだろう。わたし自身もすっかりJavaな人になっていたので同様に最初のころハマった。一応メモリー管理についてまとめておこう。

Objective-Cでは10.5からは今時の言語っぽくGabage Collectionが導入されので、Java同様あまりメモリー管理を気にする必要はなくなった。だが、パフォーマンスの問題からなのかXCodeのデフォルトの設定ではオフになっていたりするので、一応レガシィなメモリー管理のお手前も知っておこう。

リファレンスカウンタ、retain/release

さすがに大昔のC++のようにnew/deleteで自身で管理ということはなくて、リファレンスカウンタという割と一般的な手法でメモリー管理はなされている。これはある変数について参照が増えるたびにカウントアップ、参照がなくなるごとにカウントダウンしていき、参照カウンタがゼロになった時点でオブジェクトが削除されるという管理方法。Objective-Cの場合、この仕組みが言語でなくCocoaのライブラリレベルで実現されている。

リファレンスカウンタは生成時点で1に、その後 retainメッセージを送るごとに一つ増え、releaseするごとに減る。オブジェクトにretainCountというメッセージを送ると現在の参照カウンタを返してくれる。以下のようなコードでテストすると、


    ObjectA* objA = [[ObjectA alloc] init];
    ObjectA* obj_copy;
    NSMutableArray* array1 = [NSMutableArray array];
    printf("After initializing        : %i\n,[objA retainCount]);
    obj_copy = objA;
    printf("After assignment          : %i\n,[objA retainCount]);
    [objA retain];    printf("After retain              : %i\n,[objA retainCount]);
    [array1 addObject:objA]; 
   printf("After adding to array     : %i\n,[objA retainCount]);
    [array1 removeAllObjects];
    printf("After removing from array : %i\n,[objA retainCount]);
    [objA release]; 
   printf("After release             : %i\n,[objA retainCount]);

結果は、

    After initializing        : 1
    After assignment          : 1
    After retain              : 2
    After adding to array     : 3
    After removing from array : 2
    After release             : 1

となる。
生成した際にリファレンスカウンタは1になる。別の変数に代入した際にリファレンスカウンタを増やしたければ代入するだけではだめで明示的にretainをかけてやる必要がある。NSMutableArrayに加えたときリファレンスカウンタが増えるのはオブジェクトを集合に追加する際retainをかけてくれているから。Cocoaで提供されているコレクションフレームワークは内部でretainをかけており、removeする際releaseをかけているので注意が必要だ。

AutoreleasePool

しかし、こうやってすべてのオブジェクトを管理するのは面倒だというので、AutoRelasePoolという仕組みが用意されている。このプールにオブジェクトを登録しておけば、リファレンスカウンタに関係なくプールが存在する間はオブジェクトのインスタンスも保証され、Poolの削除とともにオブジェクトも破棄されるという仕組み。Cocoaのクラスはこの仕組みが前提になっているケースが多いので、Foundationのクラスを使うターミナルのプログラムでも以下のようなコードがメイン関数に追加されている。

    NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];    // User code    ObjectA* objA = [[[ObjectA alloc] init] autorelease];    .....    [pool drain];

このように プールを作成しオブジェクトにautoreleaseメッセージを投げることでプールに登録することができる。オブジェクトはプログラムでreleaseせずとも[pool drain]で破棄される。仕組み的には[pool drain]で登録されたオブジェクトに一斉にreleaseを投げているだけのようだ。逆に言うとプールに登録したオブジェクトといえど、リファレンスカウンタで制御されていてretain/releaseの回数のつじつまはあっていなければならない。「リファレンスカウンタに関係なく」と書いたが、実際にはプールに登録したオブジェクトに関しては「プログラム上でリファレンスカウンタに関係してはならない」が正解か。

また、NSAutoreleasePoolは複数生成することができる。


    NSAutoreleasePool* pool1 = [[NSAutoreleasePool alloc] init];
    printf("Pool1 is created\n");
    ObjectA objA = [[ObjectA alloc] initWithString:@"objA"];
    [objA autorelease];    printf("Pool2 is created\n"); 
   NSAutoreleasePool* pool2 = [[NSAutoreleasePool alloc] init];
    ObjectA objB = [[ObjectA alloc] initWithString:@"objB"];
    [objB autorelease];    printf("Pool2 is drained\n");
    [pool2 drain];    printf("Pool1 is drained\n"); 
   [pool1 drain];

結果は

    Pool1 is created.    Pool2 is created.    Pool2 is drained.    objB is released.    Pool1 is drained.    objA is released.

つまりオブジェクトは直近に生成されたプールにより制御される。一つのプールに依存すると、プログラムが終了するまで多量のインスタンスを抱えることになりかねない。多くのメモリーを消費するクラスや多量のインスタンスを生成する処理では、対象のインスタンスを使用するスコープでNSAutoreleasePoolを生成し不要となったら破棄するのがベター。

Objecitve-Cにおけるretain/release/autoreleaseの方針

実は、このAutoreleasePoolがあるので最初にObjective-Cを書こうと思ったときこのメモリー管理で訳が分からなくなる。上記は簡単な例で説明したが、通常はオブジェクトはインスタンス変数に別のオブジェクトの参照を持っておりそれぞれのライフサイクルが異なっているのは普通で、しかもそれぞれ自身でretain/releaseをかけていたり、AutoreleasePoolで管理されていたりと管理方法もバラバラになってしまう。で、結局retain/releaseのバランスが崩れて、二重解放してしまったり解放されないオブジェクトができたりする。

いくつかの実験とWebサイトなどの情報をまとめると、以下のような方針がよいようだ。

  1. 自身が生成したオブジェクトは自分で解放する。つまり、alloc-initでオブジェクトを生成したメソッド、またはクラスは自身の責任はreleaseをかけるか、生成時にautoreleaseを投げておく。
  2. CocoaのFrameworkでは、クラス名が先頭についた生成メソッドはautoreleaseがかかっている。例えば、NSArrayにおける+arrayWithObjectsや、NSStringにおける+stringWithCStringなど。これらについては、積極的にこれらの生成メソッドを使用しalloc - init***で生成しない。
  3. 同様に自作のクラスについては、CocoaのFrameworkに習いなるべく+クラス名の生成メソッドを用意しその中でautoreleaseをかけるなどして、自身のオブジェクトのライフサイクルに関しては自身で責任を取る。
  4. インスタンス変数については、そのオブジェクトの由来に関わらずretainをかけ、deallocの中でreleaseを入れる。こうすれば、例えばAutoreleasePoolに登録されているオブジェクトでも辻褄は合う。
  5. 局所的に多量のインスタンスを生成する場合(特にループ内など)は、全体のNSAutoreleasePoolの制御に任せるとメモリーをどんどん消費していくので、大量の一時的インスタンスを生成するようなメソッドやループ内ではローカルのNSAutoreleaseaPoolを適用する。

 

コメント

このブログの人気の投稿

W-ZERO3 カスタマイズ関連

Advanced/W-ZERO3[es]のカスタマイズのメモ。 いろいろインストールしているうちに何をどこから持ってきたのかわからなくなりそうなので、メモを残しておく。 ctrlwapmini テンキー関連の文字入力方式を改善するソフト。 キーマップの作成で携帯電話風の入力方式を利用できたりする。わたしはAuのカシオ系に慣れてしまったので、 w42ca風のキーマップ を拾ってきて利用している。 入手先: http://hp.vector.co.jp/authors/VA004474/wince/wince.html gsgetfile.dll 標準のファイル選択ダイアログを置換するDLL。 My Documents以外のフォルダにアクセスするために作成されたものらしい。いろんなソフトで前提になっているので、とりあえず導入しておく。 入手先: http://www.geocities.co.jp/SiliconValley-Cupertino/2039/ Multi Key Hook 標準では一つしか使えないキーフックを複数のアプリに割当で着るようにするソフト。 入手先をダウンロードし、Windowsフォルダにぶち込んでおく。 入手先: http://geocities.yahoo.co.jp/gl/hou ming 2/view/20070906/1189012118 DefaultMailer advanced/W-ZERO3[es]には、W-ZERO3メールとOutlookメールが入っているが標準MUAをどちらにするか切り替えるソフト。 標準ではOutlookとなっているが実際にはW-ZERO3メールを使うことの方が多いので、todayCompactなどから起動する際、このソフトを利用してW-ZERO3メールが起動するように調整。 入手先: Andante:DefaultMailer version 0.1.0.0リリース KeyLockSuspender 側面のキーロックスイッチの動作をカスタマイズできるソフト。 これでキーロックに連動して、画面のオンオフ、サスペンドなどを強制的に行いバッテリーの不要な消耗を防ぐ。 入手先からダウンロードして適当なフォルダに展開したら、ショートカットを作成してスタートアップに入れておく。 入手先: KeyLockSuspend...

Thinkpad T42

新たに購入したお仕事用のPC Thinkpad T42が先週末届いた。 仕様は、Pentium-M 1.80GHz, 1400x1050の15型TFT液晶、メモリーは追加して1.5GB(増設用に2GBを用意していたが、秘書さんのPCが256MBで苦しんでいたので1GBあげてしまった)、指紋センサー付き。無線もEEE802.11a/b/g対応となった。 こうして、iBookと並べてみると対照的。天使と悪魔か…… 今まで使用してたT30と比較すると、多少CPUが早くなりUSBが2.0になり指紋センサーがついて、やけに軽くなった。腰痛持ちの私にとっては、重量がぐんと軽くなったのが一番うれしいか。それでも2kg以上あるが。 指紋センサーはパームレスト上に(写真でいうと右側)実装されている。付属のソフトで設定すると、起動時のBIOS、HDDのパスワード投入、WindowsXPのログイン用パスワード投入の代わりに、電源オン時の指紋照合一発で済ませることができる。センサーに読み込ませるためには、指を一定の角度でセンサーに向けてまっすぐに動かさないと誤認識される。多少コツが必要で偶に失敗する。指紋はいくつか指を登録できるので複数を登録しておいたほうが無難。 今回も新しいおもちゃになりそうな機能はいくつかついているのだが、2日くらいで飽きてしまった。仕事で使うには十分なスペックで、十分に快適。ちょっと前まではお仕事用のPCも結構愛着やこだわりを持っていたのだが、買い替えを行って新しいPCが来てもあまりワクワクしなくなった。最近は、2年に一度機械的に買い替えを行うような感じ。スペック的に見るとiBookなどと比べるまでもないほどはるかに重装備だが、iBookのほうが楽しい。 PCの価値はスペックだけでは語れないのだよ(ムスカ風)