下面关于Objective-C内存管理的描述错误的是 A 当使用ARC来管理内存时，代码中不可以出现autorelease B autoreleasepool 在 drain 的时候会释放在其中分配的对象 C 当使用ARC来管理内存时，在线程中大量分配对象而不用autoreleasepool则可能会造成内存泄露 D 在使用ARC的项目中不能使用NSZone
L'erreur de A est que lors de l'utilisation d'ARC, le compilateur vous interdira d'utiliser la libération automatique et le compilateur vous aidera à l'ajouter, tout comme conserver et publier. Mais vous pouvez utiliser __autoreleasing pour spécifier la variable et l'ajouter au autoreleasepool
La description de C est correcte. L'utilisation d'autoreleasepool peut accélérer la libération d'objets lorsqu'un grand nombre d'objets doivent être créés. Si A se trompe, cela peut seulement signifier que le créateur de questions veut vous tester. Le principe d'ARC est en fait que le compilateur ajoute automatiquement la version automatique et d'autres codes au code pour vous. En fait, lors de l'écriture d'autorelease dans un projet ARC, il ne peut même pas être compilé. Si vous y réfléchissez de cette façon, A a en fait raison. Mais comme les trois autres sont corrects, je ne peux choisir que A.
==========Mise à jour========== J'espère que les personnes qui n'aiment pas ma réponse pourront me dire ce qui ne va pas dans la zone de commentaire de ma réponse. Même si je n'ai que spéculé grossièrement sur la raison pour laquelle A avait tort, j'ai clairement répondu que l'affiche C avait raison. Pour savoir pourquoi C est correct, vous pouvez lire le document officiel : autoreleasepool.
Si vous générez un thread secondaire. Vous devez créer votre propre bloc de pool à libération automatique dès que le thread commence à s'exécuter ; sinon, votre application perdra des objets (voir Blocs et threads de pool à libération automatique pour plus de détails. )
==========Mise à jour à nouveau========== Le document ci-dessus concerne MRC. Vous pouvez lire si un pool de libération automatique est nécessaire pour créer un grand nombre d'objets. dans les discussions dans ARC. Cette réponse : http://stackoverflow.com/ques...
A et D sont fondamentalement les mêmes, mais en fait NSZone *zone = NSDefaultMallocZone(); ce code peut être compilé et exécuté.
La réponse de référence que vous lisez est fausse. Sous ARC, vous ne pouvez pas utiliser la libération automatique pour la programmation, mais vous pouvez utiliser @autoreleasepool. Sa fonction est de réduire l'utilisation de la mémoire.
@autoreleasepool {
}
Le contenu suivant est principalement en réponse à la question de @ChickenBoy : "Chaque thread d'une application Cocoa maintient sa propre pile de blocs de pool de libération automatique. Dans d'autres threads, vous devez créer vous-même le pool de libération automatique, sinon il ne sera pas automatiquement libéré et la mémoire sera générée par une fuite.".
Chaque thread d'une application Cocoa maintient sa propre pile de blocs de pool à libération automatique Cette phrase n'énonce qu'un seul fait "Chaque thread d'une application Cocoa maintient sa propre pile de blocs de pool à libération automatique" Si vous écrivez. un programme Foundation uniquement ou si vous détachez un thread, vous devez créer votre propre bloc de pool à libération automatique. Si vous écrivez une application Foundation uniquement ou si vous détachez un thread, vous devez créer votre propre bloc de pool à libération automatique. . Libérez le bloc piscine.
Si votre application ou votre thread a une durée de vie longue et génère potentiellement de nombreux objets à libération automatique, vous devez utiliser des blocs de pool à libération automatique (comme le font AppKit et UIKit sur le thread principal) ; sinon, les objets à libération automatique s'accumulent et votre empreinte mémoire augmente. Si votre thread détaché n'effectue pas d'appels Cocoa, vous n'avez pas besoin d'utiliser un bloc de pool à libération automatique. Si votre application ou votre thread survit longtemps et peut générer un grand nombre d'objets à libération automatique, vous devez automatiquement libérer le pool ; bloquer ; sinon, les objets libérés automatiquement s’accumuleront et occuperont votre mémoire. Si le thread que vous créez n'appelle pas Cacoa, vous n'avez pas besoin d'utiliser le bloc pool autorelease.
Lorsque vous créez vous-même un nouveau thread, vous devez gérer la mémoire qu'il contient. Ce n'est que dans la boucle d'exécution du thread principal qu'il ajoutera automatiquement autoreleasePush() et autoreleasePop() pour vous.
Parce qu'ARC est une fonctionnalité du compilateur, pas une fonctionnalité d'exécution iOS, ni un ramasse-miettes dans d'autres langages. Cela signifie donc qu'il ne peut gérer que la gestion de la mémoire qui est déterminée au moment de la compilation, et le mécanisme utilisé est le comptage de références. En d'autres termes, sa libération de mémoire n'est pas obligatoire. Par exemple, les références de mémoire mutuelles, les références dynamiques, etc. feront que le nombre de références ne sera pas mis à 0 immédiatement, une libération explicite est donc nécessaire à ce moment.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
L'erreur de A est que lors de l'utilisation d'ARC, le compilateur vous interdira d'utiliser la libération automatique et le compilateur vous aidera à l'ajouter, tout comme conserver et publier. Mais vous pouvez utiliser __autoreleasing pour spécifier la variable et l'ajouter au autoreleasepool
La description de C est correcte. L'utilisation d'autoreleasepool peut accélérer la libération d'objets lorsqu'un grand nombre d'objets doivent être créés.
Si A se trompe, cela peut seulement signifier que le créateur de questions veut vous tester. Le principe d'ARC est en fait que le compilateur ajoute automatiquement la version automatique et d'autres codes au code pour vous. En fait, lors de l'écriture d'autorelease dans un projet ARC, il ne peut même pas être compilé. Si vous y réfléchissez de cette façon, A a en fait raison.
Mais comme les trois autres sont corrects, je ne peux choisir que A.
==========Mise à jour==========
J'espère que les personnes qui n'aiment pas ma réponse pourront me dire ce qui ne va pas dans la zone de commentaire de ma réponse.
Même si je n'ai que spéculé grossièrement sur la raison pour laquelle A avait tort, j'ai clairement répondu que l'affiche C avait raison.
Pour savoir pourquoi C est correct, vous pouvez lire le document officiel : autoreleasepool.
==========Mise à jour à nouveau==========
Le document ci-dessus concerne MRC. Vous pouvez lire si un pool de libération automatique est nécessaire pour créer un grand nombre d'objets. dans les discussions dans ARC. Cette réponse :
http://stackoverflow.com/ques...
A et D sont fondamentalement les mêmes, mais en fait
NSZone *zone = NSDefaultMallocZone();ce code peut être compilé et exécuté.
La réponse de référence que vous lisez est fausse.
Sous ARC, vous ne pouvez pas utiliser la libération automatique pour la programmation, mais vous pouvez utiliser
@autoreleasepool. Sa fonction est de réduire l'utilisation de la mémoire.Chaque thread d'une application Cocoa maintient sa propre pile de blocs de pool à libération automatique
Cette phrase n'énonce qu'un seul fait "Chaque thread d'une application Cocoa maintient sa propre pile de blocs de pool à libération automatique"
Si vous écrivez. un programme Foundation uniquement ou si vous détachez un thread, vous devez créer votre propre bloc de pool à libération automatique.
Si vous écrivez une application Foundation uniquement ou si vous détachez un thread, vous devez créer votre propre bloc de pool à libération automatique. . Libérez le bloc piscine.
Si votre application ou votre thread a une durée de vie longue et génère potentiellement de nombreux objets à libération automatique, vous devez utiliser des blocs de pool à libération automatique (comme le font AppKit et UIKit sur le thread principal) ; sinon, les objets à libération automatique s'accumulent et votre empreinte mémoire augmente. Si votre thread détaché n'effectue pas d'appels Cocoa, vous n'avez pas besoin d'utiliser un bloc de pool à libération automatique.
Si votre application ou votre thread survit longtemps et peut générer un grand nombre d'objets à libération automatique, vous devez automatiquement libérer le pool ; bloquer ; sinon, les objets libérés automatiquement s’accumuleront et occuperont votre mémoire.
Si le thread que vous créez n'appelle pas Cacoa, vous n'avez pas besoin d'utiliser le bloc pool autorelease.
Lorsque vous créez vous-même un nouveau thread, vous devez gérer la mémoire qu'il contient. Ce n'est que dans la boucle d'exécution du thread principal qu'il ajoutera automatiquement autoreleasePush() et autoreleasePop() pour vous.
Parce qu'ARC est une fonctionnalité du compilateur, pas une fonctionnalité d'exécution iOS, ni un ramasse-miettes dans d'autres langages.
Cela signifie donc qu'il ne peut gérer que la gestion de la mémoire qui est déterminée au moment de la compilation, et le mécanisme utilisé est le comptage de références.
En d'autres termes, sa libération de mémoire n'est pas obligatoire. Par exemple, les références de mémoire mutuelles, les références dynamiques, etc. feront que le nombre de références ne sera pas mis à 0 immédiatement, une libération explicite est donc nécessaire à ce moment.