绝大部分 objective-c 程序员使用属性时，都不太关注一个特殊的修饰前缀，一般都无脑的使用其非默认缺省的状态，他就是 atomic。
@interface propertyclass @property (atomic, strong) nsobject *atomicobj; //缺省也是atomic @property (nonatomic, strong) nsobject *nonatomicobj; @end
入门教程中一般都建议使用非原子操作，因为新手大部分操作都在主线程，用不到线程安全的特性，大量使用还会降低执行效率。
那他到底怎么实现线程安全的呢？使用了哪种技术呢？
首先我们研究一下属性包含的内容。通过查阅源码，其结构如下：
我要评论struct property_t {
const char *name; //名字
const char *attributes; //特性
};
属性的结构比较简单，包含了固定的名字和元素，可以通过 property_getname 获取属性名，property_getattributes 获取特性。
上例中 atomicobj 的特性为 t@"nsobject",&,v_atomicobj，其中 v 代表了 strong，atomic 特性缺省没有显示，如果是 nonatomic 则显示 n。
那到底是怎么实现原子操作的呢？ 通过引入runtime，我们能调试一下调用的函数栈。
可以看到在编译时就把属性特性考虑进去了，setter 方法直接调用了 objc_setproperty 的 atomic 版本。这里不用 runtime 去动态分析特性，应该是对执行性能的考虑。
static inline void reallysetproperty(id self, sel _cmd,
id newvalue, ptrdiff_t offset, bool atomic, bool copy, bool mutablecopy) {
//偏移为0说明改的是isa
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);
}
id objc_getproperty(id self, sel _cmd, ptrdiff_t offset, bool atomic) {
// 取isa
if (offset == 0) {
return object_getclass(self);
}
// 非原子操作直接返回
id *slot = (id*) ((char*)self + offset);
if (!atomic) return *slot;
// 原子操作自旋锁
spinlock_t& slotlock = propertylocks[slot];
slotlock.lock();
id value = objc_retain(*slot);
slotlock.unlock();
// 出于性能考虑，在锁之外autorelease
return objc_autoreleasereturnvalue(value);
}
锁用于解决线程争夺资源的问题，一般分为两种，自旋锁(spin)和互斥锁(mutex)。
互斥锁可以解释为线程获取锁，发现锁被占用，就向系统申请锁空闲时唤醒他并立刻休眠。
自旋锁比较简单，当线程发现锁被占用时，会不断循环判断锁的状态，直到获取。
原子操作的颗粒度最小，只限于读写，对于性能的要求很高，如果使用了互斥锁势必在切换线程上耗费大量资源。相比之下，由于读写操作耗时比较小，能够在一个时间片内完成，自旋更适合这个场景。
但是ios 10之后，苹果因为一个巨大的缺陷弃用了 osspinlock 改为新的 os_unfair_lock。
新版 ios 中，系统维护了 5 个不同的线程优先级/qos: background，utility，default，user-initiated，user-interactive。高优先级线程始终会在低优先级线程前执行，一个线程不会受到比它更低优先级线程的干扰。这种线程调度算法会产生潜在的优先级反转问题，从而破坏了 spin lock。
描述引用自 ibireme 大神的文章。
我的理解是，当低优先级线程获取了锁，高优先级线程访问时陷入忙等状态，由于是循环调用，所以占用了系统调度资源，导致低优先级线程迟迟不能处理资源并释放锁，导致陷入死锁。
那为什么原子操作用的还是 spinlock_t 呢？
using spinlock_t = mutex_tt<lockdebug>;
using mutex_t = mutex_tt<lockdebug>;
class mutex_tt : nocopy_t {
os_unfair_lock mlock; //处理了优先级的互斥锁
void lock() {
lockdebug_mutex_lock(this);
os_unfair_lock_lock_with_options_inline
(&mlock, os_unfair_lock_data_synchronization);
}
void unlock() {
lockdebug_mutex_unlock(this);
os_unfair_lock_unlock_inline(&mlock);
}
}
差点被苹果骗了！原来系统中自旋锁已经全部改为互斥锁实现了，只是名称一直没有更改。
为了修复优先级反转的问题，苹果也只能放弃使用自旋锁，改用优化了性能的 os_unfair_lock，实际测试两者的效率差不多。
使用atomic 修饰属性，编译器会设置默认读写方法为原子读写，并使用互斥锁添加保护。
单独的原子操作绝对是线程安全的，但是组合一起的操作就不能保证。
- (void)competition {
self.intsource = 0;
dispatch_async(queue1, ^{
for (int i = 0; i < 10000; i++) {
self.intsource = self.intsource + 1;
}
});
dispatch_async(queue2, ^{
for (int i = 0; i < 10000; i++) {
self.intsource = self.intsource + 1;
}
});
}
最终得到的结果肯定小于20000。当获取值的时候都是原子线程安全操作，比如两个线程依序获取了当前值 0，于是分别增量后变为了 1，所以两个队列依序写入值都是 1，所以不是线程安全的。
解决的办法应该是增加颗粒度，将读写两个操作合并为一个原子操作，从而解决写入过期数据的问题。
os_unfair_lock_t unfairlock;
- (void)competition {
self.intsource = 0;
unfairlock = &(os_unfair_lock_init);
dispatch_async(queue1, ^{
for (int i = 0; i < 10000; i++) {
os_unfair_lock_lock(unfairlock);
self.intsource = self.intsource + 1;
os_unfair_lock_unlock(unfairlock);
}
});
dispatch_async(queue2, ^{
for (int i = 0; i < 10000; i++) {
os_unfair_lock_lock(unfairlock);
self.intsource = self.intsource + 1;
os_unfair_lock_unlock(unfairlock);
}
});
}
通过学习属性的原子性，对系统中锁的理解又加深，包括自旋锁，互斥锁，读写锁等。
本来都以为实现是自旋锁了，还好留了个心眼多看了一层才发现最终实现还是互斥锁。这件事也给我一个小教训，查阅源码还是要刨根问底，只浮于表面的话，可能得不到想要的真相。
如对本文有疑问， 点击进行留言回复！！
网友评论