多線程訪問同一個對象，經(jīng)常會出現(xiàn)意料之外的結(jié)果。
這里就從atomic與nonatomic講起。
atomic
atomic能從一定程度上保證線程安全，但是大部分的情況下并沒不能完全保證線程安全。
首先我們看看如果將一個屬性設(shè)置為atomic的時候，編譯器幫我們做了什么？
- 生成原子操作的getter和setter方法
當(dāng)線程A執(zhí)行setter方法時，線程B如果需要執(zhí)行g(shù)etter方法必須等線程ASetter方法結(jié)束后才能執(zhí)行。
atomic內(nèi)部實現(xiàn)：
// setter
static inline void reallySetProperty(id self, SEL _cmd, id newValue, ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
// ...
if (!atomic) {
oldValue = *slot;
*slot = newValue;
} else {
spinlock_t& slotlock = PropertyLocks[slot];
slotlock.lock();
oldValue = *slot;
*slot = newValue;
slotlock.unlock();
}
// ...
}
// getter
id objc_getProperty(id self, SEL _cmd, ptrdiff_t offset, BOOL atomic) {
// ...
if (!atomic) return *slot;
// Atomic retain release world
spinlock_t& slotlock = PropertyLocks[slot];
slotlock.lock();
id value = objc_retain(*slot);
slotlock.unlock();
// ...
}
對于沒法在CPU一次讀寫操作中完成的setter和getter方法，就需要考慮其在多線程中的安全性，否則可能導(dǎo)致crash。
系統(tǒng)是通過自旋鎖的方式來保證CPU多次讀寫的執(zhí)行順序。
比如32位的系統(tǒng)中：
一個Bool值占1字節(jié)，可以在一次讀寫操作中完成賦值或取值，因此是線程安全的。
一個指針占4字節(jié)，也可以在一次讀寫操作中完成賦值或取值，因此是線程安全的。
一個double占8字節(jié)，則需要兩次讀寫操作才能完成賦值或取值，因此就會存在一個寫操作(需兩次寫操作才能完成)，之后就是讀操作的可能，導(dǎo)致異常值的現(xiàn)象。
- 設(shè)置Memory Barrier
對于Objective C的實現(xiàn)來說，幾乎所有的加鎖操作最后都會設(shè)置memory barrier，atomic本質(zhì)上是對getter，setter加了鎖，所以也會設(shè)置memory barrier。
memory barrier能夠保證內(nèi)存操作的順序，按照我們代碼的書寫順序來。聽起來有點不可思議，事實是編譯器會對我們的代碼做優(yōu)化，在它認(rèn)為合理的場景改變我們代碼最終翻譯成的機(jī)器指令順序。也就是說如下代碼：
self.intA = 0; //line 1
self.intB = 1; //line 2
編譯器可能在一些場景下先執(zhí)行l(wèi)ine2，再執(zhí)行l(wèi)ine1，因為它認(rèn)為A和B之間并不存在依賴關(guān)系，雖然在代碼執(zhí)行的時候，在另一個線程intA和intB存在某種依賴，必須要求line1先于line2執(zhí)行。
如果設(shè)置property為atomic，也就是設(shè)置了memory barrier之后，就能夠保證line1的執(zhí)行一定是先于line2的，當(dāng)然這種場景非常罕見，一則是出現(xiàn)變量跨線程訪問依賴，二是遇上編譯器的優(yōu)化，兩個條件缺一不可。這種極端的場景下，atomic確實可以讓我們的代碼更加多線程安全一點，但我寫iOS代碼至今，還未遇到過這種場景，較大的可能性是編譯器已經(jīng)足夠聰明，在我們需要的地方設(shè)置memory barrier了。
nonatomic
大部分情況下，我們會選擇nonatomic作為屬性的attribute，因為它能有效避免線程鎖帶來的性能消耗，而大部分的多線程安全問題也需要我們自己來完成線程安全。
