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

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を適用する。

 

コメント

このブログの人気の投稿

WWDC 2010の予想

眠れないので、明日に迫ったWWDC2010の予想でもしてみよう。 もう確実なのがiPhone新モデルとiPhone OS 4.0の発表。 予想される大きな改良点は、 マルチタスクになる ホームにフォルダなどの概念が取り込まれ、UIが大きく変更される テザリングが可能となり iPhoneをWiFiルーター化できる iChatが組み込まれる Facebookとの連携が組み込まれる ファイルの同期がiPadのように組み込まれる iPadとの同期がMacなしで可能となる 既にiPhoneの3G上で動作するSkypeが発表されているのでインパクトは薄いかも知れないけれど、3G上で動作するVoIPとしてiChatが提供されればユーザーとコミュニケーション・ツールとしてのiPhoneの使い方は大きく変わりそうな気がしている。 その他には、Safari Extension、新Macbook Air、新Mac Proなどかな。iTunes.comも噂されている。そう言えば、MobileMeの無料化なんてのも噂としてあるが……

My name is E

E の名刺を作って、iPhoneの専用アプリを導入してみた。 写真のようにカードが表示されるので、相手に向かってiPhoneを振ってあげれば名刺が飛んでいくというインターフェイス。なにせiPhoneユーザーが周りにいないのでどうやって相手の認識しているか不明だけれど、おもしろいインターフェイス。 ちなみに、わたしの公開カードは http://eee.am/yostos

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の価値はスペックだけでは語れないのだよ(ムスカ風)