retain cycle(保留环)

IOS中的block和retain cycle (经典)

retain cycle 的产生

说到retain cycle,首先要提一下Objective-C的内存管理机制。

作为C语言的超集,Objective-C延续了C语言中手动管理内存的方式,但是区别于C++的极其非人道的内存管理,Objective-C提出了一些机制来减少内存管理的难度。 比如:内存计数。

在Objective-C中,凡是继承自NSObject的类都提供了两种方法,retain和release。当我们调用一个对象的retain

时,这个对象的内存计数加1,反之,当我们调用release时,

对象的内存计数减1,只有当对象内存计数为0时,这个对象才真正会被释放,此时,对象的delloc方法会被调用来做些内存回收前的工作。

内存计数机制的好处在于我们可以明确分配一个使用权。比如,当一个对象A要使用另外一个对象B的时候,A会retain

B一次以表示A使用B,而当B被使用完毕之后,A会

调用B的release方法来放弃使用权。这样,一个对象可以被多个其他对象使用。而作为使用它的对象,也不必关心自己之外

被使用对象的使用情况(内存方面)。一般来讲,对于类的成员变量,retain和release分别发生在赋值和自身释放的时候,这就是Obj-C程序中

的经典写法:

头文件中:

@property (nonatomic,retain) NSObject *obj;

在.m文件里:

  • (void)dealloc{

[obj release];

[super dealloc];

}

OK,这种方式可以很容易地管理内存,但是仍存在这一个问题,这就是retain cycle。

Retain cycle,翻译成中文大概叫保留环吧。既然父对象持有子对象,而子对象会随父对象释放而释放,那么,如果两个对象相互为父对象怎么办?

比如A和B两个对象,A持有B,B同时也持有A,按照上面的规则,A只有B释放之后才有可能释放,同样B只有A释放后才可能释放,当双方都在等待对方释放的时候, retain cycle就形成了,结果是,两个对象都永远不会被释放,最终内存泄露。

retain cycle使你编程的时候不得不注意一些问题。例如,要么尽量保持子对象引用父对象的时候使用弱引用,也就是assign,比如

@property (nonatomic,assign) NSObject *parent;

要么及时地将造成retain cycle中的一个变量设置为nil,将环break掉。如果注意点,这并不是什么特别大的问题。

嗯,注意点确实不是什么问题,但是当IOS 4.0只后,block的出现,使你更需要更为谨慎。

block与内存管理

block就是一段可以灵活使用的代码,你可以把它当变量传递,赋值,甚至可以把它声明到函数体里,更灵活的是你可以在里面引用外部的环境。

最后一条使得block要有更多的考虑,既然block可以引用外部环境,那如何保证block被调用的时候当时的环境变量不被释放呢?(block调用

的时机可能是随意的)

答案就是,被block引用的变量都会被自动retain一次,这样的话至少可以保证我们的调用是有效的。

说到这里你能想到什么吗?对,还是retain cycle。因为block中的retain是隐式的,所以极易出现retain cycle的问题。

因为block本身也可以看做一个对象,也存在生命周期,也可以被持有,所以当这种情况出现的时候,我们该注意了,比如:

DoSomethingManager *manager = [[DoSomethingManager alloc] init];

manager.complete = ^{

//...complete actions

[manager otherAction];

[manager release];

};

retain cycle 就这么形成了,即使调用了release,manager也不会释放,因为manager和block相互持有了。为了解除retain cycle的话,我们可以这样写:

DoSomethingManager *manager = [[DoSomethingManager alloc] init];

manager.complete = ^{

//...complete actions

[manager otherAction];

manager.complete = nil;

[manager release];

};

manager的complete被设置为nil,如此一来retain cycle也被破坏掉,前提是你确实不需要再次回调block了。

本来写到这里就算完了,但是新世纪总有新的挑战,这就在于在Apple有推出了一种新的技术 ARC。

ARC 和 retain cycle

ARC (Auto Reference Counting),

翻译为自动引用计数,是Apple为了进一步简化内存管理来推出的技术。虽然为自动内存管理而生,但却并算不上真正的自动管理。

这是因为ARC是一种编译期的技术,它所做的是自动识别你的代码并转换成retain/release的形式,在这个层面上来看,ARC无非是简化了代码

的书写,并提供了部分性能上的优化, 而并不像Java之类的语言可以完全把垃圾回收抛之脑后(基本上)。关于ARC的细节可以看下面的网址:

http://developer.apple.com/library/ios/#releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html

下面我们主要谈下ARC下retain cycle的问题。

ARC中,变量可以用三个关键字修饰:

__strong: 赋值给这个变量的对象会自动被retain一次,如果在block中引用它,block也会retain它一次。__unsafe_unretained: 赋值给这个变量不会被retain,也就是说被他修饰的变量的存在不能保证持有对象的可靠性,它可能已经被释放了,而且留下了一个不安全的指针。不会被block retain。__week:类似于__unsafe_unretained,只是如果所持有的对象被释放后,变量会自动被设置为nil,这样更安全些,不过只在IOS5.0以上的系统支持,同样不会被block retain。

另外我们也可以用__block关键字修饰一个变量,表示这个变量能在block中被修改(值修改,而不是修改对象中的某一个属性,可以理解为修改指针的指向)。会被自动retain。

于其他变量不同的是被__block修饰的变量在块中保存的是变量的地址。(其他为变量的值)

首先,上面的代码你现在可以这么写:

DoSomethingManager *manager = [[DoSomethingManager alloc] init];

manager.complete = ^{

//...complete actions

[manager otherAction];

manager.complete = nil;

};

没什么问题,只是去掉了ARC中禁止的release。

当然,我们也可以这么写。

__block DoSomethingManager *manager = [[DoSomethingManager alloc] init];

manager.complete = ^{

//...complete actions

[manager otherAction];

manager = nil;

};

如果不用ARC,manager不会在block中被retain,但是采用了ARC就有些复杂了。block会retain

manager变量,但是,由于__block变量保存更为底层的变量地址,

因此当此变量被指向其他对象时,block便不对原来的对象负责,引发的结果就是之前对象被release掉,retain cycle被破坏。

或者这么写:

__block DoSomethingManager *manager = [[DoSomethingManager alloc] init];

DoSomethingManager __week *weekmanager = manager;

manager.complete = ^{

//...complete actions

[weekmanager otherAction];

};

上面的__week也可以用__unsafe_unretained替代,但是__week更安全些,虽然它不支持IOS5.0以下的系统。

被__week或者__unsafe_unretained修饰的变量不会被block retain,所以不会形成retain cycle,但是小心,保证你的对象不会在complete之前被释放,否则会得到你意向不到的结果。

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

推荐阅读更多精彩内容