objc でヒープ内に確保したオブジェクトは、参照カウンタを持つ。

この参照カウンタが 0 になったタイミングで、そのオブジェクトは開放される。

参照カウンタの制御に関するメソッドには次がある。

• alloc

  • オブジェクトをヒープ内に確保し、参照カウンタを 1 にセットする

• retain

  • 参照カウンタをインクリメントする

• release

  • 参照カウンタをデクリメントして、0 になった場合にオブジェクトを開放する

以下のコードを実行すると、

    obj = [[MyClass alloc] init:1]; /* step1, 参照カウンタ: 1 */
    [obj retain];                   /* step2, 参照カウンタ: 2 */
    NSLog( @"release-1" );          /* step2-2 */
    [obj release];                  /* step3, 参照カウンタ: 1 */
    NSLog( @"release-2" );          /* step3-2 */
    [obj release];                  /* step4, 参照カウンタ: 0 */
    NSLog( @"release-3" );          /* step4-2 */

この時の出力は次になる。

release-1
release-2
MyClass dealloc -- obj:1
release-3

この時の参照カウンタに着目して動作を説明すると、以下の通り。

• step1 の段階で参照カウンタが 1 にセットされる
• step2 では、retain によってインクリメンされて参照カウンタは 2 になる。
• step3 では、release によって参照カウンタがデクリメントされる。 デクリメント後の参照カウンタは 1 なので、オブジェクトはまだ開放されない
• step4 では、release によって参照カウンタがデクリメントされる。 デクリメント後の参照カウンタは 0 なので、オブジェクトは開放される。

オートリリースプールのコンセプトは、次の通りである。

『ヒープオブジェクト個々に対して release するのは面倒なので、 ヒープオブジェクトをグループでまとめて管理するクラスを作成し、 そのクラスのインスタンスを開放するタイミングで、 その管理クラスインスタンスに登録されているヒープオブジェクトに対して まとめて release を呼ぶ』

オートリリースプールには、 次の 2 つの生成方法がある。

• NSAutoreleasePool のインスタンスを生成する
• @autoreleasepool ブロックを使用する

NSAutoreleasePool のサンプル を以下に示す。

{
  NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

  MyClass *obj;
  obj = [[[MyClass alloc] init:0]autorelease];
  obj = [[[MyClass alloc] init:1]autorelease];

  NSLog( @"NSAutoreleasePool-0" );
  [pool release];
  NSLog( @"NSAutoreleasePool-1" );
}

上記サンプルを解説すると、

• [[NSAutoreleasePool alloc] init] によって、オートリリースプールを生成する
• [pool release]; によって、オートリリースプールを開放する
• 上記処理の間に autorelease メソッド が呼ばれたヒープオブジェクトは、 オートリリースプールに登録され、オートリリースプール開放時に、 登録されているヒープオブジェクト自体も release される。

上記サンプルの出力は以下の通り。

NSAutoreleasePool-0
MyClass dealloc -- obj:1
MyClass dealloc -- obj:0
NSAutoreleasePool-1

上記出力を見ると、 [pool release]; によって、 オートリリースプールに登録されている ヒープオブジェクトの release が呼ばれ開放されていることが分かる。

@autoreleasepool は、 NSAutoreleasePool のシンタックスシュガーである。

次のコードと、

{
  NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
  // some codes
  [pool release];
}

次のコードは等価である。

@autoreleasepool {
  // some codes
}

オートリリースプールを利用することで、メモリ管理の手間を削減できる。

一方で、メモリの開放タイミングがオートリリースプール開放時になるため、 細かいメモリの開放制御を行えないデメリットもある。

例えば、非常に大きいサイズのメモリを確保するような場合、 オートリリースプールに開放処理を任せてしまうと、 メモリ開放が後回しになってしまってヒープメモリを 圧迫してしまう可能性がある。

オートリリースプールを使用する場合は、 オートリリースプール自体のライフサイクルを十分検討する必要がある。

次に ARC によるメモリ開放タイミングのサンプルを示す。

  MyClass *obj = [[MyClass alloc] init:2];
  obj = [[MyClass alloc] init:3];
  obj = nil;
  NSLog(@"test");

• [[MyClass alloc] init:2] で、確保したオブジェクトが obj に代入される
• [[MyClass alloc] init:3] で、確保したオブジェクトが obj に代入される
• この時、元々 obj に格納されていたオブジェクトの release が呼ばれ、開放される
• obj = nil で元々 obj に格納されていたオブジェクトの release が呼ばれ、開放される

MyClass dealloc -- obj:2
MyClass dealloc -- obj:3
test

ARC では、参照の度合いによって _strong, _weak の違いがある。 _strong は前述の通り変数がスマートポインタになる。 一方で _weak は参照だけして retain, release を行なわない。

なお、 _strong, _weak どちらも宣言しない場合はデフォルト _strong になる。

_weak は、循環参照に対処するケースで利用する。