下面关于Objective-C内存管理的描述错误的是 A 当使用ARC来管理内存时，代码中不可以出现autorelease B autoreleasepool 在 drain 的时候会释放在其中分配的对象 C 当使用ARC来管理内存时，在线程中大量分配对象而不用autoreleasepool则可能会造成内存泄露 D 在使用ARC的项目中不能使用NSZone
A’s mistake is that when using ARC, the compiler will prohibit you from using autorelease, and the compiler will add it for you, just like retain and release. But you can use __autoreleasing to specify the variable and add it to the autoreleasepool
C’s description is correct. Using autoreleasepool can speed up object release when a large number of objects need to be created. If A is wrong, it can only mean that the question maker wants to test you. The principle of ARC is actually that the compiler automatically adds autorelease and other codes to the code for you. In fact, when writing autorelease in an ARC project, it cannot even be compiled. If you think about it this way, A is actually right. But since the other 3 are all correct, we can only choose A.
==========Update========== I hope that people who dislike my answer can tell me what is wrong in the comment area of my answer. Even though I only roughly speculated why A was wrong, I clearly answered that the poster C was right. As for why C is correct, you can read the official document: autoreleasepool.
If you spawn a secondary thread. You must create your own autorelease pool block as soon as the thread begins executing; otherwise, your application will leak objects. (See Autorelease Pool Blocks and Threads for details.)
==========Updated again========== The above document is about MRC. If you need an autorelease pool to create a large number of objects in threads in ARC, you can read this answer: http://stackoverflow.com/ques...
A and D are basically the same, but in fact NSZone *zone = NSDefaultMallocZone(); this code can be compiled and run.
The reference answer you read is wrong. Under ARC, you cannot use autorelease for programming, but you can use @autoreleasepool. Its function is to reduce memory usage.
@autoreleasepool {
}
The following content is mainly in reply to @ChickenBoy's "Each thread in a Cocoa application maintains its own stack of autorelease pool blocks. Other threads need to create their own autorelease pool, otherwise it will not be automatically released and memory leaks will occur.".
Each thread in a Cocoa application maintains its own stack of autorelease pool blocks. This sentence only states one fact "Each thread in a Cocoa application maintains its own stack of autorelease pool blocks" If you are writing a Foundation-only program or if you detach a thread, you need to create your own autorelease pool block. If you are writing a Foundation-only application or detach a thread yourself, you need to create your own autorelease pool block.
If your application or thread is long-lived and potentially generates a lot of autoreleased objects, you should use autorelease pool blocks (like AppKit and UIKit do on the main thread); otherwise, autoreleased objects accumulate and your memory footprint grows. If your detached thread does not make Cocoa calls, you do not need to use an autorelease pool block. If your application or thread survives for a long time and may generate a large number of autoreleased objects; you should automatically autorelease the pool block; otherwise, Autoreleased objects accumulate and occupy your memory. If the thread you create does not call Cacoa, you do not need to use the autorelease pool block.
If you create a new thread yourself, you have to manage the memory inside it. Only in the runloop of the main thread will it automatically add autoreleasePush() and autoreleasePop() for you.
Because ARC is a compiler feature, not an iOS runtime feature, nor a garbage collector in other languages. So this means that it can only handle memory management that is determined at compile time, and the mechanism used is reference counting. In other words, his memory release is not mandatory. For example, mutual memory references, dynamic references, etc. will cause the reference count to not be set to 0 immediately, so explicit release is necessary at this time.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
A’s mistake is that when using ARC, the compiler will prohibit you from using autorelease, and the compiler will add it for you, just like retain and release. But you can use __autoreleasing to specify the variable and add it to the autoreleasepool
C’s description is correct. Using autoreleasepool can speed up object release when a large number of objects need to be created.
If A is wrong, it can only mean that the question maker wants to test you. The principle of ARC is actually that the compiler automatically adds autorelease and other codes to the code for you. In fact, when writing autorelease in an ARC project, it cannot even be compiled. If you think about it this way, A is actually right.
But since the other 3 are all correct, we can only choose A.
==========Update==========
I hope that people who dislike my answer can tell me what is wrong in the comment area of my answer.
Even though I only roughly speculated why A was wrong, I clearly answered that the poster C was right.
As for why C is correct, you can read the official document: autoreleasepool.
==========Updated again==========
The above document is about MRC. If you need an autorelease pool to create a large number of objects in threads in ARC, you can read this answer:
http://stackoverflow.com/ques...
A and D are basically the same, but in fact
NSZone *zone = NSDefaultMallocZone();this code can be compiled and run.
The reference answer you read is wrong.
Under ARC, you cannot use autorelease for programming, but you can use
@autoreleasepool. Its function is to reduce memory usage.Each thread in a Cocoa application maintains its own stack of autorelease pool blocks.
This sentence only states one fact "Each thread in a Cocoa application maintains its own stack of autorelease pool blocks"
If you are writing a Foundation-only program or if you detach a thread, you need to create your own autorelease pool block.
If you are writing a Foundation-only application or detach a thread yourself, you need to create your own autorelease pool block.
If your application or thread is long-lived and potentially generates a lot of autoreleased objects, you should use autorelease pool blocks (like AppKit and UIKit do on the main thread); otherwise, autoreleased objects accumulate and your memory footprint grows. If your detached thread does not make Cocoa calls, you do not need to use an autorelease pool block.
If your application or thread survives for a long time and may generate a large number of autoreleased objects; you should automatically autorelease the pool block; otherwise, Autoreleased objects accumulate and occupy your memory.
If the thread you create does not call Cacoa, you do not need to use the autorelease pool block.
If you create a new thread yourself, you have to manage the memory inside it. Only in the runloop of the main thread will it automatically add autoreleasePush() and autoreleasePop() for you.
Because ARC is a compiler feature, not an iOS runtime feature, nor a garbage collector in other languages.
So this means that it can only handle memory management that is determined at compile time, and the mechanism used is reference counting.
In other words, his memory release is not mandatory. For example, mutual memory references, dynamic references, etc. will cause the reference count to not be set to 0 immediately, so explicit release is necessary at this time.