-
【互斥锁】:用于多线程编程中,防止多条线程对统一资源读写,通过
将代码切割成一个个临界区
而达成- @synchronized
- NSLock
- pthread_mutex
-
【自旋锁】:线程会一直检测锁变量是否可用,因为线程在这过程一直保持执行,所以线程会处于
忙等
状态,一旦获取了自旋锁,线程会一直持有该锁,直至显式释放自旋锁。- OSSpinLock
- atomic
-
【条件锁】
条件变量
,当进程中的某些资源要求不满足时就进入休眠,加锁,当资源分配到了就解锁,继续运行- NSCondition
- pthread_mutex
-
【递归锁】
同一线程可以加锁很多次而不会死锁
,带有递归性质的互斥锁
-
【信号量】更高的的同步机制,
互斥锁
可以说是semaphore在仅取值0/1时的特例
,信号量可以有更多的取值空间来实现更加复杂的同步机制,而不是简单的线程互斥 -
【读写锁】特殊的
自旋锁
,并发性更高
OSSpinLock(自旋锁) --> dispatch_semaphore(信号量) --> phread_mutex(互斥锁) --> NSLock(互斥锁) --> NSCondition(条件锁) --> pthread_mutex(recursive)(互斥递归锁) --> NSRecursiveLock(递归锁) --> NSConditionLock(条件锁) --> @synchronized(互斥锁)
1、OSSpinLock(自旋锁)
自从OSSpinLock出现安全问题,在iOS10之后就被废弃了。自旋锁之所以不安全,是因为获取锁后,线程会一直处于忙等待
,造成了任务的优先级反转
。
其中的忙等待机制可能会造成高优先级任务一直running等待,占用时间片,而低优先级的任务无法抢占时间片,会造成一直不能完成,锁未释放的情况
在OSSpinLock被弃用后,其替代方案是内部封装了os_unfair_lock
,而os_unfair_lock在加锁时
会处于休眠状态
,而不是自旋锁的忙等状态
2、atomic
atomic
是OC中的属性修饰符,自旋锁
,在mac开发中使用的多
setter方法
在底层中setter
方法会根据不同的属性修饰符调用不同方法,最后会统一调用reallySetProperty
方法
static inline void reallySetProperty(id self, SEL _cmd, id newValue, ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
...
id *slot = (id*) ((char*)self + offset);
...
if (!atomic) {//未加锁
oldValue = *slot;
*slot = newValue;
} else {//加锁
spinlock_t& slotlock = PropertyLocks[slot];
slotlock.lock();
oldValue = *slot;
*slot = newValue;
slotlock.unlock();
}
...
}
对于atomic
修饰的属性,会进行spinlock
加锁,spinlock
在底层抛弃以前的OSSpinLock
,使用os_unfair_lock
替代实现加锁,同时为了防止哈希冲突
,实现了加盐
using spinlock_t = mutex_tt<LOCKDEBUG>;
class mutex_tt : nocopy_t {
os_unfair_lock mLock;
...
}
getter方法
getter
方法对于atomic
的处理和setter
一样
id objc_getProperty(id self, SEL _cmd, ptrdiff_t offset, BOOL atomic) {
if (offset == 0) {
return object_getClass(self);
}
// Retain release world
id *slot = (id*) ((char*)self + offset);
if (!atomic) return *slot;
// Atomic retain release world
spinlock_t& slotlock = PropertyLocks[slot];
slotlock.lock();//加锁
id value = objc_retain(*slot);
slotlock.unlock();//解锁
// for performance, we (safely) issue the autorelease OUTSIDE of the spinlock.
return objc_autoreleaseReturnValue(value);
}
3、@synchronize(互斥递归锁)
-
通过汇编调试,可以发现
image.png@synchronize
在执行过程中,从objc_sync_enter
开始到objc_sync_exit
结束
-
通过
image.pngclang
查看底层编译
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不存在,直接return
// 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;
}
SyncData分析
SyncData
是一个结构体,表示一个线程data
,类似链表结构
,有next指向,封装了recursive_mutex_t
属性,从而确定@ synchronized
是一个递归互斥锁
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;
SyncCache分析
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
该方法加锁和解锁
的复用
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_get_direct
方法中传入线程Key
,通过KVC
的方式获得绑定的SyncData
,其中tls()
表示本地局部的线程缓存
- 判断获取的
线程data是否存在
,以及线程data中是否能找到对应的object
- 如果存在,在
tls_get_direct
方法中通过KVC
方法获取lockCount
,记录对象被锁几次
(锁的嵌套次数) - 如果线程data中
threadCount <= 0
或者lockCount <= 0
,直接奔溃 - 通过传入的
why
判断操作类型- 如果是
ACQUIRE
,加锁,lockCount++
,保存到线程缓存中 - 如果是
RELEASE
,解锁,lockCount--
,保存到线程缓存中,如果lockCount==0
,从线程缓存中移除 - 如果是
CHECK
,什么也不做,直接return
- 如果是
- 在
-
【第二步】在
cache缓存
中查找- 通过
fetch_cache
方法查找cache缓存
中是否有线程 - 如果有,遍历
cache总表
,对出线程对应的SyncCacheItem
- 从
SyncCacheItem
中取出线程data - 判断线程data的后续操作和【第一步】判断一致
- 通过
-
【第三步】如果cache中也没有,即
第一次进来
,创建SyncData
,并存储到线程缓存中- 如果cache中找到线程,且与object相等,则进行赋值、threadCount++
- 如果cache没有找到线程,threadCount==1
总结
-
@synchronized·在底层通过
lockCount、threadCount,解决了递归互斥锁和嵌套可重用,所以这个锁是
递归互斥锁` -
使用
链表
结构,方便下一个data插入 -
由于底层中有
链表查询、缓存查询和递归
,所有内存和性能
开销大,所有如果嵌套次数过多
,会导致底层查找麻烦,非常耗费性能
,但是使用简单,不用手动解锁
-
不能使用
非oc对象
加锁,加锁对象应该一直存在内存中
,不能中途释放,否则会奔溃
-
底层流程
-
【第一次进入,没有锁】
threadCount = 1、lockCount = 1
- 存储到
tls线程缓存
-
【不是第一次进入,且是同一个线程】
- 当
tls线程缓存
中有数据,则lockCount++
- 存储到
tls线程缓存
- 当
-【不是第一次进入,且是不同线程】
- 根据线程Key
在全局线程空间
查找对应线程
-threadCount ++、lockCount++
- 存储到cache
-
NSLock
NSLock底层是封装了pthread_mutex
,遵循了NSLocking
协议,使用如下
NSLock *lock = [[NSLock alloc] init];
[lock lock];
[lock unlock];
- NSLock是简单的
互斥锁
,不能嵌套递归使用
,不然会出现一直等待的情况
NSRecursiveLock
NSRecursiveLock
是递归互斥锁
, 用于解决循环嵌套
,在底层也是对pthread_mutex
的封装,底层实现和NSLock
一致,区别在init
时候,NSRecursiveLock
的标识是PTHREAD_MUTEX_RECURSIVE
,而NSLock
的标识是默认的
pthread_mutex
pthread_mutex
是互斥锁
,当锁被占用,其他线程申请锁时,不会一直忙等待,而是阻塞线程并睡眠
,需要自己手动释放锁和维护线程安全
// 导入头文件
#import <pthread.h>
// 全局声明互斥锁
pthread_mutex_t _lock;
// 初始化互斥锁
pthread_mutex_init(&_lock, NULL);
// 加锁
pthread_mutex_lock(&_lock);
// 这里做需要线程安全操作
// 解锁
pthread_mutex_unlock(&_lock);
// 释放锁
pthread_mutex_destroy(&_lock);
NSCondition
NSCondition
是条件锁
,和信号量
类似,线程需要满足条件才会继续执行,否则会堵塞等待,线程进入休眠,直到条件满足,常用于生成消费者模型
-
NSCondition对象
实际是一个锁
和一个线程检测器
-
锁
:检测条件时保护数据源,执行条件时引发任务 -
线程检测器
:根据条件决定是否继续执行线程,否则阻塞
-
- 底层也是
pthread_mutex
的封装-
NSCondition
是对mutex
和cond
的一种封装(cond是一种用于访问和操作特定类型数据的指针)
-
//初始化
NSCondition *condition = [[NSCondition alloc] init]
//一般用于多线程同时访问、修改同一个数据源,保证在同一 时间内数据源只被访问、修改一次,其他线程的命令需要在lock 外等待,只到 unlock ,才可访问
[condition lock];
//与lock 同时使用
[condition unlock];
//让当前线程处于等待状态
[condition wait];
//CPU发信号告诉线程不用在等待,可以继续执行
[condition signal];
NSConditionLock
NSConditionLock
是条件锁
,一旦一个线程获得锁,其他线程一定等待,其本质是NSCondition + Lock
,是对NSCondition
的封装,可以设置锁条件
,而NSCondition
只是信号的通知
//初始化
NSConditionLock *conditionLock = [[NSConditionLock alloc] initWithCondition:2];
//表示 conditionLock 期待获得锁,如果没有其他线程获得锁(不需要判断内部的 condition) 那它能执行此行以下代码,如果已经有其他线程获得锁(可能是条件锁,或者无条件 锁),则等待,直至其他线程解锁
[conditionLock lock];
//表示如果没有其他线程获得该锁,但是该锁内部的 condition不等于A条件,它依然不能获得锁,仍然等待。如果内部的condition等于A条件,并且 没有其他线程获得该锁,则进入代码区,同时设置它获得该锁,其他任何线程都将等待它代码的 完成,直至它解锁。
[conditionLock lockWhenCondition:A条件];
//表示释放锁,同时把内部的condition设置为A条件
[conditionLock unlockWithCondition:A条件];
// 表示如果被锁定(没获得 锁),并超过该时间则不再阻塞线程。但是注意:返回的值是NO,它没有改变锁的状态,这个函 数的目的在于可以实现两种状态下的处理
return = [conditionLock lockWhenCondition:A条件 beforeDate:A时间];
//其中所谓的condition就是整数,内部通过整数比较条件
锁性能总结
-
OSSpinLock自旋锁
由于安全性问题,在iOS10之后已经被废弃,在底层使用os_unfair_lock
替代-
OSSpinLock
:线程会处于忙等状态
-
os_unfair_lock
:线程会处于休眠状态
-
-
atomic原子锁
,自带自旋锁
,保证setter、getter
方法的线程安全- 属性在调用setter、getter方法时,会自动加锁
osspinlock自旋锁
,避免属性读写不同步
- 属性在调用setter、getter方法时,会自动加锁
-
@synchronized
在底层维护了一个哈希表
用来存在线程data,通过链表
表示可重用(嵌套)
特性,性能低
,但是简单好用,多线程下适用性强 -
NSLock、NSRecursiveLock
是互斥锁,底层都是对pthread_mutex
的封装,区别在于init
时的标识符不一样
,NSLock
不能用于嵌套递归
,而NSRecursiveLock
可以 -
NSCondition 、NSConditionLock
是条件锁,底层都是对pthread_mutex
的封装,当满足某一个条件时才能进行操作,和信号量dispatch_semaphore
类似
网友评论