1、锁的基础概念

1.1 线程安全

当一个线程访问数据的时候，其他的线程不能对其进行访问，直到该线程访问完毕。简单来讲就是在同一时刻，对同一个数据操作的线程只有一个。而线程不安全，则是在同一时刻可以有多个线程对该数据进行访问，从而得不到预期的结果。

注：即线程内操作了一个线程外的非线程安全变量，这个时候一定要考虑线程安全和同步

1.2 检测线程安全

1.3 锁的作用

锁是保证线程安全的同步工具，每一个线程在访问数据前，要先获取 acquire 锁，访问结束之后释放 release 锁。如果锁已经被占用，其它试图获取锁的线程会等待或休眠，直到锁重新可用。

为什么要有锁呢？在多线程编程场景中，多个线程同时访问同一个共享数据，可能会出现数据竞争 data race，容易引发数据错乱等问题。这时候就需要用一种同步机制来保证数据安全，锁就是最常见的同步工具。

注：不要将过多的其他操作代码放到锁里面，否则一个线程执行的时候另一个线程就一直在等待，就无法发挥多线程的作用了。

1.4 有哪些锁

在iOS中锁的基本种类只有两种：互斥锁、自旋锁，其他的比如 条件锁、递归锁 等等这些都是上层的封装和实现。

1.5 互斥锁

互斥锁：防止两条线程同时对同一公共资源(比如全局变量)进行读写的机制。当获取锁操作失败时，线程会进入睡眠，等待锁释放时被唤醒。

可分为以下两种：

递归锁：可重入锁，同一个线程在锁释放前可再次获取锁，即可以递归调用。
非递归锁：不可重入，必须等锁释放后才能再次获取锁。

1.6 自旋锁

自旋锁：线程反复检查锁变量是否可⽤。由于线程在这⼀过程中保持执⾏，因此是⼀种忙等待。⼀旦获取了⾃旋锁，线程会⼀直保持该锁，直⾄显式释放⾃旋锁。

⾃旋锁 避免了进程上下⽂的调度开销，因此对于线程只会阻塞很短时间的场合是有效的。

1.7 互斥锁和自旋锁的区别

互斥锁 在线程获取锁但没有获取到时，线程会进入休眠状态，等锁被释放时线程会被唤醒；
自旋锁 的线程则会一直处于等待状态（忙等待）不会进入休眠——因此效率高。

2、@synchronized 分析

synchronized 是 objc 中提供的同步锁，支持递归。

@synchronized(self) {
    // do something
}

关于 synchronized，我们很多人都有一些以下的疑问，比如：

synchronized 对 obj 做了哪些操作？ synchronized 的 obj 为 nil 会造成什么后果? synchronized 和 pthread_mutex 有什么关系？ synchronized 和 objc_sync 有什么关系？

想要弄清楚这些问题，还得探索 synchronized 的底层实现，接下来我们来分析具体的实现。

2.1 准备阶段

我们分析 synchronized 的底层实现，首先要搞明白，我们从哪里开始着手，然后是想要探索什么内容，带着这两个问题，我们才开始分析。可以从以下两个方面分析

汇编方式

首先通过汇编来分析下 synchronized 都做了什么，先写一段测试代码：

然后执行 Xcode 的查看汇编指令，得到以下汇编代码。

我们发现，本质上还是调用了 _objc_sync_enter 和 _objc_sync_exit。

clang方式

当然我们也可以用 clang 来编译当前文件。

clang -x objective-c -rewrite-objc main.m

打开编译后的 main.cpp 文件，找到以下 c++ 的代码。

可以看到，和汇编的分析结果相似，synchronized 调用了 try catch，内部调用了 objc_sync_enter 和 objc_sync_exit，那么这两个函数属于哪个库，然后又是如何实现的呢?

我们可以给 objc_sync_enter 下一个符号断点

断住之后，我们可以看到是隶属于 libobjc.A.dylib，查看 objc4 源码，在 objc-sync.mm 文件中，找到了 objc_sync_enter 的实现。

2.2 源码分析

2.2.1 objc_sync_enter

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 上开始同步锁。
如果需要，初始化递归互斥锁（recursive mutex），并关联 obj。
如果 obj 为 nil，加锁不会成功。

2.2.2 objc_sync_exit

同样，在 objc-sync.mm 文件中，找到了 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;
}

2.3 SyncData 的实现

我们再来看看 objc_sync_enter 是如何加锁的？

// 获取 obj 关联的同步数据
SyncData* data = id2data(obj, ACQUIRE);
// 加锁
data->mutex.lock();

SyncData 又是什么呢？

typedef struct alignas(CacheLineSize) SyncData {
    // 下一条同步数据
    struct SyncData* nextData;
    // 锁的对象
    DisguisedPtr<objc_object> object;
    // 等待的线程数量
    int32_t threadCount;  // number of THREADS using this block
    // 递归互斥锁
    recursive_mutex_t mutex;
} SyncData;
typedef struct {
    SyncData *data;
    unsigned int lockCount;  // number of times THIS THREAD locked this block
} SyncCacheItem;
typedef struct SyncCache {
    unsigned int allocated;
    unsigned int used;
    SyncCacheItem list[0];
} SyncCache;

SyncData 是一个结构体，类似链表。

nextData：SyncData 的指针节点，指向下一条数据
object：锁住的对象
threadCount：等待的线程数量
mutex：使用的递归互斥锁

recursive_mutex_t

recursive_mutex_t 是一个递归互斥锁，也是基于 pthread_mutex_t 的封装。可以在 objc-os.h 找到以下代码：

using recursive_mutex_t = recursive_mutex_tt<LOCKDEBUG>;
class recursive_mutex_tt : nocopy_t {
    os_unfair_recursive_lock mLock;
  public:
    constexpr recursive_mutex_tt() : mLock(OS_UNFAIR_RECURSIVE_LOCK_INIT) {
        lockdebug_remember_recursive_mutex(this);
    }
    constexpr recursive_mutex_tt(const fork_unsafe_lock_t unsafe)
        : mLock(OS_UNFAIR_RECURSIVE_LOCK_INIT)
    { }
    void lock()
    {
        lockdebug_recursive_mutex_lock(this);
        os_unfair_recursive_lock_lock(&mLock);
    }
    void unlock()
    {
        lockdebug_recursive_mutex_unlock(this);
        os_unfair_recursive_lock_unlock(&mLock);
    }
    void forceReset()
    {
        lockdebug_recursive_mutex_unlock(this);
        bzero(&mLock, sizeof(mLock));
        mLock = os_unfair_recursive_lock OS_UNFAIR_RECURSIVE_LOCK_INIT;
    }
    bool tryLock()
    {
        if (os_unfair_recursive_lock_trylock(&mLock)) {
            lockdebug_recursive_mutex_lock(this);
            return true;
        }
        return false;
    }
    bool tryUnlock()
    {
        if (os_unfair_recursive_lock_tryunlock4objc(&mLock)) {
            lockdebug_recursive_mutex_unlock(this);
            return true;
        }
        return false;
    }
    void assertLocked() {
        lockdebug_recursive_mutex_assert_locked(this);
    }
    void assertUnlocked() {
        lockdebug_recursive_mutex_assert_unlocked(this);
    }
};

可以看到是基于 os_unfair_recursive_lock 的封装，这里就不继续往下深究了，具体可以查看官方文档的使用介绍 os_unfair_lock_lock

其实到这里，synchronized 的原理就很清晰了。

内部为每一个 obj 分配一把 recursive_mutex 递归互斥锁。
针对每个 obj，通过这个 recursive_mutex 递归互斥锁进行加锁、解锁。

接下来我们来看看内部是如何管理 obj 和 recursive_mutex 的。

2.3.1 id2data 流程分析

id2data 这一步管理了 obj 和 SyncData 的映射关系，根据 obj 获取SyncData，主要分为五步。

1. tls

第一步，从当前线程的 Thread Local Storage 快速缓存中获取 SyncData，只适合一个线程一应一个 SyncData。

static SyncData* id2data(id object, enum usage why)
{
    spinlock_t *lockp = &LOCK_FOR_OBJ(object);
    SyncData **listp = &LIST_FOR_OBJ(object);
    SyncData* result = NULL;
    // 1.先从线程 Thread Local Storage 快速缓存中获取 SyncData
#if SUPPORT_DIRECT_THREAD_KEYS
    // Check per-thread single-entry fast cache for matching object
    bool fastCacheOccupied = NO;
    SyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY);
    if (data) {
        fastCacheOccupied = YES;
        if (data->object == object) {
            // Found a match in fast cache.
            uintptr_t lockCount;
            result = data;
            // 获取当前线程 tls 缓存里的 SyncData 加锁次数
            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: {
                // 加锁一次，更新当前线程 tls 缓存
                lockCount++;
                tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
                break;
            }
            // 释放锁
            case RELEASE:
                // 释放锁一次，更新当前线程 tls 缓存
                lockCount--;
                tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
                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
// 省略部分代码.....

2. fetch_cache

第二步，从当前线程缓存中获取 SyncCache 结构体，包含了 SyncCacheItem 数组，一个线程可以对应多个 SyncCacheItem 同步对象，也就是一个线程可以处理多个SyncData。

    // Check per-thread cache of already-owned locks for matching object
    // 从当前线程缓存中获取 SyncCache
    SyncCache *cache = fetch_cache(NO);
    if (cache) {
        unsigned int i;
        for (i = 0; i < cache->used; i++) {
            // 编译 SyncCache、SyncCacheItem 列表。
            SyncCacheItem *item = &cache->list[i];
            if (item->data->object != object) continue;
            // Found a match.
            // 找到匹配当前 obj 的 SyncCacheItem
            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;
        }
    }

3. LIST_FOR_OBJ

第三步，通过 obj 在全局哈希表 sDataLists 中查找 SyncData 列表，因为sDataLists 是全局共享的，所以这里使用了 spinlock_t 加锁。

    // Thread cache didn't find anything.
    // Walk in-use list looking for matching object
    // Spinlock prevents multiple threads from creating multiple 
    // locks for the same new object.
    // We could keep the nodes in some hash table if we find that there are
    // more than 20 or so distinct locks active, but we don't do that now.
    // 先加锁
    lockp->lock();
    {
        SyncData* p;
        SyncData* firstUnused = NULL;
        // 遍历 SyncData 列表
        for (p = *listp; p != NULL; p = p->nextData) {
            if ( p->object == object ) {
                result = p;
                // atomic because may collide with concurrent RELEASE
                OSAtomicIncrement32Barrier(&result->threadCount);
                goto done;
            }
            // 标记未使用的 SyncData
            if ( (firstUnused == NULL) && (p->threadCount == 0) )
                firstUnused = p;
        }
        // no SyncData currently associated with object
        // 没有找到 SyncData
        if ( (why == RELEASE) || (why == CHECK) )
            goto done;
        // an unused one was found, use it
        // 找到 SyncData，且未使用，重复利用
        if ( firstUnused != NULL ) {
            result = firstUnused;
            result->object = (objc_object *)object;
            result->threadCount = 1;
            goto done;
        }
    }

4. New SyncData

第四步，如果上面三步都没有找到 SyncData，那么需要新建 SyncData。

    // Allocate a new SyncData and add to list.
    // XXX allocating memory with a global lock held is bad practice,
    // might be worth releasing the lock, allocating, and searching again.
    // But since we never free these guys we won't be stuck in allocation very often.
    posix_memalign((void **)&result, alignof(SyncData), sizeof(SyncData));
    result->object = (objc_object *)object;
    result->threadCount = 1;
    //new 递归互斥锁
    new (&result->mutex) recursive_mutex_t(fork_unsafe_lock);
    result->nextData = *listp;
    *listp = result;

5. Save SyncData

第五步，保存 SyncData 对象。

 done:
    // 释放 sDataLists 的锁
    lockp->unlock();
    if (result) {
        // Only new ACQUIRE should get here.
        // All RELEASE and CHECK and recursive ACQUIRE are 
        // handled by the per-thread caches above.
        if (why == RELEASE) {
            // Probably some thread is incorrectly exiting 
            // while the object is held by another thread.
            return nil;
        }
        if (why != ACQUIRE) _objc_fatal("id2data is buggy");
        if (result->object != object) _objc_fatal("id2data is buggy");
    // 线程 tls fast cache 模式，缓存 SyncData
#if SUPPORT_DIRECT_THREAD_KEYS
        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 模式，加入到 SyncCacheItem 数组
        {
            // Save in thread cache
            if (!cache) cache = fetch_cache(YES);
            cache->list[cache->used].data = result;
            cache->list[cache->used].lockCount = 1;
            cache->used++;
        }
    }
    return result;

至此，id2data 的功能已经大致清晰。利用 SyncData 管理 obj、线程、递归互斥锁之间的关系。

1. 先从当前线程的 tls fast cache 快速缓存中去获取单个 SyncData 对象。
2. 如果 1 中 SyncData未找到，再从当前线程的缓存中获取 SyncCache，遍历 SyncCacheItem 数组，找到对应的 SyncData。
3. 如果 2 中 SyncData 未找到，再从全局的哈希表 sDataLists 中查找 SyncCache，查看其它线程是否已经占用过 obj。
4. 如果还是没有找到 SyncData，则新建一个 SyncData 对象。
5. 把新建的 SyncData 加入到当前线程缓存里，或者全局的哈希表 sDataLists 中。

2.4 回顾

相信看到这里，开头的这些问题，我们应该都知道答案了吧。

问: synchronized 对 obj 做了哪些操作？ 答: 会为 obj 生成递归自旋锁，并建立关联，生成 SyncData，存储在当前线程的缓存里或者全局哈希表里。 问: synchronized 的 obj 为 nil 会造成什么后果? 答: 加锁操作无效。 问: synchronized 和 pthread_mutex 有什么关系？ 答: SyncData 里的递归互斥锁，使用 pthread_mutex 实现的。 问: synchronized 和 objc_sync 有什么关系？ 答: synchronized 底层调用了 objc_sync_enter() 和 objc_sync_exit()。

iOS底层原理

二十一、Synchronized