@synchronized底层探索&其他锁

2020-11-17 本文已影响0人猿人

锁的性能排行

锁的性能排行.png

锁的归类

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

互斥锁：是一种用于多线程编程中，防止两条线程同时对同一公共资源进行读写的机制。该目的通过将代码切片成一个一个的临界区而达成。
上图中属于互斥锁的有：

NSLock
pthread_mutex
@synchronized

条件锁：就是条件变量，当进程的某些资源要求不满足时就进入休眠，也就是锁住了。当资源分配到了，条件锁打开，进程继续运行
上图中属于条件锁的有：

NSConfition
NSConditionLock

递归锁：就是同一线程可以加锁N次而不会引发死锁
上图中属于递归锁的有

NSRecursiveLock
pthread_mutex(recursive)

信号量（semaphore）:是一种更高级的同步机制，互斥锁可以说是semaphore在仅取值0/1时的特例。信号量可以有更多的取值空间，用来实现更加复杂的同步，而不单单是线程间的互斥。

其实基本的锁就包括了三类，自旋锁 互斥锁 读写锁，其他的比如条件锁，递归锁，信号量都是上层的封装和实现！

引用：百度百科读写锁

@synchronized

对于@synchronized 的使用大家都不陌生，但是它的底层实现是怎样的呢？通过底层分析我们又能得到什么新的发现？下面废话不多说直接探寻其底层。

如何进行探索（知道的可略过直接去看底层源码分析）

1、 dome 准备

- (void)viewDidLoad {
    [super viewDidLoad];
    // Do any additional setup after loading the view.
    self.ticketCount = 15;
    [self  testSaleTicket];
}
 
- (void)testSaleTicket{
    ///窗口 1
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        for (int i = 0; i < 5; i++) {
            [self saleTicket];
        }
    });
    ///窗口 2
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        for (int i = 0; i < 5; i++) {
            [self saleTicket];
        }
    });
    ///窗口 3
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        for (int i = 0; i < 10; i++) {
            [self saleTicket];
        }
    });
}

- (void)saleTicket{
//     @synchronized (self) {
        
        if (self.ticketCount > 0) {
            self.ticketCount--;
            sleep(0.1);
            NSLog(@"当前余票还剩：%ld张",self.ticketCount);
            
        }else{
            NSLog(@"当前车票已售罄");
        }
//     }
 }

在没有考虑到线程安全的情况我们运行其任务

截屏2020-11-17 下午2.25.41.png

这明显这票数有问题票池抽了疯，不管三七二一的瞎胡扯的反馈。

当用上了 @synchronized 完美的解决了问题

截屏2020-11-17 下午2.36.29.png

2、如何分析synchronize

那肯定是符号断点，clang了
首先符号断点打开 Debug -> Debug Workflow -> Always Show Disassembly

符号断点打开
将断点打到 @synchronized 并运行在汇编里我们找到了两个很重要的线索

汇编线索1

汇编线索2

objc_sync_enter 函数
objc_sync_exit 函数

我们到此先记住这两个函这是可疑的两个函数下面在clang一下 @synchronized 看clang编译器是怎样实现的。
在main函数中写一个 @synchronized

截屏2020-11-17 下午3.02.33.png

通过命令得到 mian.cpp

clang -rewrite-objc -fobjc-arc -fobjc-runtime=ios-14.0.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.0.sdk main.m

截屏2020-11-17 下午3.16.03.png

通过 clang我们也发现了上面的两个函数是一模一样的，证明上面的两个函数正是我们要研究的。

找到 objc_sync_enter 和 objc_sync_exit 所在的库
下符号断点

下符号断点找到所在的库

此时我们知道了 objc_sync_enter 函数是在 libojc 中掉起的。

截屏2020-11-17 下午3.25.43.png
objc_sync_exit 函数也是由 libobjc 中调起的

到这里我们也就知道了@synchronized 底层是由 objc_sync_enter 和objc_sync_exit 两个重要的函数组合而成他们来自 libobjc 动态库。也就找到程序的入口分析的入口。

objc_sync_enter&objc_sync_exit 函数分析

找到objc4源码并定位到当前函数

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为真的话通过id2data函数获取一个SyncData 对象，并将此对象里面的 mutex 的属性上锁

我们看 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;

可以看到SyncData是一个结构体，里面包含一个指向下一个SyncData的指针nextData,可以看出SyncData是链表中的一个节点。
包含object 将其类型进行了伪装，其实它就是我们传进来的 object。
里面还有一个 threadCount,通过注释我们可以详细的看到使用此块的线程数。
还有一把锁，从这把锁的定义来看它是一个递归互斥类型

来到 id2data函数看里面如何获取到SyncData的对象的
由于函数太长我们拆分几大块来看

第一步： 判断是否支持tls缓存，从tls缓存中获取obj的相关信息

static SyncData* id2data(id object, enum usage why)
{
    ///跟当前对象关联的所有的被锁线程中的锁任务的状态
    spinlock_t *lockp = &LOCK_FOR_OBJ(object);
    ///跟当前对象关联的所有的被锁线程数据
    SyncData **listp = &LIST_FOR_OBJ(object);
    SyncData* result = NULL;

#if SUPPORT_DIRECT_THREAD_KEYS
    //检查每个线程单条目快速缓存是否匹配对象
    // Check per-thread single-entry fast cache for matching object
    ///默认没找到
    bool fastCacheOccupied = NO;
    ///从线程中读取数据  (tls： （Thread Local Storage） 线程本地存储)
    SyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY);
    if (data) {
   /// 找到了 设置为 YES
        fastCacheOccupied = YES;
         ///如对象是传入的对象
        if (data->object == object) {
            // Found a match in fast cache. ///从快速缓存中找到
            uintptr_t lockCount;
            ///返回值赋值
            result = data;
            /// 当前线程 被锁了 几回 如当前线程递归调用锁
            lockCount = (uintptr_t)tls_get_direct(SYNC_COUNT_DIRECT_KEY);
            /// 如果使用此块儿的线程总数 或者 当前线程被锁次数 都小于等于0 那么这时候bug
            if (result->threadCount <= 0  ||  lockCount <= 0) {
                _objc_fatal("id2data fastcache is buggy");
            }

            switch(why) {
            case ACQUIRE: {///进行中
                lockCount++;///将当前线程被锁次数+1
                 ///更新线程缓存的任务数
                tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
                break;
            }
            case RELEASE:/// 释放中
                lockCount--;///将当前线程被锁次数 -1
                ///更新线程缓存的任务数
                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

tls，Thread Local Storage,线程局部储存，它是操作系统为线程单独提供的私有空间，通常只有有限的容量。
百度百科：线程局部存储

从tls读取数据，如果找到了并且和当前被锁对象一样，获取当前线程被锁几回的lockCount。
如当前是 ACQUIRE （也就是 objc_sync_enter调用的）那说明在当前线程上对象又被锁了一次，锁的次数加+1。更新tls中存储的obj信息。并返回
如当前是 RELEASE （也就是 objc_sync_exit）发起的调用，那说明在当前线程上的被锁任务应该 -1 。更新tls中存储的obj信息。并返回
如在tls中并未找到，那么进入第二步

第二步：在线程缓存中SyncCache中查找是否存在obj的数据信息

#endif
  
   /// //检查已拥有锁的每个线程缓存是否匹配对象
    // 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;

            // Found a match. ///找到了当前对象所关联的线程。
            result = item->data;
            /// 如果 当前对象所关联的 线程总数 小于等于0
            /// 或 当前对象所关联的线程 锁任务的个数小于等于0 程序bug
            if (result->threadCount <= 0  ||  item->lockCount <= 0) {
                _objc_fatal("id2data cache is buggy");
            }
                
            switch(why) {
            case ACQUIRE: ///进行中
                item->lockCount++; ///当前线程任务数+1
                break;
            case RELEASE:///释放中
                item->lockCount--; ///当前线程任务数 -1
                if (item->lockCount == 0) { ///当前线程加锁任务 为 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 。
如当前是 ACQUIRE （也就是 objc_sync_enter调用的）那说明在当前线程上对象又被锁了一次，锁的次数(lockCount)加+1。
如当前是 RELEASE （也就是 objc_sync_exit）发起的调用，那说明在当前线程上的被锁任务次数标识（lockCount）应该 -1 。如果当前线程上的任务数为0 那么移除线程缓存
如在线程缓存中也没有那么进入第三步

这里看一下缓存结构(SyncCache )及缓存对象结构(SyncCacheItem)

///线程缓存
typedef struct SyncCache {
unsigned int allocated;
unsigned int used;
SyncCacheItem list[0];
} SyncCache;
///缓存对象item
typedef struct {
SyncData *data;
unsigned int lockCount;  // number of times THIS THREAD locked >this block
} SyncCacheItem;

第三步：使用列表 sDataLists中查找对象，并做处理

    // 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.
    ///线程缓存没有找到任何东西。，需要遍历每个线程，沿着nextData递归查找
    ///上锁
    lockp->lock();

    {
        SyncData* p;
        SyncData* firstUnused = NULL;
      
        ///遍历跟当前object相关的 所有线程任务
        for (p = *listp; p != NULL; p = p->nextData) {
            ///再次判断是否是当前 object
            if ( p->object == object ) {
                result = p;//找到赋值
                 //原子操作 可能会和 并发 释放 冲突
                // atomic because may collide with concurrent RELEASE
                OSAtomicIncrement32Barrier(&result->threadCount);
                goto done;//跳出
            }
            ///没找到与当前objc关联的锁任务线程 更新第一个没有使用的线程
            if ( (firstUnused == NULL) && (p->threadCount == 0) )
                firstUnused = p;
        }
        //当前没有与对象关联的SyncData
        // 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;///将当前对象存入 object
            result->threadCount = 1;//只有一个线程加锁
            goto done;
        }
    }

    //分配一个新的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.
    //分配一个新的SyncData并添加到列表。
    // XXX用持有的全局锁分配内存是不好的做法，
    //可能值得释放锁、重新分配和搜索。
    //但由于我们从来没有释放这些，我们就不会经常陷入分配的困境。
    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);
    result->nextData = *listp;
    *listp = result;
    
 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
        if (!fastCacheOccupied) {
            // Save in fast thread cache ///存入 tls
            tls_set_direct(SYNC_DATA_DIRECT_KEY, result);
            tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)1);
        } else 
#endif
        {
            // 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;
}

在列表sDataLists中查找，就需要对查找过程加锁防止多线程查找导致数据异常。使用列表 sDataLists把SyncData又做了一层封装，元素是一个结构体SyncList.

这里我们回到最上面看一下 *listp

 ///跟当前对象关联的所有的被锁线程中的锁任务的状态
spinlock_t *lockp = &LOCK_FOR_OBJ(object);
 ///跟当前对象关联的所有的被锁线程数据

SyncData **listp = &LIST_FOR_OBJ(object);
///进入 LOCK_FOR_OBJ 发现是一个宏
#define LOCK_FOR_OBJ(obj) sDataLists[obj].lock
#define LIST_FOR_OBJ(obj) sDataLists[obj].data
///sDataLists 是一个静态的 map 泛型为 SyncList 也就是key为object指针，value为SynLlist
static StripedMap<SyncList> sDataLists;

struct SyncList {
SyncData *data;
spinlock_t lock;

constexpr SyncList() : data(nil), lock(fork_unsafe_lock) { }
};

如找到，解锁，将数据写入tls ，写入线程缓存，并返回数据
如未找到，创建一个新的SyncData放入sDataLists中，并存入tls和线程缓存中然后返回

看完了objc_sync_enter 下面看 objc_sync_exit 锁的释放

// End synchronizing on 'obj'. ///根据obj结束 加锁
// Returns OBJC_SYNC_SUCCESS or OBJC_SYNC_NOT_OWNING_THREAD_ERROR
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函数，这里传进的是RELEASE
下面总结objc_sync_exit 函数的id2data做了什么事情

1、先从tls缓存中查找，如果找到，对锁的计数(lockCount)减1，更新缓存中的数据，如果当前对象对应的锁计数为0了，直接将其从tls缓存中删除。未找到进入2
2、从线程缓存SyncCache中查找，如果找到，对锁的计数减1，更新缓存中的数据，如果当前对象对应的锁计数为0了，直接将其从线程缓存SyncCache中删除。未找到进入3
3、从sDataLists查找，找到的话，直接将其置为nil。

总结

synchronized底层我们看到了有对同一条线程上的加锁任务计数lockCount。有使用此块的线程数的统计 threadCount
还看到了 SyncData对象中的 recursive_mutex_t。
由此可以下结论synchronized 是一把 递归互斥锁,
synchronized 进入代码块的入口为objc_sync_enter，出口为objc_sync_enter
如果@synchronized(nil)传入的为nil那么锁将不起任何作用
核心处理逻辑：
如支持tls缓存，就从tls缓存中查找对象SyncData,找到对lockCount进行相应操作。
如果不支持tls缓存，或者从tls缓存中未找到,就从线程缓存SyncCache中查找，同样如找到就对lockCount进行相应操作。
如缓存中没有找到，就从sDataLists链表中查找，找到后进行相关操作，并写入tls缓存和线程缓存SyncCache.
都没找到，创建一个节点，将对象锁SyncData插入sDataLists，并写入缓存.