锁的种类
借用网上的一张有关锁性能的对比图，如下所示：
从上图中我们可以看出来，锁大概可以分为以下几种：
1.：在自旋锁中，线程会反复检查变量是否可用。由于线程这个过程中一致保持执行，所以是一种忙等待。 一旦获取了自旋锁，线程就会一直保持该锁，直到显式释放自旋锁。自旋锁避免了进程上下文的调度开销，因此对于线程只会阻塞很短时间的场合是有效的。对于iOS属性的修饰符atomic，自带一把自旋锁。
常见的有：、os_unfair_lock、
2.：互斥锁是一种用于多线程编程中，防止两条线程同时对同一公共资源（例如全局变量）进行读写的机制，该目的是通过将代码切成一个个临界区而达成。
常见的有：、、pthread_mutex
3.:条件锁就是条件变量，当进程的某些资源要求不满足时就进入休眠，即锁住了，当资源被分配到了，条件锁打开了，进程继续运行
常见的有：、
4.：递归锁就是同一个线程可以加锁N次而不会引发死锁。递归锁是特殊的互斥锁，即是带有递归性质的互斥锁
常见的有：pthread_mutex(recursive)、
5.：信号量是一种更高级的同步机制，互斥锁可以说是semaphore在仅取值0/1时的特例，信号量可以有更多的取值空间，用来实现更加复杂的同步，而不单单是线程间互斥
常见的有：dispatch_semaphore
6.：读写锁实际是一种特殊的自旋锁。将对共享资源的访问分成读者和写者，读者只对共享资源进行读访问，写者则需要对共享资源进行写操作。这种锁相对于自旋锁而言，能提高并发性
一个读写锁同时只能有一个写者或者多个读者，但不能既有读者又有写者，在读写锁保持期间也是抢占失效的
如果读写锁当前没有读者，也没有写者，那么写者可以立刻获得读写锁，否则它必须自旋在那里， 直到没有任何写者或读者。如果读写锁没有写者，那么读者可以立
其实基本的锁就包括三类：自旋锁、互斥锁、读写锁，其他的比如条件锁、递归锁、信号量都是上层的封装和实现
OSSpinLock（自旋锁）
自从OSSpinLock出现安全问题，在iOS10之后就被废弃了。自旋锁之所以不安全，是因为获取锁后，线程会一直处于忙等待，造成了任务的优先级反转。
其中的忙等待机制可能会造成高优先级任务一直running等待，占用时间片，而低优先级的任务无法抢占时间片，会造成一直不能完成，锁未释放的情况
在OSSpinLock被弃用后，其替代方案是内部封装了os_unfair_lock，而os_unfair_lock在加锁时会处于休眠状态，而不是自旋锁的忙等状态
synchronized(互斥递归锁)探索
开启汇编调试，发现@synchronized在执行过程中，会走底层的objc_sync_enter 和 objc_sync_exit方法
通过对objc_sync_enter方法符号断点，查看底层所在的源码库，通过断点发现在objc源码中，即libobjc.A.dylib
objc_sync_enter & objc_sync_exit 分析
进入oc源码查看objc_sync_enter实现
- 如果obj存在，则通过id2data方法获取相应的SyncData，对threadCount、lockCount进行递增操作
- 如果obj不存在，则调用objc_sync_nil，通过符号断点得知，这个方法里面什么都没做，直接return了
int objc_sync_enter(id obj)
{
int result = OBJC_SYNC_SUCCESS;
if (obj) {//传入不为nil
SyncData* data = id2data(obj, ACQUIRE);//重点
ASSERT(data);
data->mutex.lock();//加锁
} else {//传入nil
// @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;
}
进入objc_sync_exit源码实现
- 如果obj存在，则调用id2data方法获取对应的SyncData，对threadCount、lockCount进行递减操作
- 如果obj为nil，什么也不做
// 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) {//obj不为nil
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;
}
通过上面两个实现逻辑的对比，发现它们有一个共同点，在obj存在时，都会通过id2data方法，获取SyncData
- 进入SyncData的定义，是一个结构体，主要用来表示一个线程data，类似于链表结构，有next指向，且封装了recursive_mutex_t属性，可以确认@synchronized确实是一个递归互斥锁
typedef struct alignas(CacheLineSize) SyncData {
struct SyncData* nextData;//类似链表结构
DisguisedPtr object;
int32_t threadCount; // number of THREADS using this block
recursive_mutex_t mutex;//递归锁
} SyncData;
- 进入SyncCache的定义，也是一个结构体，用于存储线程，其中list[0]表示当前线程的链表data，主要用于存储SyncData和lockCount
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;
id2data 分析
- 进入id2data源码，从上面的分析，可以看出，这个方法是加锁和解锁都复用的方法
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 //tls（Thread Local Storage，本地局部的线程缓存）
// Check per-thread single-entry fast cache for matching object
bool fastCacheOccupied = NO;
//通过KVC方式对线程进行获取 线程绑定的data
SyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY);
//如果线程缓存中有data，执行if流程
if (data) {
fastCacheOccupied = YES;
//如果在线程空间找到了data
if (data->object == object) {
// Found a match in fast cache.
uintptr_t lockCount;
result = data;
//通过KVC获取lockCount，lockCount用来记录 被锁了几次，即 该锁可嵌套
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: {
//objc_sync_enter走这里，传入的是ACQUIRE -- 获取
lockCount++;//通过lockCount判断被锁了几次，即表示 可重入（递归锁如果可重入，会死锁）
tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);//设置
break;
}
case RELEASE:
//objc_sync_exit走这里，传入的why是RELEASE -- 释放
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
// Check per-thread cache of already-owned locks for matching object
SyncCache *cache = fetch_cache(NO);//判断缓存中是否有该线程
//如果cache中有，方式与线程缓存一致
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;
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中清除使用标记
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;
}
}
// 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;
for (p = *listp; p != NULL; p = p->nextData) {//cache中已经找到
if ( p->object == object ) {//如果不等于空，且与object相似
result = p;//赋值
// atomic because may collide with concurrent RELEASE
OSAtomicIncrement32Barrier(&result->threadCount);//对threadCount进行++
goto done;
}
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 第一次进来，没有找到
if ( firstUnused != NULL ) {
result = firstUnused;
result->object = (objc_object *)object;
result->threadCount = 1;
goto done;
}
}
// 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 (&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) { //判断是否支持栈存缓存，支持则通过KVC形式赋值 存入tls
// Save in fast thread cache
tls_set_direct(SYNC_DATA_DIRECT_KEY, result);
tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)1);//lockCount = 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;
}
第一步、首先在tls即线程缓存中查找。
在tls_get_direct方法中以线程为key，通过KVC的方式获取与之绑定的SyncData，即线程data。其中的tls（），表示本地局部的线程缓存，
判断获取的data是否存在，以及判断data中是否能找到对应的object
如果都找到了，在tls_get_direct方法中以KVC的方式获取lockCount，用来记录对象被锁了几次（即锁的嵌套次数）
如果data中的threadCount 小于等于0，或者 lockCount 小于等于0时，则直接崩溃
通过传入的why，判断是操作类型
如果是ACQUIRE，表示加锁，则进行lockCount++，并保存到tls缓存
如果是RELEASE，表示释放，则进行lockCount--，并保存到tls缓存。如果lockCount 等于 0，从tls中移除线程data
如果是CHECK，则什么也不做
第二步、如果tls中没有，则在cache缓存中查找
通过fetch_cache方法查找cache缓存中是否有线程
如果有，则遍历cache总表，读取出线程对应的SyncCacheItem
从SyncCacheItem中取出data，然后后续步骤与tls的匹配是一致的
第三步、如果cache中也没有，即第一次进来，则创建SyncData，并存储到相应缓存中
- 如果在cache中找到线程，且与object相等，则进行赋值、以及threadCount++
- 如果在cache中没有找到，则threadCount等于1
所以在id2data方法中，主要分为三种情况
【第一次进来，没有锁】：
threadCount = 1
lockCount = 1
存储到tls
【不是第一次进来，且是同一个线程】
tls中有数据，则lockCount++
存储到tls
【不是第一次进来，且是不同线程】
全局线程空间进行查找线程
threadCount++
lockCount++
存储到cache
tls和cache表结构
针对tls和cache缓存，底层的表结构如下：
哈希表结构中通过SyncList结构来组装多线程的情况
SyncData通过链表的形式组装当前可重入的情况
下层通过tls线程缓存、cache缓存来进行处理
底层主要有两个东西：lockCount、threadCount,解决了递归互斥锁，解决了嵌套可重入
总结
@synchronized在底层封装的是一把递归锁，所以这个锁是递归互斥锁
@synchronized的可重入，即可嵌套，主要是由于lockCount 和 threadCount的搭配
@synchronized使用链表的原因是链表方便下一个data的插入，但是由于底层中链表查询、缓存的查找以及递归，是非常耗内存以及性能的，导致性能低，所以在前文中，该锁的排名在最后,但是目前该锁的使用频率仍然很高，主要是因为方便简单，且不用解锁
不能使用非OC对象作为加锁对象，因为其object的参数为id@synchronized (self)这种适用于嵌套次数较少的场景。这里锁住的对象也并不永远是self，这里需要读者注意
如果锁嵌套次数较多，即锁self过多，会导致底层的查找非常麻烦，因为其底层是链表进行查找，所以会相对比较麻烦，所以此时可以使用NSLock、信号量等
NSLock 底层分析
-
通过加符号断点lock分析，发现其源码在Foundation框架中
image.jpg 由于OC的Foundation框架不开源，所以这里借助Swift的开源框架Foundation来 分析NSLock的底层实现，其原理与OC是大致相同的
通过源码实现可以看出，底层是通过pthread_mutex互斥锁实现的。并且在init方法中，还做了一些其他操作，所以在使用NSLock时需要使用init初始化
回到前文的性能图中，可以看出NSLock的性能仅次于 pthread_mutex（互斥锁），非常接近
** 使用弊端 **
请问下面block嵌套block的代码中，会有什么问题？
for (int i= 0; i<100; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
static void (^testMethod)(int);
testMethod = ^(int value){
if (value > 0) {
NSLog(@"current value = %d",value);
testMethod(value - 1);
}
};
testMethod(10);
});
}
-
在未加锁之前，其中的current=9、10有很多条，导致数据混乱，主要原因是多线程导致的
image.jpg 如果像下面这样加锁，会有什么问题？
NSLock *lock = [[NSLock alloc] init];
for (int i= 0; i<100; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
static void (^testMethod)(int);
testMethod = ^(int value){
[lock lock];
if (value > 0) {
NSLog(@"current value = %d",value);
testMethod(value - 1);
}
};
testMethod(10);
[lock unlock];
});
}
会出现一直等待的情况，主要是因为嵌套使用的递归，使用NSLock（简单的互斥锁，如果没有回来，会一直睡觉等待），即会存在一直加lock，等不到unlock 的堵塞情况
所以，针对这种情况，可以使用以下方式解决
- 使用@synchronized
for (int i= 0; i<100; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
static void (^testMethod)(int);
testMethod = ^(int value){
@synchronized (self) {
if (value > 0) {
NSLog(@"current value = %d",value);
testMethod(value - 1);
}
}
};
testMethod(10);
});
}
- 使用递归锁NSRecursiveLock
NSRecursiveLock *recursiveLock = [[NSRecursiveLock alloc] init];
for (int i= 0; i<100; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
static void (^testMethod)(int);
[recursiveLock lock];
testMethod = ^(int value){
if (value > 0) {
NSLog(@"current value = %d",value);
testMethod(value - 1);
}
[recursiveLock unlock];
};
testMethod(10);
});
}
NSRecursiveLock
-
NSRecursiveLock在底层也是对pthread_mutex的封装，可以通过swift的Foundation源码查看
image.jpg
对比NSLock 和 NSRecursiveLock，其底层实现几乎一模一样，区别在于init时，NSRecursiveLock有一个标识PTHREAD_MUTEX_RECURSIVE，而NSLock是默认的
锁的使用场景
如果只是简单的使用，例如涉及线程安全，使用NSLock即可
如果是循环嵌套，推荐使用@synchronized，主要是因为使用递归锁的 性能 不如 使用@synchronized的性能（因为在synchronized中无论怎么重入，都没有关系，而NSRecursiveLock可能会出现崩溃现象）
在循环嵌套中，如果对递归锁掌握的很好，则建议使用递归锁，因为性能好
如果是循环嵌套，并且还有多线程影响时，例如有等待、死锁现象时，建议使用@synchronized