NSAutoreleasePool & thread
2017-07-25 23:54
387 查看
https://developer.apple.com/documentation/foundation/nsautoreleasepool
An object that supports Cocoa’s reference-counted memory management system.
An autorelease pool stores objects that are sent a
Important
If you use Automatic Reference Counting (ARC), you cannot use autorelease pools directly. Instead, you use
you would write:
In a reference-counted environment (as opposed to one which uses garbage collection), an
In a reference counted environment, Cocoa expects there to be an autorelease pool always available. If a pool is not available, autoreleased objects do not get released and you leak memory. In this situation, your program will typically log suitable warning messages.
The Application Kit creates an autorelease pool on the main thread at the beginning of every cycle of the event loop, and drains it at the end, thereby releasing any autoreleased objects generated while processing an event. If you use the Application Kit, you therefore typically don’t have to create your own pools. If your application creates a lot of temporary autoreleased objects within the event loop, however, it may be beneficial to create “local” autorelease pools to help to minimize the peak memory footprint.
You create an
Each thread (including the main thread) maintains its own stack of
If your application or thread is long-lived and potentially generates a lot of autoreleased objects, you should periodically drain and create autorelease pools (like the Application Kit does on the main thread); otherwise, autoreleased objects accumulate and your memory footprint grows. If, however, your detached thread does not make Cocoa calls, you do not need to create an autorelease pool.
Note
If you are creating secondary threads using the POSIX thread APIs instead of
An object that supports Cocoa’s reference-counted memory management system.
An autorelease pool stores objects that are sent a
releasemessage when the pool itself is drained.
Important
If you use Automatic Reference Counting (ARC), you cannot use autorelease pools directly. Instead, you use
@autoreleasepoolblocks. For example, in place of:
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; // Code benefitting from a local autorelease pool. [pool release];
you would write:
@autoreleasepool { // Code benefitting from a local autorelease pool. }
@autoreleasepoolblocks are more efficient than using an instance of
NSAutoreleasePooldirectly; you can also use them even if you do not use ARC.
In a reference-counted environment (as opposed to one which uses garbage collection), an
NSAutoreleasePoolobject contains objects that have received an
autoreleasemessage and when drained it sends a
releasemessage to each of those objects. Thus, sending
autoreleaseinstead of
releaseto an object extends the lifetime of that object at least until the pool itself is drained (it may be longer if the object is subsequently retained). An object can be put into the same pool several times, in which case it receives a
releasemessage for each time it was put into the pool.
In a reference counted environment, Cocoa expects there to be an autorelease pool always available. If a pool is not available, autoreleased objects do not get released and you leak memory. In this situation, your program will typically log suitable warning messages.
The Application Kit creates an autorelease pool on the main thread at the beginning of every cycle of the event loop, and drains it at the end, thereby releasing any autoreleased objects generated while processing an event. If you use the Application Kit, you therefore typically don’t have to create your own pools. If your application creates a lot of temporary autoreleased objects within the event loop, however, it may be beneficial to create “local” autorelease pools to help to minimize the peak memory footprint.
You create an
NSAutoreleasePoolobject with the usual
allocand
initmessages and dispose of it with
drain(or
release—to understand the difference, see Garbage Collection). Since you cannot retain an autorelease pool (or autorelease it—see
retainand
autorelease), draining a pool ultimately has the effect of deallocating it. You should always drain an autorelease pool in the same context (invocation of a method or function, or body of a loop) that it was created. See Using Autorelease Pool Blocks for more details.
Each thread (including the main thread) maintains its own stack of
NSAutoreleasePoolobjects (see Threads). As new pools are created, they get added to the top of the stack. When pools are deallocated, they are removed from the stack. Autoreleased objects are placed into the top autorelease pool for the current thread. When a thread terminates, it automatically drains all of the autorelease pools associated with itself.
Threads
If you are making Cocoa calls outside of the Application Kit’s main thread—for example if you create a Foundation-only application or if you detach a thread—you need to create your own autorelease pool.If your application or thread is long-lived and potentially generates a lot of autoreleased objects, you should periodically drain and create autorelease pools (like the Application Kit does on the main thread); otherwise, autoreleased objects accumulate and your memory footprint grows. If, however, your detached thread does not make Cocoa calls, you do not need to create an autorelease pool.
Note
If you are creating secondary threads using the POSIX thread APIs instead of
NSThreadobjects, you cannot use Cocoa, including
NSAutoreleasePool, unless Cocoa is in multithreading mode. Cocoa enters multithreading mode only after detaching its first
NSThreadobject. To use Cocoa on secondary POSIX threads, your application must first detach at least one
NSThreadobject, which can immediately exit. You can test whether Cocoa is in multithreading mode with the
NSThreadclass method
isMultiThreaded.
Garbage Collection
In a garbage-collected environment, there is no need for autorelease pools. You may, however, write a framework that is designed to work in both a garbage-collected and reference-counted environment. In this case, you can use autorelease pools to hint to the collector that collection may be appropriate. In a garbage-collected environment, sending adrainmessage to a pool triggers garbage collection if necessary;
release, however, is a no-op. In a reference-counted environment,
drainhas the same effect as
release. Typically, therefore, you should use
draininstead of
release.
相关文章推荐
- NSAutoreleasePool' is unavailable: not available in automatic reference counting mode
- Xcode中使用NSAutoreleasePool报错的问题
- NSAutoReleasePool
- C#中的thread和task之 Thread & ThreadPool
- NSAutoreleasePool自动释放池
- JAVA ThreadPool & ThreadFactory
- Threadpool & C
- 重新认识下NSAutoreleasePool
- Foundation框架常用数据类型和NSAutoreleasePool自动释放池解析
- NSAutoreleasePool
- 关于 NSAutoreleasePool中 release 与 drain 区别
- NSAutoReleasePool
- 危险的NSAutoreleasePool
- 善用 NSAutoreleasePool 节约宝贵内存
- ARC 工程出现错误__NSAutoreleaseNoPool(): Object 0x8850ce0 of class __NSCFData autoreleased with no pool in
- CCThread(On iOS, should create autorelease pool when create a new thread)
- NSAutoReleasePool的理解
- 如果autorelease NSAutoreleasePool对象会发生什么?
- 了解Objective-C中NSAutoreleasePool使用方法
- NSAutoreleasePool自动释放池