问题现象：
<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系统：
crash截图.png
可见当被关联的对象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真机测试：
32bit magic number test
果然，验证了猜想，在iPhone5 iOS10系统上同样的现象。
同时也发现了一个有意思的现象：
封装get方法之后不会崩溃.png
将get操作封装在一个方法中，不会崩溃。这个原因暂时没想通，但是只要点了Xcode的停止按钮，还是会提示有Crash
奇葩的崩溃
在get操作之后再打印一下取到的对象，这种case下就会崩溃，然后取到的对象居然是@(20)，也就是虽然@(14)被释放了，但是在他的内存区域由重新new了一个@(20)的对象，鸠占鹊巢，@(20)这个对象被释放之后20这个值还是存在的，所以还能够打印出来，但是因为执行的对象以及被销毁，所以再对其调用release方法就自然会报double free的错误了。
这里到底为什么，一块内存被销毁之后内存中到底是如何标记的，抛砖引玉一下，欢迎大神指导~
那么对于64bit的设备呢？
64bit magic number test1.png
64bit magic number test2.png
可见无论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。
网友评论