在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原理分析