问题：使用atomic一定是线程安全的吗？

atomic不是绝对的线程安全。atomic的本意是指属性的存取方法是线程安全的，并不保证整个对象是线程安全的。

网上常见的关于atomic非线程安全的举例：如果线程 A 调了 getter，与此同时线程 B 、线程 C 都调了 setter——那最后线程 A get 到的值，有3种可能：可能是 B、C set 之前原始的值，也可能是 B set 的值，也可能是 C set 的值。同时，最终这个属性的值，可能是 B set 的值，也有可能是 C set 的值。所以atomic可并不能保证对象的线程安全。

类似的这个例子相信很多人都见过，看起来也非常合理，没什么错；但细琢磨，这个例子本身没问题，但并不能证明atomic的非线程安全这个观点，它只说明了不确定哪个线程先调用了set。所以面试的时候如果举这个例子~~说明你没明白atomic的非线程安全性！

首先你得知道什么是线程不安全？线程的不安全是由于多线程访问和修改共享资源而引起的不可预测的结果(有可能crash)。可以简单理解为我们拿到的值是错的。这个例子中，如果线程A getter到的值是个错误的值才能说是线程不安全的，可是这个例子就算线程A可能取到好几种值，你能说取值不对吗；不能。所以这个例子是个错误的例子！*误导了我好久；下文中我会举两个正确的例子。

atomic的原子性和nonatomic的非原子性

atomic ：系统自动生成的getter/setter方法会进行加锁操作；可以理解过读写锁，可以保证读写安全；较耗时。
nonatomic：系统自动生成的getter/setter方法不会进行加锁操作；但速度会更快。

源代码分析atomic为什么不是线程安全

为什么要把atomic和线程安全联系在一起去探究？这个问题本身其实就很奇怪，atomic只是对属性的getter/setter方法进行了加锁操作，这种安全仅仅是get/set的读写安全，仅此而已，但是线程安全还有除了读写的其他操作，比如：当一个线程正在get/set时，另一个线程同时进行release操作，可能会直接crash。很明显atomic的读写锁不能保证线程安全。下面两个例子写的就挺好，挺简单：

例子一：如果定义属性NSInteger i是原子的，对i进行i = i + 1操作就是不安全的；因为原子性只能保证读写安全，而该表达式需要三步操作：
1、读取i的值存入寄存器；
2、将i加1；
3、修改i的值；
如果在第一步完成的时候，i被其他线程修改了，那么表达式执行的结果就与预期的不一样，也就是不安全的。

例子二：
   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替换：

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
        .
        .
        .