关于引用计数的小问题

引用计数(retainCount)是iOS系统中用来管理对象生命周期的标识,当对象的引用计数大于0则表示该对象还有生命,没有被系统回收,自然,当引用计数等于0的时候,表示没有了生命,它所指的空间就被系统回收了。这是iOS中的常识,具体的其他知识点我就不用过多说明了,网上到处都是。

第一小点,关于常量字符串的引用计数。直接上图:


是不是有点惊讶,按照正常的理解,他仨的retainCount应该都是1才对,但是string1和string2的retainCount打印出来是一个随机数,且他俩的retainCount相等,只有mustring3的retainCount是1。为什么会是这样呢?从指针输出地址我们可以看到,string1和string2的指针地址是不一样的,但是他俩指向的地址是同一个,也就是字符串@“xyz”的地址,这是一个字符串常量。我们知道程序运行起来后内存区域里有一块常量区,顾名思义专门用来存放常量的,且这些常量是公用的,生命周期跟进程一样,程序退出时才会被系统一起回收,我们也无法改变他们。在一次进程中,他们的地址不会变,他们的引用计数一直会是一个非0的随机正整数,且这个retainCount在进程生命周期中,一直保持不变,而string1和string2又是不可变字符串,所以就出现了图中的现象。

那为什么mustring3又是另一种情况呢,我们也是用@“xyz”来初始化的啊。这是因为mustring3本身是可变的,即使你用的@“xyz”进行初始化,但是mustring3随时可以改变(移除或者拼接),所以系统并不会把mustring3指向一块常量内存区域,那么mustring3指向的内存区域自然就跟@“xyz”所处的内存区域不是同一块。且就这里来说,常量@“xyz”所处区域属于常量区,mustring3所指向的区域是临时开辟的,处在栈区。


第二小点,关于局部变量释放时机问题。还是先看图:


我先在viewDidLoad里面声明了局部变量arr,并用一个全局弱引用指针selfArray指向arr,这么做只是为了后续能获取到,我们知道弱引用是不会改变arr的引用计数的,所以这个不会影响arr的生命周期。按照我们平时的默认理解,出了viewDidLoad后arr局部变量就会被释放,那么在后续的viewWillAppear和viewDidAppear里面应该都是nil,但是打印结果我们看到了,并没有被立马释放。他是在viewWillAppear到viewDidAppear这个过程中的某个时间点被释放回收了。为什么会这样呢?因为自动释放池。我们知道系统会自己去创建一些autoreleasepool,并把一些局部变量以及那些标记为autorelease的变量放入最近的自动释放池。那系统为什么要提供自动释放池这个东西呢?为什么不能让变量出了这个作用域就立马释放呢?因为释放回收也是需要消耗系统资源的,自动释放池就是让系统能够智能地选择一个合适的时间,可以理解为某个系统不忙的时间点一起去释放。autoreleasepool其实是一个以autoreleasepoolpage为节点的双向链表。具体有关autoreleasepool的细节可以移步这里iOS AutoreleasePool 深入探究 - 简书。所以这里是因为系统的自动释放池延迟了局部变量的释放时间。我们可以自己写个自动释放池验证一下,看图:


这次我们看到arr出了autoreleasepool范围就被释放了。所以我们在大量次循环内部(注意是循环内部)要使用autoreleasepool包裹,防止内存暴涨。


第三小点,关于retainCount是否会增加问题。还是先看图:


这五种操作哪种会立马改变arr的retainCount?

第一个输出是1,这大家没异议。retain就不用说了,所以第二个输出2。那么copy之后呢?有同学乍一看,觉得copy这个词就给人感觉就是要加1。如果我告诉你copy只是复制出一份新的,对原来的没有影响呢,这个时候你可能又会觉得不会加1。我就不卖关子了,这里的copy是浅拷贝,(关于深浅拷贝问题移步这里浅拷贝,深拷贝以及全拷贝 - 简书)只是指针复制,复制出来的指针还是指向原来的那块内存地址,所以会加1,如果是深拷贝那自然就不会加1,可自证。所以第三个输出3。第四个和第五个都不会增加retainCount,跟__strong和__autoreleasing没什么关系,我猜有同学会想是不是arr2和arr3被立马释放了,我开始也有这个疑问,所以我特意打印的arr2和arr3的内容,可以看到他们并没有被释放。这里不会加1是因为arr2和arr3就相当于给arr取了个别名,这两个别名并没有被谁强拥有,所以不加1。所以第四个和第五个都输出3,第六个self.strongArr = arr;  strongArr是我定义一个全局的strong属性,所以这里自然会加1,所以第六个输出4,这也可以说明第四个和第五个为什么不加1。下面是输出结果:

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

推荐阅读更多精彩内容