OC 底层原理 21:锁 @synchronized

714 阅读15分钟

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

1. 锁的类型

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

1.1 自旋锁

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

自旋锁优缺点

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

自旋锁种类

常见的自旋锁种类:

  • OSSpinLock
  • atomic

1.2 互斥锁

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

互斥锁优缺点

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

互斥锁种类

常见的互斥锁种类:

  • NSLock
  • pthread_mutex
  • @synchronized

读写锁

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

2. @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);
}

通过xcrun查看底层代码编译:

Xnip2022-07-28_14-19-19.png

通过上面查看.cpp代码,知道@synchronized核心的方法是objc_sync_enterobjc_sync_exit方法,下面就探究这两个方法。在探究之前首先找到objc_sync_enterobjc_sync_exit方法是属于哪个源码库,给objc_sync_enterobjc_sync_exit下符号断点:

Xnip2022-07-28_14-27-23.png

Xnip2022-07-28_14-28-02.png

很明显示属于Objc源码库,其实从方法的名字也能猜个大概

2.1 objc_sync_enter探究

Objc源码库中全局搜索 objc_sync_enter

// 从'obj'开始同步。
// 递归分配与obj关联的互斥锁。
// 一旦获得锁,返回OBJC_SYNC_SUCCESS。
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,注意objid类型,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就走加锁流程,否则相当于没有加锁

2.2 objc_sync_exit探究

Objc源码库中全局搜索 objc_sync_exit

// 结束'obj'同步。
// 返回OBJC_SYNC_SUCCESS或OBJC_SYNC_NOT_OWNING_THREAD_ERROR
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方法就是解锁功能,如果objnil 什么也不做

总结:

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

2.3 id2data方法探究

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

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

Xnip2022-07-28_15-23-16.png

图中的整体流程如下

  • 首先从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也是一个结构体里面包含了SyncDatalockCount当前线程当前对象锁的次数

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
  • 如果whyACQUIRE表示加锁,此时lockCount++,并把lockCount更新到tls
  • 如果whyRELEASE表示解锁,此时lockCount--,并把lockCount更新到tls中,如果lockCount == 0表示当前线程中没有加锁的对象或者已经全部解锁。此时threadCount1,返回result
  • 如果data->objectobject不是同一个对象则进行线程缓存查找流程

线程缓存查找流程

// 检查已拥有锁的每个线程缓存,以查找匹配的对象
// 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去为SyncCacheSyncCacheItem开辟内存空间第一次开辟4SyncCacheItem,初始化的个数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中查找datacreate = 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,然后判断SyncListdata有值
  • 如果SyncListdata有值中有值,则在单向链表找到相应的加锁对象,进行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流程

  • 当前线程第一个进行加锁操作的对象,此时会把SyncDatalockCout=1 存储在tls,而且当前线程的tls不会改变除非解锁。一个线程的tls只存储第一次加锁的SyncDatalockCout

  • 当在同一线程对另一个对象进行加锁注意(上一个加锁的对象没有进行解锁),此时的SyncDatalockCount存储在线程缓存中

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

案例分析

单线程单对象递归加锁

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

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

Xnip2022-07-28_17-50-53.png

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

Xnip2022-07-28_17-54-05.png

Xnip2022-07-28_17-59-28.png

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

Xnip2022-07-28_18-03-45.png

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

Xnip2022-07-28_18-16-05.png

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

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

Xnip2022-07-28_18-20-15.png

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

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

Xnip2022-07-28_18-22-33.png

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

单线程多对象递归加锁

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        YJPerson * p  = [YJPerson alloc];
        YJPerson * p1 = [YJPerson alloc];
        YJPerson * p2 = [YJPerson 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对象进行加锁,此时创建的SyncDatalockCount存储在tls中,这个上面已经探究过了

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

Xnip2022-07-28_18-43-15.png

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

Xnip2022-07-28_18-55-31.png

最新创建的SyncData放在拉链的最前面,此时p1SyncDatanextData存储着pSyncData地址

Xnip2022-07-28_18-56-48.png

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

多线程递归加锁

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        YJPerson * p  = [YJPerson alloc];
        YJPerson * p1 = [YJPerson alloc];
        dispatch_queue_t  queue = dispatch_queue_create("YJ", 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)打下断点进行调试

Xnip2022-07-28_21-03-10.png

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

@synchronized总结

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