在iOS多線程開發當中，不可避免會遇到數據同步的問題，其中一種解決方案就是經過加鎖來防止兩條線程同時操做同一片內存空間。今天咱們主要來探索一下一種比較常見的鎖@synchronized同步鎖。ios

代碼示例

首先咱們來看一段簡單的代碼，能夠經過xcode轉換爲彙編代碼來看一下@synchronized到底作了什麼。接下來在xcode中對於objc_sync_enter和objc_sync_exit打下符號斷點。能夠看到，@synchronized代碼塊確實調用了上述兩個函數，接下來咱們到源碼中去一探究竟。算法

源碼分析

objc_sync_enter

// Begin synchronizing on 'obj'. 
// Allocates recursive mutex associated with 'obj' if needed.
// Returns OBJC_SYNC_SUCCESS once lock is acquired.  
int objc_sync_enter(id obj)
{
    int result = OBJC_SYNC_SUCCESS;

    if (obj) {
        SyncData* data = id2data(obj, ACQUIRE);
        ASSERT(data);
        data->mutex.lock();
    } else {
        // @synchronized(nil) does nothing
        if (DebugNilSync) {
            _objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");
        }
        objc_sync_nil();
    }

    return result;
}
複製代碼

註釋簡單翻譯以下：數組

開始obj的同步工做，必要時開闢一個關聯着obj的互斥遞歸鎖，當得到鎖以後返回OBJC_SYNC_SUCCESS。xcode

經過註釋咱們就能夠得出這樣一個結論，@synchronized是一個互斥遞歸鎖。緩存

objc_sync_enter主要邏輯以下：markdown

obj不爲空時，獲取SyncData* data，取出data->mutex進行加鎖
obj爲空時，執行obj_sync_nil，經過源碼查看其實什麼也沒有處理。

那麼核心確定就在這個SyncData了：這個結構很容易讓人聯想到鏈表，其中的多線程

接下來看一下獲取data的方法id2dataide

id2data

該方法代碼比較多，一共有160多行，你們能夠打開一份objc的源碼同步觀看。經過上圖大體分爲6個操做，咱們一步一步來解析。函數

操做1

spinlock_t *lockp = &LOCK_FOR_OBJ(object);
SyncData **listp = &LIST_FOR_OBJ(object);
複製代碼

咱們來看一下LOCK_FOR_OBJ和LIST_FOR_OBJ這兩個宏都幹了什麼源碼分析

#define LOCK_FOR_OBJ(obj) sDataLists[obj].lock
#define LIST_FOR_OBJ(obj) sDataLists[obj].data
static StripedMap<SyncList> sDataLists;
複製代碼

簡單看一下StripedMap

template<typename T>
class StripedMap {
#if TARGET_OS_IPHONE && !TARGET_OS_SIMULATOR
    enum { StripeCount = 8 };
#else
    enum { StripeCount = 64 };
#endif
	// 內部有一個T類型的value值
    struct PaddedT {
        T value alignas(CacheLineSize);
    };
	// array來存儲PaddedT
    PaddedT array[StripeCount];
	// 哈希函數
    static unsigned int indexForPointer(const void *p) {
        uintptr_t addr = reinterpret_cast<uintptr_t>(p);
        return ((addr >> 4) ^ (addr >> 9)) % StripeCount;
    }

 public:
    T& operator[] (const void *p) { 
        return array[indexForPointer(p)].value; 
    }
...
複製代碼

StripedMap實際上是一個哈希表，內部是一個容量爲8的數組，存儲T類型的數據，在當前的狀況下，就是SyncList

struct SyncList {
    SyncData *data;
    spinlock_t lock;
    constexpr SyncList() : data(nil), lock(fork_unsafe_lock) { }
};
複製代碼

經過這一步咱們就能夠知道其實上述兩個宏的主要做用就是經過哈希算法得出obj所在的SyncList，進一步取出對應的數組data和spinlock_t鎖。

總結一下操做1的主要工做是經過哈希算法取出咱們須要加鎖的obj所對應的SyncList中的數組以及一把spinlock_t鎖

操做2

#if SUPPORT_DIRECT_THREAD_KEYS
    // Check per-thread single-entry fast cache for matching object
    // 檢查單獨線程的快速緩存
    bool fastCacheOccupied = NO;
    // 經過tls來獲取SyncData
    SyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY);
    if (data) {
        fastCacheOccupied = YES;
	// 校驗取出的data是否和這次的object一致
        if (data->object == object) {
            // Found a match in fast cache.
            uintptr_t lockCount;

            result = data;
            // 獲取當前線程中對於object的加鎖次數，由於是遞歸鎖，因此存在屢次加鎖
            lockCount = (uintptr_t)tls_get_direct(SYNC_COUNT_DIRECT_KEY);
            if (result->threadCount <= 0  ||  lockCount <= 0) {
                _objc_fatal("id2data fastcache is buggy");
            }

            switch(why) {
            case ACQUIRE: {
            // ACQUIRE類型表示新增長了一次鎖
                lockCount++;
                tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
                break;
            }
            case RELEASE:
            // RELEASE表示這次加鎖結束了
                lockCount--;
                tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
                // 0表明當前線程已經沒有針對object加鎖，此時thread_count須要減一
                if (lockCount == 0) {
                    // remove from fast cache
                    tls_set_direct(SYNC_DATA_DIRECT_KEY, NULL);
                    // atomic because may collide with concurrent ACQUIRE
                    OSAtomicDecrement32Barrier(&result->threadCount);
                }
                break;
            case CHECK:
                // do nothing
                break;
            }

            return result;
        }
    }
#endif
複製代碼

上述代碼中已經有對應的註釋，簡單歸納就是從當前線程的本地存儲tls中快速的查找obj對應的SyncData，找到的話根據傳入的參數ACQUIRE/RELEASE選擇相應的操做：修改lockCount以及threadCount，同時更新tls中的值。

操做3

若是tls中沒有找到對應的SyncData，會進入操做3。

// Check per-thread cache of already-owned locks for matching object
// 獲取緩存
    SyncCache *cache = fetch_cache(NO);
    if (cache) {
        unsigned int i;
        for (i = 0; i < cache->used; i++) {
            SyncCacheItem *item = &cache->list[i];
            if (item->data->object != object) continue;
			// 遍歷cache查找object對應的cacheItem
            // Found a match.
            result = item->data;
            if (result->threadCount <= 0  ||  item->lockCount <= 0) {
                _objc_fatal("id2data cache is buggy");
            }
                
            switch(why) {
            case ACQUIRE:
                item->lockCount++;
                break;
            case RELEASE:
                item->lockCount--;
                if (item->lockCount == 0) {
                    // remove from per-thread cache
                    cache->list[i] = cache->list[--cache->used];
                    // atomic because may collide with concurrent ACQUIRE
                    OSAtomicDecrement32Barrier(&result->threadCount);
                }
                break;
            case CHECK:
                // do nothing
                break;
            }

            return result;
        }
    }
複製代碼

順帶看一下SyncCacheItem以及fetch_cache的實現

typedef struct {
    SyncData *data;
    unsigned int lockCount;  // number of times THIS THREAD locked this block
} SyncCacheItem;

static SyncCache *fetch_cache(bool create)
{
    _objc_pthread_data *data;
    
    data = _objc_fetch_pthread_data(create);
    if (!data) return NULL;
	
    if (!data->syncCache) {
        if (!create) {
            return NULL;
        } else {
        	// 默認緩存容量爲4
            int count = 4;
            data->syncCache = (SyncCache *)
                calloc(1, sizeof(SyncCache) + count*sizeof(SyncCacheItem));
            data->syncCache->allocated = count;
        }
    }

    // Make sure there's at least one open slot in the list.
    // 擴容
    if (data->syncCache->allocated == data->syncCache->used) {
        data->syncCache->allocated *= 2;
        data->syncCache = (SyncCache *)
            realloc(data->syncCache, sizeof(SyncCache) 
                    + data->syncCache->allocated * sizeof(SyncCacheItem));
    }

    return data->syncCache;
}
複製代碼

能夠發現，其實和操做2相似，操做3會從SyncCache中取出對應的SyncData，以後進行個操做2相似的處理。

操做4

cache尚未建立

// 加鎖
lockp->lock();

    {
        SyncData* p;
        SyncData* firstUnused = NULL;
        // 在全局的listp鏈表中查找object對應的SyncData
        for (p = *listp; p != NULL; p = p->nextData) {
            if ( p->object == object ) {
                result = p;
                // atomic because may collide with concurrent RELEASE
                // 找到說明當前線程是第一次對object進行加鎖，此時須要threadCount+1
                OSAtomicIncrement32Barrier(&result->threadCount);
                goto done;
            }
            // 若是當前結點的threadCount爲0，即當前結點對應的object沒有一條線程有加鎖操做
            if ( (firstUnused == NULL) && (p->threadCount == 0) )
                firstUnused = p;
        }
    
        // no SyncData currently associated with object
        if ( (why == RELEASE) || (why == CHECK) )
            goto done;
    
        // an unused one was found, use it
        // 若是找到一個沒有用的結點，對結點進行從新初始化，從新賦值
        if ( firstUnused != NULL ) {
            result = firstUnused;
            result->object = (objc_object *)object;
            result->threadCount = 1;
            goto done;
        }
    }
複製代碼

這一步總的來講就是若是緩存都尚未建立，那麼須要從全局的listp鏈表中尋找Syncdata，若是這也沒找到，可是找到了空結點，就對空結點進行賦值。

操做5

// 鏈表中的結點都被佔用，此時只能建立新的結點了
    posix_memalign((void **)&result, alignof(SyncData), sizeof(SyncData));
    result->object = (objc_object *)object;
    result->threadCount = 1;
    new (&result->mutex) recursive_mutex_t(fork_unsafe_lock);
    // 頭插法插入到當前的listp鏈表中
    result->nextData = *listp;
    *listp = result;
複製代碼

緊接着上面的listp查找，若是listp沒有空結點，只能建立新的結點，而後頭插法插入鏈表listp中

操做6

done:
	// 此時object對應的syncdata已經建立完畢，而且存儲完成，對於多線程已經沒有了風險，能夠解鎖了
    lockp->unlock();
    if (result) {
        ...
#if SUPPORT_DIRECT_THREAD_KEYS
	// 若是快速緩存即tls尚未被佔用，存儲快速緩存中
        if (!fastCacheOccupied) {
            // Save in fast thread cache
            tls_set_direct(SYNC_DATA_DIRECT_KEY, result);
            tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)1);
        } else 
#endif
	// 不然存儲到線程的緩存syncCache中
        {
            // Save in thread cache
            // cache不存在的話須要先建立cache
            if (!cache) cache = fetch_cache(YES);
            cache->list[cache->used].data = result;
            cache->list[cache->used].lockCount = 1;
            cache->used++;
        }
    }
    return result;
複製代碼

id2data總結

至此id2data的源碼終於分析完了，總結一下，本質就是一個找object對應的syncData的過程，先從tls即fast cache中找，再從線程的syncCache中找，最後從全局的listp鏈表中找，都找不到的話只能本身建立，而後存儲到對應的位置。

爲了便於理解，貼一張SyncData的存儲結構圖：從前面的代碼能夠翻到，在ios系統中，全局的哈希表容量爲8。

objc_sync_exit

int objc_sync_exit(id obj)
{
    int result = OBJC_SYNC_SUCCESS;
    
    if (obj) {
        SyncData* data = id2data(obj, RELEASE); 
        if (!data) {
            result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
        } else {
            bool okay = data->mutex.tryUnlock();
            if (!okay) {
                result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
            }
        }
    } else {
        // @synchronized(nil) does nothing
    }
	

    return result;
}
複製代碼

在分析過id2data後，objc_sync_exit就比較簡單了，也是找到對應的SyncData，而後進行解鎖，就不作過多的分析了。

@synchronized使用注意點

首先咱們來看以下代碼：在執行過程當中出現了崩潰，崩潰緣由是同時有兩條線程執行了賦值代碼時，致使原有的_testArray舊值被釋放了兩次，咱們作以下改動：結果仍是崩潰了,緣由也是由於過分釋放形成的，你們可能會有疑問，爲何我明明加了鎖仍是不行呢？

緣由主要出在@synchronized (_testArray)這裏，由於是對_testArray加鎖，當_testArray發生變化以後，在後續的線程和以前的線程中加鎖的對象已經發生了變化，即不一樣的線程取出的syncData不同了，由於object已經不同了，所以鎖就失效了，引起了後續的崩潰問題。可是若是咱們針對self進行加鎖，就能夠解決這個問題。

iOS多線程鎖之@synchronized原理分析