前言

IOS中的锁是比较困扰大家的一个问题，知道有锁这么个东西，但是却不常用。今天带大家一起走进锁的底层世界

准备工作

Objc-818.2

锁的类型

锁基本分为三种类型：自旋锁、互斥锁、读写锁

自旋锁

线程反复检查锁变量是否可用，由于线程在这一过程中保持执行，因此是一种忙等状态。一旦获取了自旋锁，线程会一直保持该锁，直至显示释放自旋锁。自旋锁避免了线程上下文的调度开销，因此对于线程只会阻塞很短的场合是有效的

自旋锁优缺点

优点：自旋锁不会引起调用者的睡眠，避免了线程的调度开销，如果短时间内可以获得锁，那么优先使用自旋锁
缺点：自旋锁一直占用着cpu，在未获得锁的情况下会一直忙等，大大的降低了cpu的效率。这里也可以看出自旋锁不能进行递归使用

自旋锁种类

常见的自旋锁种类

OSSpinLock
atomic

互斥锁

是一种多线程编程中，防止多条线程对同一公共资源（比如全局变量）进行读写机制。该目的是通过将代码切片成一个个临界区而达成。其实简单的说同一时刻保证有一条线程执行任务，其他线程会处在睡眠状态

互斥锁优缺点

优点：在调用被锁的资源时，调用者的线程会进行睡眠。cpu可以调度其他的线程工作。所以任务复杂的时间长的建议使用互斥锁
缺点：其实个人感觉也不算缺点，互斥锁就涉及到了线程的调度开销，如果任务时间很短，线程调度就会显得降低了cpu的效率

互斥锁种类

常见的互斥锁种类

NSLock
pthread_mutex
@synchronized

读写锁

读写锁适合于对数据结构读的次数比写的次数多的多的情况。因为读模式锁定时可以共享，写模式锁定时意味着独占，所以多写锁有叫做共享-独占锁

锁的性能数据

锁的种类很多种，但是每种锁的性能不一样。在选择的锁的过程尽量选择性能高的锁，下面根据LockPerformance 源码得出锁的性能高低

模拟器性能测试如下：

模拟器的情况目前测试性能高低如下
OSSpinLock(自旋锁) -> os_unfair_lock(互斥锁) ->dispatch_semaphore_t(信号量) -> pthread_mutex(互斥锁) -> NSLock(互斥锁) -> NSCondition(条件锁) -> pthread_mutex_recursive(互斥递归锁) -> NSRecursiveLock(递归锁) -> NSConditionLock(条件锁) -> synchronized(互斥锁)

iPhoneX真机（软件版本：13.7）

真机情况目前测试性能高低如下
OSSpinLock(自旋锁) -> os_unfair_lock(互斥锁) -> dispatch_semaphore_t(信号量) -> NSCondition(条件锁) -> NSLock(互斥锁) -> pthread_mutex_t(互斥锁) -> pthread_mutex_recursive(互斥递归锁) -> NSRecursiveLock(递归锁) -> NSConditionLock(条件锁) -> @synchronized(互斥锁)

iPhoneX真机（软件版本：13.7）性能图

总结：有些锁性能差距不是很大，每次运行数据可能会有些许的变化，但是整体性能变化不大。@synchronized的性能是最低的，这个是大家经常用的因为用起来简单方便。在iPhone 12真机以后苹果对@synchronized性能进行了巨大的优化，现在没有iPhone 12真机，有的话后面会进行更新

`@synchronized`

下面探究下大家经常用的一把锁@synchronized，大家喜欢用它是因为方便。下面探究下@synchronized底层是如何实现的。探究底层快速的方法是根据汇编走流程，还有可以通过clang查看底层编译代码

调试代码

int main(int argc, char * argv[]) {
    NSString * appDelegateClassName;
    @autoreleasepool {
        appDelegateClassName = NSStringFromClass([AppDelegate class]);
        @synchronized (appDelegateClassName) {
       
        }
    }
    return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}

第一种汇编调试

第二种通过clang查看底层代码编译

通过上面的两种方式核心的方法是objc_sync_enter和objc_sync_exit方法，下面就探究这两个方法。在探究之前首先找到objc_sync_enter和objc_sync_exit方法是属于哪个源码库，给objc_sync_enter和objc_sync_exit下符号断点

很明显示属于Objc源码库，其实从方法的名字也能猜测出来

`objc_sync_enter`探究

在Objc源码库中全局搜索 objc_sync_enter ``

int objc_sync_enter(id obj)
{
    int result = OBJC_SYNC_SUCCESS;
    //根据obj是否存在判断流程
    if (obj) {
        //获取底层封装的 SyncData
        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是否为nil，注意obj是id类型，id是对象指针类型objc_object*
如果obj有值走加锁的流程
如果obj = nil根据注释@synchronized(nil) does nothing什么也不操作，里面调用了objc_sync_nil()方法

全局搜索objc_sync_nil()方法

#   define BREAKPOINT_FUNCTION(prototype)                             \
    OBJC_EXTERN __attribute__((noinline, used, visibility("hidden"))) \
    prototype { asm(""); }
    
    
 BREAKPOINT_FUNCTION(
    void objc_sync_nil(void)
);

BREAKPOINT_FUNCTION 是一个宏定义void objc_sync_nil(void)是一个参数。相当于 define BREAKPOINT_FUNCTION(prototype)中的prototype，而prototype的实现就是啥也没做，简单理解就是如果obj = nil相当于没加锁

总结：objc_sync_enter方法是加锁的过程，如果obj参数不为nil就走加锁流程，否则相当于没有加锁

`objc_sync_exit`探究

在Objc源码库中全局搜索 objc_sync_exit

int objc_sync_exit(id obj)
{
    int result = OBJC_SYNC_SUCCESS;
    //根据obj是否存在判断流程
    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 {
        //如果 obj = nil 什么也不做
        // @synchronized(nil) does nothing
    }
    

    return result;
}

objc_sync_exit方法和objc_sync_enter方法是对应的。objc_sync_exit方法就是解锁功能，如果obj= nil 什么也不做

总结：

objc_sync_enter方法作用是任务开始时进行加锁操作，而objc_sync_exit方法作用是在任务结束时进行解锁操作。如果参数为nil相当于没有加锁解锁的作用，这就是@synchronized内部自己实现的加锁解锁功能
在objc_sync_enter方法和objc_sync_exit方法都有id2data方法而且加锁解锁的功能也是通过id2data方法的返回值调用的。下面探究下id2data方法

`id2data`方法探究

整体流程梳理及数据结构分析

id2data方法源码比较多，先理一下整体流程，然后在对每一部分进行详细的探究

图中的整体流程如下

首先从tls（线程局部存储）中查找SyncData，如果查找到就走其相应的流程
如果tls没有查找到就到线程缓存中去查找，如果缓存中有走缓存中的流程
如果缓存中没有判断哈希表中是否存储对应的SyncData，如果SyncData存在就进行多线程操作同一对象的流程
如果都没有则表示是第一次进来，此时创建SyncData

源码中说到了SyncData、哈希表StripedMap以及SyncCache

SyncData结构分析

typedef struct alignas(CacheLineSize) SyncData {
    struct SyncData* nextData;//相同的数据类型 单向链表形式
    DisguisedPtr<objc_object> object;//将object进行底层封装
    //多少线程对同一对象进行加锁的操作
    int32_t threadCount;  // number of THREADS using this block
    recursive_mutex_t mutex;//递归锁
} SyncData;

SyncData是一个结构体类型，里面有4个变量

struct SyncData* nextData：和SyncData相同的数据类型单向链表的形式
DisguisedPtr<objc_object> object：将object进行底层封装，方便计算比较。关联对象也有其封装
threadCount：多少线程对同一对象进行加锁的操作
recursive_mutex_t mutex：递归锁
StripedMap

#define LOCK_FOR_OBJ(obj) sDataLists[obj].lock
#define LIST_FOR_OBJ(obj) sDataLists[obj].data
static StripedMap<SyncList> sDataLists;
// SyncList
struct SyncList {
    SyncData *data;
    spinlock_t lock;

    constexpr SyncList() : data(nil), lock(fork_unsafe_lock) { }
};
// StripedMap
template<typename T>
class StripedMap {
#if TARGET_OS_IPHONE && !TARGET_OS_SIMULATOR
    enum { StripeCount = 8 };
#else
    enum { StripeCount = 64 };
#endif
   ...//省略部分代码
}

StripedMap是一张哈希表在真机情况的存储SyncList个数是8个，其它环境64个。SyncList是一个结构体有两个变量SyncData *data 和 lock

SyncCache

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

typedef struct SyncCache {
    unsigned int allocated;//开辟SyncCacheItem内存空间的个数
    unsigned int used;//被使用的个数
    SyncCacheItem list[0];
} SyncCache;

SyncCache是一个结构体，每个线程缓存对应一个SyncCache.SyncCacheItem表示每个对象锁的信息。SyncCacheItem也是一个结构体里面包含了SyncData和lockCount当前线程当前对象锁的次数

`tls`中查找`data`

tls线程局部存储：是操作系统为线程单独提供的私有空间，通常只有有限的容量。每个线程都会有独立的tls

// Check per-thread single-entry fast cache for matching object
bool fastCacheOccupied = NO;
//1.从线程的局部存储中查找data
SyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY);
if (data) {
    fastCacheOccupied = YES;//如果fastCacheOccupied = YES
    //如果 data->object 和 object相等
    if (data->object == object) {
        // Found a match in fast cache.
        uintptr_t lockCount;//被锁的次数
        result = data;//在tls中查找的data 赋值给result
        //初始化的lockCount = 1 存储 key = SYNC_COUNT_DIRECT_KEY 的tls中
        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: {//加锁的标识
            lockCount++;//lockCount ++  说明此锁是可以递归的
            tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);//更新tls中lockCount的值
            break;
        }
        case RELEASE://解锁的标识
            lockCount--;
            tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);//更新tls中lockCount的值
            if (lockCount == 0) {
                // remove from fast cache
                //如果 lockCount = 0 表示当前线程全部解锁，tls中的data设置为nil
                tls_set_direct(SYNC_DATA_DIRECT_KEY, NULL);
                // atomic because may collide with concurrent ACQUIRE
                //线程threadCount个数进行减1
                OSAtomicDecrement32Barrier(&result->threadCount);
            }
            break;
        case CHECK:
            // do nothing
            break;
        }
        //直接返回 result
        return result;
    }
}

tls查找流程

首先在tls查到data，如果data有值fastCacheOccupied = YES
如果data->object == object表示加锁的是同一个对象，此时把在tls中查找的data赋值给result
如果why是ACQUIRE表示加锁，此时lockCount++，并把lockCount更新到tls中
如果why是RELEASE表示解锁，此时lockCount--，并把lockCount更新到tls中，如果lockCount == 0表示当前线程中没有加锁的对象或者已经全部解锁。此时threadCount减1，返回result
如果data->object和object不是同一个对象则进行线程缓存查找流程

线程缓存查找流程

//2.从线程缓存中查找如果fetch_cache(NO)参数是NO表示去只是去查找
SyncCache *cache = fetch_cache(NO);
if (cache) {
    unsigned int i;
    //遍历缓存中的 SyncCacheItem
    for (i = 0; i < cache->used; i++) {
        SyncCacheItem *item = &cache->list[i];
        if (item->data->object != object) continue;
        // Found a match.
        result = item->data;//如果线程缓存中查找到item将item->data赋值给result
        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
                // 将当前的item中的数据设置为空的数据，然后cache->used被使用的个数进行减减
                cache->list[i] = cache->list[--cache->used];
                // atomic because may collide with concurrent ACQUIRE
                // 线程threadCount个数进行减一
                OSAtomicDecrement32Barrier(&result->threadCount);
            }
            break;
        case CHECK:
            // do nothing
            break;
        }
        //如果线程缓存中查询到就直接返回result
        return result;
    }
}

线程缓存的查找流程和tls查找流程基本相似，的就是数据结构的类型不同。在线程缓存中通过遍历循环查找需要加锁的对象，详细的流程上面注释的很清楚

fetch_cache探究

static SyncCache *fetch_cache(bool create)
{
    _objc_pthread_data *data;
    
    //查询或者创建线程数据
    data = _objc_fetch_pthread_data(create);
    if (!data) return NULL;//如果data = nil 返回NULL

    if (!data->syncCache) {
        if (!create) {
            return NULL;
        } else {
            //首次创建 4 个 SyncCacheItem
            int count = 4;
            //开辟内存空间
            data->syncCache = (SyncCache *)
                calloc(1, sizeof(SyncCache) + count*sizeof(SyncCacheItem));
            //初始化的个数等于 4 
            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;
}

根据create去查找线程数据_objc_pthread_data，如果data不存在直接返回NULL
如果data->syncCache不存在且create== YES去为SyncCache和SyncCacheItem开辟内存空间第一次开辟4个SyncCacheItem，初始化的个数allocated = 4。每个SyncCacheItem里面的默认数据都是0
如果初始化的个数和使用的个数相进行2倍扩容。返回SyncCache

_objc_fetch_pthread_data探究

 _objc_pthread_data *_objc_fetch_pthread_data(bool create)
{
    _objc_pthread_data *data;
    //先去tls查找线程数据，如果data存在直接返回
    //如果data不存在且create = NO 返回nil
    data = (_objc_pthread_data *)tls_get(_objc_pthread_key);
    //如果data不存在且create = YES 则去开辟内存创建_objc_pthread_data
    if (!data  &&  create) {
        data = (_objc_pthread_data *)
            calloc(1, sizeof(_objc_pthread_data));
        tls_set(_objc_pthread_key, data);
    }

    return data;
}

_objc_fetch_pthread_data流程

在tls中查找_objc_pthread_data，如果查询到直接返回data
如果data不存在且create = NO，返回nil
如果data不存在且create = YES，则去开辟内存创建_objc_pthread_data

所以在create = NO只会去tls中查找data，create = YES先去查找data，如果没有就去开辟内存创建data

多线程加锁同一对象

为什么说下面这段代码是多线程加锁同意对象呢，因为如果是单个线程内存操作会直接走上面的tls查找流程和线程缓存查找流程

lockp->lock();
//多线程操作流程
{
    SyncData* p;
    SyncData* firstUnused = NULL;
    //哈希表中的SyncList的data如果有值即*listp有值
    //遍历循环单向链表中的SyncData
    for (p = *listp; p != NULL; p = p->nextData) {
        //查询到需要加锁的对象
        if ( p->object == object ) {
            result = p;//赋值操作
            // atomic because may collide with concurrent RELEASE
            //线程数threadCount进行加1操作，threadCount多个线程对该对象进行加锁操作
            OSAtomicIncrement32Barrier(&result->threadCount);
            //跳转到done流程。此时的result还是存在各个线程的tls中或者线程缓存中
            goto done;
        }
        if ( (firstUnused == NULL) && (p->threadCount == 0) )
            firstUnused = p;
    }
    ...
}

多线程操作流程

首先会根据object在哈希表中找到下标对应的SyncList，然后判断SyncList的data有值
如果SyncList的data有值中有值，则在单向链表找到相应的加锁对象，进行threadCount++操作，然后跳转done流程，在done流程里存储在对应线程的tls中或者线程缓存中

创建`SyncData`

posix_memalign((void **)&result, alignof(SyncData), sizeof(SyncData));
//赋值操作
result->object = (objc_object *)object;
result->threadCount = 1;//默认 threadCount = 1
new (&result->mutex) recursive_mutex_t(fork_unsafe_lock);//创建一个递归锁
result->nextData = *listp; //哈希下标如果一样头插法形成链表的形式
*listp = result;//更新哈希表中的值

第一次给对象加锁时，会创建一个SyncData，简单的说就是一个SyncData绑定一个对象，一个对象有且只有一个SyncData
如果不同对象哈希的下标是一样的这样就会形成单向链表，而插入的方式采用的是头插法

`done`流程

done:
    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");

#if SUPPORT_DIRECT_THREAD_KEYS
        // fastCacheOccupied = NO 表示当前线程的tls里面没有数据
        // 此时把第一次需要加锁创建的SyncData和lockCout = 1 存储在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
        {   //当在同一线程对另一个对象进行加锁注意（上一个加锁的对象没有进行解锁）
            //此时的SyncData和lockCount存储在线程缓存中
            // 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;

done流程

当前线程第一个进行加锁操作的对象，此时会把SyncData和lockCout=1 存储在tls，而且当前线程的tls不会改变除非解锁。一个线程的tls只存储第一次加锁的SyncData和lockCout
当在同一线程对另一个对象进行加锁注意（上一个加锁的对象没有进行解锁），此时的SyncData和lockCount存储在线程缓存中

至此整个id2data方法的源码已经探究完，下面通过案例分析下

案例分析

单线程单对象递归加锁

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        LWPerson * p = [LWPerson alloc];
        @synchronized (p) {
            NSLog(@"p第一次进来");
            @synchronized (p) {
                NSLog(@"p第二次进来");
                @synchronized (p ) {
                    NSLog(@"p第三次进来");
                };
            };
        };
 
    return 0;
}

在第一个@synchronized打下断点进行调试

第一次对对象加锁*listp、data以及cache都是空，说哈希表中和tls以及线程缓存中都没有查找到。那么就会进入创建SyncData流程，为了方便测试我把在非真机状态下的 StripeCount = 2

图中显示此时的哈希表中的数据都是空的没有数据，断点往下走一步，继续调试

*listp = result更新哈希表中data的值，此时result的nextData等于*listp，*listp前面打印的值是空的，所以result的nextData也是空的，*listp = result以后此时*listp已经被赋值。继续调试走到done流程

图中断点显示此时第一次创建的SyncData和lockCount存储在tls中

在第二个@synchronized打下断点进行调试

对同一个对象再次加锁此时*listp和data都有值，那么此时会走到tls查找data的流程， lockCount = 2说明又加锁一次，然后更新tls中lockCount的值，然后直接返回result

在第三个@synchronized打下断点进行调试

很明显在单线程中对同一个对象进行递归加锁，SyncData和lockCount存储在tls，而没有缓存的事

单线程多对象递归加锁

int main(int argc, const char * argv[]) {
    @autoreleasepool {
    LWPerson * p  = [LWPerson alloc];
    LWPerson * p1 = [LWPerson alloc];
    LWPerson * p2 = [LWPerson alloc];

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        @synchronized (p) {
            NSLog(@"p第一次进来");
            @synchronized (p1) {
                NSLog(@"p1第二次进来");
                @synchronized (p2) {
                    NSLog(@"p2第三次进来");
                };
            };
        };
    });
    do {

    } while (1);
  }
    return 0;
}

在第一个@synchronized打下断点进行调试
对p对象进行加锁，此时创建的SyncData和lockCount存储在tls中，这个上面已经探究过了

在第二个@synchronized打下断点进行调试

*listp有值说明p和p1的哈希下标是一样的，此时cache中也没有数据，tls中的是有data不过和p1不是同一个对象，所以此时会重新创建SyncData，然后用头插法的方式形成单向链表

最新创建的SyncData放在拉链的最前面，此时p1的SyncData的nextData存储着p的SyncData地址

因为当前线程的tls中是有data的而且不会改变，所以fastCacheOccupied = YES，在走done流程就会存储在线程缓存中，如果后面还有其它对象需要加锁，也都会储存在缓存中。解锁的时候缓存的数据会被清空

多线程递归加锁

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        LWPerson * p  = [LWPerson alloc];
        LWPerson * p1 = [LWPerson alloc];
        dispatch_queue_t  queue = dispatch_queue_create("lw", DISPATCH_QUEUE_CONCURRENT);
        for (int i = 0; i<10;i++) {
            dispatch_async(queue, ^{
                @synchronized (p) {
                    NSLog(@"p第一次进来");
                    @synchronized (p1) {
                        NSLog(@"p第一次进来");
                    };
                };
            });
        }
        do {

        } while (1);
         
    }
    return 0;
}

在 @synchronized (p1)打下断点进行调试

哈希表中只有一个SyncList有值，而且SyncData里面的值threadCount = 10，说明走了多线程的流程。而nextData的值为空，说明此时只有一个对象进行了多线程加锁，如果多线程多对象实际就是每个对象走单个对象的加锁流程

单向链表图后面补上

`@synchronized`总结

objc_sync_exit流程和objc_sync_enter流程走的是一样的只不过一个是加锁一个是解锁
@synchronized底层是链表查找、缓存查找以及递归，是非常耗内存以及性能的
@synchronized底层封装了是一把递归锁，可以自动进行加锁解锁，这也是大家喜欢使用它的原因
@synchronized中lockCount控制递归，而threadCount控制多线程
@synchronized加锁的对象尽量不要为nil，不然起不到加锁的效果

总结

锁的世界才开始，今天探究了@synchronized递归锁。下面会探究其它类型的锁，让我们一起在锁的世界遨游

IOS底层原理之锁 - @synchronized

前言