「NSAutoreleasePool Class Reference」の編集履歴（バックアップ）一覧はこちら
「NSAutoreleasePool Class Reference」(2010/02/17 (水) 00:04:50) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
//0.下はいじらない
Tags:&tags()
//1.以下に続けてADCでの分類を書き込みリンクする。「NSHogeのクラスリファレンス」、まで書く
&link_toppage(トップ) > [[リファレンス]] > Core Services階層 > Foundation > NSAutoreleasePool Class Reference
//2.リファレンス日本語名を見出し1で書く。wiki内のリンクで用いられるタイトルになる。翻訳元にもリンクする。
*NSAutoreleasePool クラスリファレンス [[翻訳元>http://developer.apple.com/mac/library/documentation/Cocoa/Reference/Foundation/Classes/NSAutoreleasePool_Class/Reference/Reference.html]]
//3.翻訳元の最終更新日を書く
このページの最終更新：&date()
ADCの最終更新：2009-01-02
//4.以下、用語は頻繁に出てくる単語の翻訳ガイドラインを参照しながら翻訳する。
//5.ある程度書き終わったらタグ（未完または完成、カテゴリ名×3）をつけて下線を引く(広告との境)。これで終了。それではGood Luck!
//本文開始↓
|BGCOLOR(#eef):継承するクラス|BGCOLOR(#eef):[[NSObject>NSObject Class Reference]]|
|準拠しているプロトコル|[[NSObject (NSObject)>NSObject Protocol Reference]]|
|BGCOLOR(#eef):フレームワーク|BGCOLOR(#eef):/System/Library/Frameworks/[[Foundation.framework>Foundation Framework]]|
|使用可能な環境|Mac OS X v10.0|
|BGCOLOR(#eef):コンパニオンガイド|BGCOLOR(#eef):[[Cocoaメモリ管理プログラミングガイド>Memory Management Programming Guide for Cocoa]]|
|宣言ファイル|NSAutoreleasePool.h|
|TOP:BGCOLOR(#eef):サンプルコード|BGCOLOR(#eef):[[CocoaSpeechSynthesisExample]]&br()[[OpenCL NBody Simulation Example]]&br()[[SpellingChecker CarbonCocoa Bundled]]&br()[[SpellingChecker-CarbonCocoa]]&br()[[SpellingChecker-CocoaCarbon]]|
**概観(Overview)
----
NSAutoreleasePoolクラスはCocoaのリファレンスカウンタ方式のメモリ管理をサポートするのに使われます。自動解放プールはオブジェクトをストアし、プール自身がドレインされた時にそのオブジェクトのreleaseメソッドを呼び出します。
(ガーベジコレクション環境と対照的な)リファレンスカウンタ環境では、NSAutoreleasePoolオブジェクトは&link_anchor(autorelease){autorelease}メッセージを受信したオブジェクトを収容し、ドレインされた時にそれらのオブジェクトにそれぞれ&link_anchor(release){release}メッセージを送ります。このように、&link_anchor(release){release}メッセージの代わりに&link_anchor(autorelease){autorelease}メッセージを送ることで、オブジェクトの寿命を最低でもプールがドレインされるまで(その後保持されればもっと)延ばすことができます。オブジェクトは同じプールに何度か入れることができます。その場合、そのオブジェクトはプールに入れた回数だけ&link_anchor(){release}メッセージを受け取ることになります。
リファレンスカウンタ環境では、Cocoaフレームワークは常に自動解放プールが利用可能であることを想定しています。もしプールが利用可能でなければ、autoreleaseメッセージを受け取ったオブジェクトは解放されず、メモリリークとなります。このようなとき、プログラムはたいてい適切な警告をログに出力するでしょう。
Application Kitフレームワークはメインスレッド上ではイベントループの最初に自動解放プールを生成し、最後にプールをドレインします。そのため、イベント中に出力された自動解放されるオブジェクトは全て解放されます。したがって、Application Kitを使っているなら、大抵の場合は独自のプールを作る必要はありません。ただし、アプリケーションが自動解放される一時的なオブジェクトをイベントループ中に大量に生成する場合、メモリ使用量のピークを下げる為に「局所的な」自動解放プールを作った方が良いかもしれません。
NSAutoreleaseオブジェクトは通常のalloc、initメソッドで生成し、&link_anchor(drain){drain}メソッド(または&link_anchor(release){release}メソッド。違いを理解するには、&link_anchor(Garbage Collection){「ガーベジコレクション(Garbage Collection)」}を参照してください)で後始末をします。自動解放プールを保持すること(それと自動解放すること。&link_anchor(retain){retain}メソッドと&link_anchor(autorelease){autorelease}メソッドを参照してください)はできません。よって、プールをドレインすることは、結局はメモリの解放と同じ働きをします。自動解放プールは常に生成したのと同じ文脈(関数やメソッド、ループの内部)でドレインするべきです。詳細については&link_anchor(){Autorelease Pools}を参照してください。
それぞれのスレッド(メインスレッドを含む)は自信のNSAutoreleasePoolオブジェクトのスタックを維持します(&link_anchor(Threads){「スレッド(Threads)」}を参照してください)。新しいプールが作られると、そのプールはスタックトップに積まれます。プールが開放されると、そのプールはスタックから取り除かれます。自動解放されるオブジェクトはその時点でのスレッドの一番上の自動解放プールに収容されます。スレッドが終了すると、関連のある自動解放プールは全て自動的にドレインされます。
***&anchor(option=nolink,Threads){スレッド(Threads)}
Application Kitのメインスレッド以外でCocoaフレームワークを使用している場合、例えばFoundationのみのアプリケーションやメインスレッドから分離したスレッドの場合には、独自の自動解放プールを生成する必要があります。
アプリケーションやスレッドの寿命があまりに長く、多くの自動解放されるオブジェクトを出力する可能性がある場合、(Application Kitがメインスレッド上で行うように)定期的に自動解放プールを生成、ドレインするべきです。そうしなければ、自動解放されるオブジェクトが累積し、メモリ使用量が上昇します。ただし、分離したスレッドがCocoaフレームワークを使用しないのであれば、自動解放プールを生成する必要はありません。
|BGCOLOR(#eef):&bold(){注:}もしNSThreadオブジェクトではなく、POSIXスレッドAPIを使って第２のスレッドを生成する場合には、Cocoaがマルチスレッディングモードでない限り、NSAutoreleasePoolクラスを含むCocoaフレームワークを使うことはできません。Cocoaフレームワークは最初のNSThreadオブジェクトが分離した後のみマルチスレッディングモードになります。第２のPOSIXスレッドでCocoaフレームワークを使用する為には、そのアプリケーションでは最低一つのNSThreadオブジェクトが分離していなければなりません。そのスレッドはすぐに終了しても構いません。Cocoaフレームワークがマルチスレッディングモードであるかは、NSThreadクラスの&link_anchor(){isMultiThreaded}メソッドで調べることができます。|
***&anchor(option=nolink,Garbage Collection){ガーベジコレクション(Garbage Collection)}
ガーベジコレクションが有効な環境では、自動解放プールは必要ありません。しかし、ガーベジコレクション環境でもリファレンスカウンタ環境でも動くフレームワークを開発することになるかもしれません。このような時には、自動解放プールをガーベジコレクションが発動するきっかけとして使うことができます。ガーベジコレクション環境下では、&link_anchor(drain){drain}メッセージをプールに送ると、プールは必要であればガーベジコレクションを開始させます。ですが、&link_anchor(release){release}メソッドではそのようにはなりません。リファレンスカウンタ環境下では、&link_anchor(drain){drain}メソッドは&link_anchor(release){release}メソッドと同じ効果があります。したがって、通常は&link_anchor(release){release}メソッドの代わりに&link_anchor(drain){drain}メソッドを使用するべきです。
**このクラスでできること(Tasks)
----
***プールの管理(Managing a Pool)
&space(8)&link_anchor(release){– release}
&space(8)&link_anchor(drain){– drain}
&space(8)&link_anchor(autorelease){– autorelease}
&space(8)&link_anchor(retain){– retain}
***プールへのオブジェクトの追加(Adding an Object to a Pool)
&space(8)&link_anchor(class_addObject:){+ addObject:}
&space(8)&link_anchor(instance_addObject:){– addObject:}
**クラスメソッド
----
***&anchor(option=nolink,class_addObject:){addObject:}
**インスタンスメソッド
----
***&anchor(option=nolink,instance_addObject:){addObject:}
***&anchor(option=nolink,autorelease){autorelease}
***&anchor(option=nolink,drain){drain}
***&anchor(option=nolink,release){release}
***&anchor(option=nolink,retain){retain}
----
//0.下はいじらない
Tags:&tags()
//1.以下に続けてADCでの分類を書き込みリンクする。「NSHogeのクラスリファレンス」、まで書く
&link_toppage(トップ) > [[リファレンス]] > Core Services階層 > Foundation > NSAutoreleasePool Class Reference
//2.リファレンス日本語名を見出し1で書く。wiki内のリンクで用いられるタイトルになる。翻訳元にもリンクする。
*NSAutoreleasePool クラスリファレンス [[翻訳元>http://developer.apple.com/mac/library/documentation/Cocoa/Reference/Foundation/Classes/NSAutoreleasePool_Class/Reference/Reference.html]]
//3.翻訳元の最終更新日を書く
このページの最終更新：&date()
ADCの最終更新：2009-01-02
//4.以下、用語は頻繁に出てくる単語の翻訳ガイドラインを参照しながら翻訳する。
//5.ある程度書き終わったらタグ（未完または完成、カテゴリ名×3）をつけて下線を引く(広告との境)。これで終了。それではGood Luck!
//本文開始↓
|BGCOLOR(#eef):継承するクラス|BGCOLOR(#eef):[[NSObject>NSObject Class Reference]]|
|準拠しているプロトコル|[[NSObject (NSObject)>NSObject Protocol Reference]]|
|BGCOLOR(#eef):フレームワーク|BGCOLOR(#eef):/System/Library/Frameworks/[[Foundation.framework>Foundation Framework]]|
|使用可能な環境|Mac OS X v10.0|
|BGCOLOR(#eef):コンパニオンガイド|BGCOLOR(#eef):[[Cocoaメモリ管理プログラミングガイド>Memory Management Programming Guide for Cocoa]]|
|宣言ファイル|NSAutoreleasePool.h|
|TOP:BGCOLOR(#eef):サンプルコード|BGCOLOR(#eef):[[CocoaSpeechSynthesisExample]]&br()[[OpenCL NBody Simulation Example]]&br()[[SpellingChecker CarbonCocoa Bundled]]&br()[[SpellingChecker-CarbonCocoa]]&br()[[SpellingChecker-CocoaCarbon]]|
**概観(Overview)
----
NSAutoreleasePoolクラスはCocoaのリファレンスカウンタ方式のメモリ管理をサポートするのに使われます。自動解放プールはオブジェクトをストアし、プール自身がドレインされた時にそのオブジェクトのreleaseメソッドを呼び出します。
(ガーベジコレクション環境と対照的な)リファレンスカウンタ環境では、NSAutoreleasePoolオブジェクトは&link_anchor(autorelease){autorelease}メッセージを受信したオブジェクトを収容し、ドレインされた時にそれらのオブジェクトにそれぞれ&link_anchor(release){release}メッセージを送ります。このように、&link_anchor(release){release}メッセージの代わりに&link_anchor(autorelease){autorelease}メッセージを送ることで、オブジェクトの寿命を最低でもプールがドレインされるまで(その後保持されればもっと)延ばすことができます。オブジェクトは同じプールに何度か入れることができます。その場合、そのオブジェクトはプールに入れた回数だけ&link_anchor(release){release}メッセージを受け取ることになります。
リファレンスカウンタ環境では、Cocoaフレームワークは常に自動解放プールが利用可能であることを想定しています。もしプールが利用可能でなければ、autoreleaseメッセージを受け取ったオブジェクトは解放されず、メモリリークとなります。このようなとき、プログラムはたいてい適切な警告をログに出力するでしょう。
Application Kitフレームワークはメインスレッド上ではイベントループの最初に自動解放プールを生成し、最後にプールをドレインします。そのため、イベント中に出力された自動解放されるオブジェクトは全て解放されます。したがって、Application Kitを使っているなら、大抵の場合は独自のプールを作る必要はありません。ただし、アプリケーションが自動解放される一時的なオブジェクトをイベントループ中に大量に生成する場合、メモリ使用量のピークを下げる為に「局所的な」自動解放プールを作った方が良いかもしれません。
NSAutoreleaseオブジェクトは通常のalloc、initメソッドで生成し、&link_anchor(drain){drain}メソッド(または&link_anchor(release){release}メソッド。違いを理解するには、&link_anchor(Garbage Collection){「ガーベジコレクション(Garbage Collection)」}を参照してください)で後始末をします。自動解放プールを保持すること(それと自動解放すること。&link_anchor(retain){retain}メソッドと&link_anchor(autorelease){autorelease}メソッドを参照してください)はできません。よって、プールをドレインすることは、結局はメモリの解放と同じ働きをします。自動解放プールは常に生成したのと同じ文脈(関数やメソッド、ループの内部)でドレインするべきです。詳細については&link_anchor(){Autorelease Pools}を参照してください。
それぞれのスレッド(メインスレッドを含む)は自信のNSAutoreleasePoolオブジェクトのスタックを維持します(&link_anchor(Threads){「スレッド(Threads)」}を参照してください)。新しいプールが作られると、そのプールはスタックトップに積まれます。プールが開放されると、そのプールはスタックから取り除かれます。自動解放されるオブジェクトはその時点でのスレッドの一番上の自動解放プールに収容されます。スレッドが終了すると、関連のある自動解放プールは全て自動的にドレインされます。
***&anchor(option=nolink,Threads){スレッド(Threads)}
Application Kitのメインスレッド以外でCocoaフレームワークを使用している場合、例えばFoundationのみのアプリケーションやメインスレッドから分離したスレッドの場合には、独自の自動解放プールを生成する必要があります。
アプリケーションやスレッドの寿命があまりに長く、多くの自動解放されるオブジェクトを出力する可能性がある場合、(Application Kitがメインスレッド上で行うように)定期的に自動解放プールを生成、ドレインするべきです。そうしなければ、自動解放されるオブジェクトが累積し、メモリ使用量が上昇します。ただし、分離したスレッドがCocoaフレームワークを使用しないのであれば、自動解放プールを生成する必要はありません。
|BGCOLOR(#eef):&bold(){注:}もしNSThreadオブジェクトではなく、POSIXスレッドAPIを使って第２のスレッドを生成する場合には、Cocoaがマルチスレッディングモードでない限り、NSAutoreleasePoolクラスを含むCocoaフレームワークを使うことはできません。Cocoaフレームワークは最初のNSThreadオブジェクトが分離した後のみマルチスレッディングモードになります。第２のPOSIXスレッドでCocoaフレームワークを使用する為には、そのアプリケーションでは最低一つのNSThreadオブジェクトが分離していなければなりません。そのスレッドはすぐに終了しても構いません。Cocoaフレームワークがマルチスレッディングモードであるかは、NSThreadクラスの&link_anchor(){isMultiThreaded}メソッドで調べることができます。|
***&anchor(option=nolink,Garbage Collection){ガーベジコレクション(Garbage Collection)}
ガーベジコレクションが有効な環境では、自動解放プールは必要ありません。しかし、ガーベジコレクション環境でもリファレンスカウンタ環境でも動くフレームワークを開発することになるかもしれません。このような時には、自動解放プールをガーベジコレクションが発動するきっかけとして使うことができます。ガーベジコレクション環境下では、&link_anchor(drain){drain}メッセージをプールに送ると、プールは必要であればガーベジコレクションを開始させます。ですが、&link_anchor(release){release}メソッドではそのようにはなりません。リファレンスカウンタ環境下では、&link_anchor(drain){drain}メソッドは&link_anchor(release){release}メソッドと同じ効果があります。したがって、通常は&link_anchor(release){release}メソッドの代わりに&link_anchor(drain){drain}メソッドを使用するべきです。
**このクラスでできること(Tasks)
----
***プールの管理(Managing a Pool)
&space(8)&link_anchor(release){– release}
&space(8)&link_anchor(drain){– drain}
&space(8)&link_anchor(autorelease){– autorelease}
&space(8)&link_anchor(retain){– retain}
***プールへのオブジェクトの追加(Adding an Object to a Pool)
&space(8)&link_anchor(class_addObject:){+ addObject:}
&space(8)&link_anchor(instance_addObject:){– addObject:}
**クラスメソッド
----
***&anchor(option=nolink,class_addObject:){addObject:}
**インスタンスメソッド
----
***&anchor(option=nolink,instance_addObject:){addObject:}
***&anchor(option=nolink,autorelease){autorelease}
***&anchor(option=nolink,drain){drain}
***&anchor(option=nolink,release){release}
***&anchor(option=nolink,retain){retain}
----
表示オプション
横に並べて表示：
変化行の前後のみ表示：
