iOS 内存管理(1) —— MRC & ARC

基本的内存管理规则

1 自己生成的对象自己持有
2 非自己生成的对象,自己也能持有
3 不再需要自己持有的对象时必须释放
4 自己不持有的对象无法释放

ARC

ARC 会在编译期添加合适的内存管理的相关代码,但从本质上讲,它与 MRC 还是无异。

1. 自己生成的对象自己持有

首先,在 ARC 中引入了__strong 修饰符(下文还会提到),是所有 id 类型和对象类型默认的修饰符,以下两条语句是等价的:

{
  id obj = [[NSObject alloc] init];
  // id __strong obj = [[NSObject alloc] init];
}

当 obj 出了作用域之后,对 NSObject 对象的强引用消失,该对象则被自动销毁。以上代码在 MRC 中相当于:

{
  id obj = [[NSObject alloc] init];
  [obj release];
}

上个例子是针对内存管理的第一条规则,自己生成并持有的对象,在 ARC 模式下自动被释放。

2. 非自己生成的对象,自己也能持有
// ARC 模式下:
@autoreleasepool {
  Person *p1 = [Person object];
  ...
}

+ (instancetype)object {
  Person *p = [[self alloc] init];
  return p;
}

ARC 会自动在 return p 之前插入 [p autorelease]。p1 默认具有强引用,当出了 autoreleasepool 的作用域之后,p1 的强引用失效,该对象被释放。以上代码应该等价于 MRC 模式下的以下代码:

@autoreleasepool {
  Person *p1 = [Person object];
  [p1 retain];
  ...
  [p1 release];
}

+ (instancetype)object {
  Person *p = [[self alloc] init];
  [p autorelease];
  return p;
}

3. __weak 修饰符和 __strong 修饰符

有以下代码:

Person *__weak p1;
NSLog(@"%@", p1);
@autoreleasepool {
  Person *p2 = [Person object];
  p1 = p2;
  NSLog(@"%@", p1);
}
NSLog(@"%@", p1);

运行以上代码可以发现,当 p1 弱引用的对象被销毁后,p1 被自动置为 nil。但是反观 __strong 修饰符:

Person *p1;
@autoreleasepool {
  p1 = [Person object];
  NSLog(@"%@", p1);
}
NSLog(@"%@", p1);

p1 对 Person 对象是具有强引用的,在第二次 NSLog(p1) 的时候,p1 的强引用并没有失效,当然是可以继续访问 p1 的。

4. 循环引用

循环引用有两种情况:第一种是对象之间的互相强引用,第二种是对象自身的强引用。

  • 首先是第一种情况,举个李子:
/ Person.h
@interface Person : NSObject
@property (nonatomic, strong) Person *child;
@end
  
// Person.m
@implementation Person

- (void)dealloc {
  NSLog(@"person dealloc");
}
- (instancetype)init {
  self = [super init];
  if (self) {
  }
  return self;
}
@end
  
// main.m
int main(int argc, const char * argv[]) {
  @autoreleasepool {
    Person *p1 = [[Person alloc] init];
    Person *p2 = [[Person alloc] init];  
    p1.child = p2;
    p2.child = p1;
  }
  return 0;
}

我们看到 p1.child 强引用了 p2,而 p2.child 强引用了 p1,这样就造成了循环引用,运行之后是不会打印出 person dealloc 信息的。但是这个情况完全可以主动断开这个循环强引用,比如将 p1.child 置为 nil,因为我们很明确这里存在循环引用。

  • 接下来是第二种情况,自身强引用:
// main.m
int main(int argc, const char * argv[]) {
  @autoreleasepool {
    Person *p1 = [[Person alloc] init]; 
    p1.child = p1;
  }
  return 0;
}

同样只要 p1.child = nil 即可。

以上的例子还是很直观的,主动断开循环引用不会有什么问题,不过更普遍的方法应该是使用 weak 修饰符,比如写 delegate 的时候就会这样写:

@property (nonatomic, weak) id<SomeDelegate> delegate;

提到 delegate,有一点,在 MRC 时代,delegate 是使用 assign 修饰的。那时候需要在 dealloc 中将 delegate 置空,不然会存在悬空指针,而现在使用 weak 会自动赋值为 nil。

MRC

1. 自己生成的对象自己持有

如果调用的方法以 alloc、new、copy、mutableCopy 等开头,则生成的对象自己持有。自己是谁?自己就是该方法的使用者。
以下是栗子:

{
  Person *p1 = [[Person alloc] init];
  ...
  [p1 release];
}

通过 alloc 生成的对象,被 p1 持有,当 p1 不再需要持有该对象时则释放它。如果不释放它,出了作用域就再也访问不到该对象了,也就造成了内存泄漏。

2. 非自己生成的对象,自己也能持有

除了上述提到的四种前缀,通过其他方法创建的对象,都不被自己所持有。

假定 Person 类中有以下方法:

+ (instancetype)object {
  id p = [[Person alloc] init];
  return p;
}

根据命名规则,object 的语义是使用者取得该对象,但不持有。所以使用者会这样调用该方法:

Person *p1 = [Person object];
// 一句话结束,因为使用者认为我不持有该对象,何必release

但我们看到 object 方法中的代码可以发现,p1 其实是持有了该对象(后文有一个 allocObject 方法就是这样),这样一来就造成了内存泄漏。

那好,在 return p 之前加上 [p release] 呢,如果是这样的话 return p 真的是有个p用。

我自己曾经这样想,那我可以在方法外释放呀。因为我忽略了一点,这种方法一般都是对使用者隐藏细节的,所以除了我只有鬼会像下面这样写。

Person *p = [Person object];
[p release];

那么正确的 object 方法应该是这样的:

+ (instancetype)object {
  id p = [[Person alloc] init];
  [p autoreleasepool];
  return p;
}

将 p 注册到自动释放池,一旦自动释放池的作用域结束 p 也就释放了。

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
Person *p = [Person object];
[pool drain];
// Person对象被释放

回顾下第一条规则,再举个栗子,如果有一个 allocObject 方法:

+ (instancetype)allocObject {
  id p = [[Person alloc] init];
  return p;
}

在这个方法中没有使用 [p autoreleasepool],因为根据命名规则,allocObject 方法表述的意思是,我创建该对象并持有它。所以使用者会 Person *p = [Person allocObject] 创建对象,当不再需要它的时候 [p release]。

总结一句话:如果调用的方法以 alloc、new、copy、mutableCopy 为前缀,则持有该对象,调用其他的方法不持有该对象,而是将其注册到 autoreleasepool。

3. 不再需要自己持有的对象时必须释放

NSObject 类中有一个 dealloc 方法,当对象的引用计数为0时,该方法会自动被调用,用于释放该对象的内存。如果重写该方法,必须在最后写上 [super dealloc]。

除了上文说到的自己生成并持有的对象需要自己释放,还有另一个栗子:

Person *p = [Person object];
// 根据之前的代码,p 不持有 Person 对象
[p retain];
// p 持有该对象了
[p release];
// 释放对象
4. 自己不持有的对象无法释放
Person *p = [[Person alloc] init];
[p release];
[p release];

第一次 release 的时候已经不持有该对象了,第二次也就没啥用。

从书上看到说这样会造成程序崩溃,但是好像并没有,只有控制台输出了一句话:重复 release。

另一个栗子:

@autoreleasepool {
  Person *p1 = [Person object];
  [p1 release];
}

按照道理来说,p1 不持有对象,应该不能调用 release 才对,可是上面的代码运行起来也没什么错误。

5. 关于 AutoreleasePool

AutoreleasePool 可以起到一种延时销毁的作用,当 AutoreleasePool 的作用域结束之后,在 AutoreleasePool 中注册的对象会收到 release 的消息,随后将对象销毁。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,163评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,301评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,089评论 0 352
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,093评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,110评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,079评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,005评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,840评论 0 273
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,278评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,497评论 2 332
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,667评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,394评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,980评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,628评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,796评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,649评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,548评论 2 352

推荐阅读更多精彩内容