开文首先我要纠正一个网上常见的关于atomic非线程安全的举例:若是线程 A 调了 getter,与此同时线程 B 、线程 C 都调了 setter——那最后线程 A get 到的值,有3种可能:多是 B、C set 以前原始的值,也多是 B set 的值,也多是 C set 的值。同时,最终这个属性的值,多是 B set 的值,也有多是 C set 的值。因此atomic可并不能保证对象的线程安全。面试
相似的这个例子相信不少人都见过,看起来也很是合理,没什么错;但细琢磨,这个例子自己没问题,但根本不能证实atomic的非线程安全这个观点!因此面试的时候若是举这个例子~~说明你就没明白atomic的非线程安全性!安全
下面是两个nonatomic和atomic修饰的变量,咱们用代码掩饰其内部实现;bash
@property (nonatomic) UIImage *nonImage;
@property (atomic) UIImage *atomicImage;
//nonatomic的setter和getter实现:
- (void)setNonImage:(UIImage *)nonImage
{
_nonImage = nonImage;
}
- (UIImage *)nonImage
{
return _nonImage;
}
//atomic的setter和getter实现:
- (void)setAtomicImage:(UIImage *)atomicImage
{
@synchronized (self) {
_atomicImage = atomicImage;
}
}
- (UIImage *)atomicImage
{
@synchronized (self) {
return _atomicImage;
}
}
复制代码
其实如今一想很奇怪,为何要把atomic和线程安全联系在一块儿去探究;atomic只是对属性的getter/setter方法进行了加锁操做,这种安全仅仅是get/set的读写安全,仅此之一,可是线程安全还有除了读写的其余操做,好比:当一个线程正在get/set时,另外一个线程同时进行release操做,可能会直接crash。很明显atomic的读写锁不能保证线程安全。 下面两个例子写的就挺好,挺简单:\多线程
eg1:若是定义属性NSInteger i是原子的,对i进行i = i + 1操做就是不安全的; 由于原子性只能保证读写安全,而该表达式须要三步操做:
一、读取i的值存入寄存器;
二、将i加1;
三、修改i的值;
若是在第一步完成的时候,i被其余线程修改了,那么表达式执行的结果就与预期的不同,也就是不安全的 eg2:async
self.slice = 0;
dispatch_queue_t queue = dispatch_queue_create("TestQueue", DISPATCH_QUEUE_CONCURRENT);
dispatch_async(queue, ^{
for (int i=0; i<10000; i++) {
self.slice = self.slice + 1;
}
});
dispatch_async(queue, ^{
for (int i=0; i<10000; i++) {
self.slice = self.slice + 1;
}
});
复制代码
结果多是[10000,20000]之间的某个值,而咱们想要的结果是20000;很明显这个例子就会引发线程隐患,而atomic并不能防止这个问题;因此咱们说atomic不是线程安全;
因此要想真正理解atomic的非线程安全性,必需要去官网查找解释并经过源码分析才行; 在runtime时property的atomic是一个booleau值,是采用spinlock_t锁去实现的;源码分析
id objc_getProperty(id self, SEL _cmd, ptrdiff_t offset, BOOL atomic) {
if (offset == 0) {
return object_getClass(self);
}
// Retain release world
id *slot = (id*) ((char*)self + offset);
if (!atomic) return *slot;
// Atomic retain release world
spinlock_t& slotlock = PropertyLocks[slot];
slotlock.lock();
id value = objc_retain(*slot);
slotlock.unlock();
// for performance, we (safely) issue the autorelease OUTSIDE of the spinlock.
return objc_autoreleaseReturnValue(value);
}
static inline void reallySetProperty(id self, SEL _cmd, id newValue, ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
if (offset == 0) {
object_setClass(self, newValue);
return;
}
id oldValue;
id *slot = (id*) ((char*)self + offset);
if (copy) {
newValue = [newValue copyWithZone:nil];
} else if (mutableCopy) {
newValue = [newValue mutableCopyWithZone:nil];
} else {
if (*slot == newValue) return;
newValue = objc_retain(newValue);
}
if (!atomic) {
oldValue = *slot;
*slot = newValue;
} else {
spinlock_t& slotlock = PropertyLocks[slot];
slotlock.lock();
oldValue = *slot;
*slot = newValue;
slotlock.unlock();
}
objc_release(oldValue);
}
复制代码
很明显atomic属性的setter/getter方法都被加了spinlock自旋锁,须要注意的是spinlock已经因为存在优先级反转问题被弃用并用os_unfair_lock替代。既然被弃用了,这里为何还在用;缘由是进入spinlock去看会发现,底层已经被os_unfair_lick替换:ui
using spinlock_t = mutex_tt<LOCKDEBUG>;
class mutex_tt : nocopy_t {
os_unfair_lock mLock;
public:
constexpr mutex_tt() : mLock(OS_UNFAIR_LOCK_INIT) {
lockdebug_remember_mutex(this);
}
constexpr mutex_tt(const fork_unsafe_lock_t unsafe) : mLock(OS_UNFAIR_LOCK_INIT) { }
void lock() {
lockdebug_mutex_lock(this);
os_unfair_lock_lock_with_options_inline
.
.
.
复制代码