问题现象:
<br />有这样两个方法:
- (ErrorViewType)viewType {
NSNumber *number = objc_getAssociatedObject(self, @selector(viewType));
return [number integerValue];
}
l
- (void)setViewType:(ErrorViewType)viewType {
objc_setAssociatedObject(self, @selector(viewType),@(viewType), OBJC_ASSOCIATION_ASSIGN) ;
}
其中ErrorViewType
为枚举变量类型NSUInteger,值为0-14
有这样两个方法,某一次setViewType
传入的值为14,但是在之后某次get的时候直接崩了。报的错误是EXC_BAD_ACCESS
,即野指针访问,那么这个对象又是什么时候被释放,又为什么被释放了呢?
写了一个简单的Demo在32bit真机上验证了一下,iPhone4s,iOS7系统:
可见当被关联的对象NSNumer的值为13的时候,在下一轮runloop去访问这个对象会引发野指针访问:
编译器的代码大概是,通过rewrite以及汇编代码整理:
id tmp1 = _objc_retainAutoreleasedReturnValue([NSNumber numberWithInt:13]);//ARC环境下对于autorelease对象的优化 这个时候tmp1指向的对象retainCount为1
_objc_setAssociatedObject(self,_SEL(testMagicNumber),tmp1,0);
_objc_release(temp1);//因为temp是作为一个入参压栈的,这里出了上面方法的作用域就会被释放
id tmp2 = _objc_retainAutoreleasedReturnValue(_objc_getAssociatedObject(self,_SEL(testMagicNumber)));
objc_storeStrong(&tmp2,nil);//release temp2指向的对象,并且把temp2指向nil
其中对于ARC下对autorelease对象的优化可以参考我上一篇博客:
ARC环境下编译器到底对autorelease对象做了怎样的优化
可见temp1指向的对象在_objc_setAssociatedObject
方法调用结束之后就立即被释放了,而对于关联对象的修饰符又是assign,没有被强引用,所以最后temp1指向的对象release1次引用计数就变成了0,也就随即被释放了。所以下一轮runloop访问的时候就引发野指针访问的崩溃了。在当前runloop访问的话也会崩溃,但是如果把上面的set和get方法抽出来之后现象有点诡异,这个待会说。
然后我们把NSNumer的值改为12之后,一切正常, 这其中有什么猫腻呢。
http://stackoverflow.com/questions/2533355/nsnumber-13-wont-retain-everything-else-will
上面这个回答里有提到,NSNumber在32bit设备之上0-12都是存在内存共享区,类似于[NSArray array]无论调用多少次指针指向的都是相同的一块内存区域,永远不会被销毁。而只要大于12就是正常的创建在堆上的对象。为了验证这个问题,再写个Demo,还是4s真机测试:
果然,验证了猜想,在iPhone5 iOS10系统上同样的现象。
同时也发现了一个有意思的现象:
将get操作封装在一个方法中,不会崩溃。这个原因暂时没想通,但是只要点了Xcode的停止按钮,还是会提示有Crash
在get操作之后再打印一下取到的对象,这种case下就会崩溃,然后取到的对象居然是@(20),也就是虽然@(14)被释放了,但是在他的内存区域由重新new了一个@(20)的对象,鸠占鹊巢,@(20)这个对象被释放之后20这个值还是存在的,所以还能够打印出来,但是因为执行的对象以及被销毁,所以再对其调用release方法就自然会报double free的错误了。
这里到底为什么,一块内存被销毁之后内存中到底是如何标记的,抛砖引玉一下,欢迎大神指导~
那么对于64bit的设备呢?
可见无论NSInterger
保存的这个数有多大,只要在正常范围之内,一定是存放在常量区的,也就是永远不会释放。
可见,是系统在32bit设备上对NSNumber
类型的对象做的优化不够彻底,然后我们在使用关联对象时内存修饰符又使用不当,造成了崩溃的问题。猜测对于32bit的设备,同时存在大量的共享内存会比较消耗资源,因此只对0-12这少数的几个数做了优化,而出问题时候我们传入的参数刚好是14,所以就掉进了坑里。
解决办法及结论
将OBJC_ASSOCIATION_ASSIGN
改为OBJC_ASSOCIATION_RETAIN
,这样在本对象有一个强引用,这个被关联的对象也就不会释放,生命周期也和本对象相同了。我认为既然关联对象传入的都是对象,那么其实绝大多时候用的都应该是是OBJC_ASSOCIATION_RETAIN
,在我们项目中传入的对象很多是NSNumber类型(包装的bool或则int)的时候都是用的OBJC_ASSOCIATION_ASSIGN,以前没暴露问题也是误打误撞错进错出。所以除了一些需要破解循环引用的场景,关联对象的内存操作修饰符建议都用OBJC_ASSOCIATION_RETAIN
。