前言

這里面你將會了解到什么是。

絕大部分 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，我們能調試一下調用的函數棧。

image.png

可以看到在編譯時就把屬性特性考慮進去了，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)。

互斥鎖可以解釋為線程獲取鎖，發現鎖被占用，就向系統申請鎖空閑時喚醒他并立刻休眠。互斥鎖加鎖的時候，等待鎖的線程處于休眠狀態，不會占用CPU的資源

自旋鎖比較簡單，當線程發現鎖被占用時，會不斷循環判斷鎖的狀態，直到獲取。自旋鎖加鎖的時候，等待鎖的線程處于忙等狀態，并且占用著CPU的資源。

原子操作的顆粒度最小，只限于讀寫，對于性能的要求很高，如果使用了互斥鎖勢必在切換線程上耗費大量資源。相比之下，由于讀寫操作耗時比較小，能夠在一個時間片內完成，自旋更適合這個場景。

自旋鎖的坑

但是iOS 10之后，蘋果因為一個巨大的缺陷棄用了 OSSpinLock 改為新的 os_unfair_lock。

新版 iOS 中，系統維護了 5 個不同的線程優先級/QoS: background，utility，default，user-initiated，user-interactive。高優先級線程始終會在低優先級線程前執行，一個線程不會受到比它更低優先級線程的干擾。這種線程調度算法會產生潛在的優先級反轉問題，從而破壞了 spin lock。

描述引用自 ibireme 大神的文章。

新版 iOS 中，系統維護了 5 個不同的線程優先級/QoS: background，utility，default，user-initiated，user-interactive。高優先級線程始終會在低優先級線程前執行，一個線程不會受到比它更低優先級線程的干擾。這種線程調度算法會產生潛在的優先級反轉問題，從而破壞了 spin lock。

具體來說，如果一個低優先級的線程獲得鎖并訪問共享資源，這時一個高優先級的線程也嘗試獲得這個鎖，它會處于 spin lock 的忙等狀態從而占用大量 CPU。此時低優先級線程無法與高優先級線程爭奪 CPU 時間，從而導致任務遲遲完不成、無法釋放 lock。導致陷入死鎖。

這并不只是理論上的問題，libobjc 已經遇到了很多次這個問題了，于是蘋果的工程師停用了 OSSpinLock。iOS10以后，蘋果給出了新的api

那為什么原子操作用的還是 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，實際測試兩者的效率差不多。

os_unfair_lock用于取代不安全的OSSpinLock，從iOS10開始才支持

從底層調用看，等待os_unfair_lock鎖的線程會處于休眠狀態，并非忙等

問答

atomic的實現機制

使用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);
    }
  });
}

總結

通過學習屬性的原子性，對系統中鎖的理解又加深，包括自旋鎖，互斥鎖，讀寫鎖等。

本來都以為實現是自旋鎖了，還好留了個心眼多看了一層才發現最終實現還是互斥鎖。這件事也給我一個小教訓，查閱源碼還是要刨根問底，只浮于表面的話，可能得不到想要的真相。

引用

可以編譯的runtime庫

不再安全的 OSSpinLock