锁性能分析
iPhone 12真机测试,锁的性能数据对比图
性能从高到低排序:OSSpinLock
(自旋锁)>os_unfair_lock
(自旋锁)>NSCondition
(条件锁)>pthread_mutex
(互斥锁)>NSLock
(互斥锁)>dispatch_semaphore_t
(信号量)>pthread_mutex_t(recursive)
(递归锁)>NSRecursiveLock
(递归锁)>@synchronized
(互斥锁)>NSConditionLock
(条件锁)
测试方案
循环十万次,进行加锁解锁
操作,计算耗时
int kc_runTimes = 100000;
{
OSSpinLock kc_spinlock = OS_SPINLOCK_INIT;
double_t kc_beginTime = CFAbsoluteTimeGetCurrent();
for (int i=0 ; i < kc_runTimes; i++) {
OSSpinLockLock(&kc_spinlock); //解锁
OSSpinLockUnlock(&kc_spinlock);
}
double_t kc_endTime = CFAbsoluteTimeGetCurrent() ;
KCLog(@"OSSpinLock: %f ms",(kc_endTime - kc_beginTime)*1000);
}
{
dispatch_semaphore_t kc_sem = dispatch_semaphore_create(1);
double_t kc_beginTime = CFAbsoluteTimeGetCurrent();
for (int i=0 ; i < kc_runTimes; i++) {
dispatch_semaphore_wait(kc_sem, DISPATCH_TIME_FOREVER);
dispatch_semaphore_signal(kc_sem);
}
double_t kc_endTime = CFAbsoluteTimeGetCurrent() ;
KCLog(@"dispatch_semaphore_t: %f ms",(kc_endTime - kc_beginTime)*1000);
}
{
os_unfair_lock kc_unfairlock = OS_UNFAIR_LOCK_INIT;
double_t kc_beginTime = CFAbsoluteTimeGetCurrent();
for (int i=0 ; i < kc_runTimes; i++) {
os_unfair_lock_lock(&kc_unfairlock);
os_unfair_lock_unlock(&kc_unfairlock);
}
double_t kc_endTime = CFAbsoluteTimeGetCurrent() ;
KCLog(@"os_unfair_lock_lock: %f ms",(kc_endTime - kc_beginTime)*1000);
}
{
pthread_mutex_t kc_metext = PTHREAD_MUTEX_INITIALIZER;
double_t kc_beginTime = CFAbsoluteTimeGetCurrent();
for (int i=0 ; i < kc_runTimes; i++) {
pthread_mutex_lock(&kc_metext);
pthread_mutex_unlock(&kc_metext);
}
double_t kc_endTime = CFAbsoluteTimeGetCurrent() ;
KCLog(@"pthread_mutex_t: %f ms",(kc_endTime - kc_beginTime)*1000);
}
{
NSLock *kc_lock = [NSLock new];
double_t kc_beginTime = CFAbsoluteTimeGetCurrent();
for (int i=0 ; i < kc_runTimes; i++) {
[kc_lock lock];
[kc_lock unlock];
}
double_t kc_endTime = CFAbsoluteTimeGetCurrent() ;
KCLog(@"NSlock: %f ms",(kc_endTime - kc_beginTime)*1000);
}
{
NSCondition *kc_condition = [NSCondition new];
double_t kc_beginTime = CFAbsoluteTimeGetCurrent();
for (int i=0 ; i < kc_runTimes; i++) {
[kc_condition lock];
[kc_condition unlock];
}
double_t kc_endTime = CFAbsoluteTimeGetCurrent() ;
KCLog(@"NSCondition: %f ms",(kc_endTime - kc_beginTime)*1000);
}
{
pthread_mutex_t kc_metext_recurive;
pthread_mutexattr_t attr;
pthread_mutexattr_init (&attr);
pthread_mutexattr_settype (&attr, PTHREAD_MUTEX_RECURSIVE);
pthread_mutex_init (&kc_metext_recurive, &attr);
double_t kc_beginTime = CFAbsoluteTimeGetCurrent();
for (int i=0 ; i < kc_runTimes; i++) {
pthread_mutex_lock(&kc_metext_recurive);
pthread_mutex_unlock(&kc_metext_recurive);
}
double_t kc_endTime = CFAbsoluteTimeGetCurrent() ;
KCLog(@"PTHREAD_MUTEX_RECURSIVE: %f ms",(kc_endTime - kc_beginTime)*1000);
}
{
NSRecursiveLock *kc_recursiveLock = [NSRecursiveLock new];
double_t kc_beginTime = CFAbsoluteTimeGetCurrent();
for (int i=0 ; i < kc_runTimes; i++) {
[kc_recursiveLock lock];
[kc_recursiveLock unlock];
}
double_t kc_endTime = CFAbsoluteTimeGetCurrent() ;
KCLog(@"NSRecursiveLock: %f ms",(kc_endTime - kc_beginTime)*1000);
}
{
NSConditionLock *kc_conditionLock = [NSConditionLock new];
double_t kc_beginTime = CFAbsoluteTimeGetCurrent();
for (int i=0 ; i < kc_runTimes; i++) {
[kc_conditionLock lock];
[kc_conditionLock unlock];
}
double_t kc_endTime = CFAbsoluteTimeGetCurrent() ;
KCLog(@"NSConditionLock: %f ms",(kc_endTime - kc_beginTime)*1000);
}
{
double_t kc_beginTime = CFAbsoluteTimeGetCurrent();
for (int i=0 ; i < kc_runTimes; i++) {
@synchronized(self) {}
}
double_t kc_endTime = CFAbsoluteTimeGetCurrent() ;
KCLog(@"@synchronized: %f ms",(kc_endTime - kc_beginTime)*1000);
}
iphone12真机执行结果
OSSpinLock: 0.485063 ms
dispatch_semaphore_t: 0.717044 ms
os_unfair_lock_lock: 0.768065 ms
pthread_mutex_t: 0.838041 ms
NSlock: 1.092076 ms
NSCondition: 1.066923 ms
PTHREAD_MUTEX_RECURSIVE: 1.288056 ms
NSRecursiveLock: 1.695037 ms
NSConditionLock: 5.481005 ms
@synchronized: 3.665924 ms
@synchronized
执行速度并不是最慢的,系统对其进行了优化。
iphone12模拟器执行结果
OSSpinLock: 0.509977 ms
dispatch_semaphore_t: 0.768065 ms
os_unfair_lock_lock: 0.856042 ms
pthread_mutex_t: 1.099944 ms
NSlock: 1.405954 ms
NSCondition: 1.512051 ms
PTHREAD_MUTEX_RECURSIVE: 1.899004 ms
NSRecursiveLock: 3.090978 ms
NSConditionLock: 4.673004 ms
@synchronized: 5.235076 ms
模拟器运行结果和真机相比,模拟器中@synchronized
的效率低了不少,原因是系统底层
在真机和模拟器上的处理有一些差异。下面对其分析......
synchronized的原理分析上
比如售票系统,异步会产生线程安全问题,我们可以添加@synchronized
锁来解决。对于@synchronized
锁的使用,我们有几个疑问?
-
@synchronized (参数)
,这里的参数该传什么?一般会传self
,那么传self
的意义是什么? -
@synchronized (参数)
,参数可以传nil吗?传nil的话会有什么结果? -
@synchronized (参数) { }
是个代码块,这个代码块到底是什么? -
@synchronized (参数)
可以起到加锁的效果,并且能够起到递归可重入
的效果,递归可重入
是什么样的结构?简单理解递归可重入
就是锁里面嵌套锁
@synchronized有两种方式进行探索
clang编译出C++代码
汇编跟源码
clang编译出C++代码
int main(int argc, char * argv[]) {
NSString * appDelegateClassName;
@autoreleasepool {
// Setup code that might create autoreleased objects goes here.
appDelegateClassName = NSStringFromClass([AppDelegate class]);
@synchronized (appDelegateClassName) {
}
}
return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}
xcrun -sdk iphonesimulator clang -arch arm64 -rewrite-objc main.m -o main.cpp
- 查看
main.cpp
代码
int main(int argc, char * argv[]) {
NSString * appDelegateClassName;
/* @autoreleasepool */ { __AtAutoreleasePool __autoreleasepool;
appDelegateClassName = NSStringFromClass(((Class (*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("AppDelegate"), sel_registerName("class")));
{
id _rethrow = 0;
id _sync_obj = (id)appDelegateClassName;
objc_sync_enter(_sync_obj);
try {
struct _SYNC_EXIT {
_SYNC_EXIT(id arg) : sync_exit(arg) {}
~_SYNC_EXIT() {
objc_sync_exit(sync_exit);}
id sync_exit;
}
} catch (id e) {_rethrow = e;}
{
struct _FIN { _FIN(id reth) : rethrow(reth) {}
~_FIN() { if (rethrow) objc_exception_throw(rethrow); }
id rethrow;
} _fin_force_rethow(_rethrow);}
}
}
return UIApplicationMain(argc, argv, __null, appDelegateClassName);
}
通过分析main.cpp文件,发现@synchronized (appDelegateClassName){}
执行了objc_sync_enter
与objc_sync_exit
方法
- 调用
_sync_exit
传入_sync_obj
,相当于调用结构体的构造函数
和析构函数
。构造函数中没有代码,而析构函数中调用objc_sync_exit
函数,传入的sync_exit
等同于_sync_obj
使用objc_sync_enter(_sync_obj)
函数,进行加锁
使用objc_sync_exit(_sync_obj)
函数,进行解锁
- 使用
try...catch
,说明锁的使用有可能出现异常
通过汇编追踪
在main函数
中设置断点,查看汇编代码:
-
objc_sync_enter
和objc_sync_exit
函数成对出现,分别进行加锁
和解锁
操作
image.png -
添加符号断点查看
image.png
发现这两个函数来自于libobjc.A.dylib
sync的原理分析-synData的结构
- 打开
objc4-818.2
源码,查看objc_sync_enter
函数
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
,对threadCount
、lockCount
进行递增操作
。 - 否则,执行
objc_sync_nil
函数;
- 查看
进入objc_sync_nil
方法
BREAKPOINT_FUNCTION(
void objc_sync_nil(void)
);
# define BREAKPOINT_FUNCTION(prototype) \
OBJC_EXTERN __attribute__((noinline, used, visibility("hidden"))) \
prototype { asm(""); }
objc_sync_nil
中的代码,相当于将void objc_sync_nil(void)
传入宏,等同于void objc_sync_nil(void) { }
无效代码不进行加锁操作。这里就解答了上面传入nil
的问题,@synchronized (参数)
参数传nil
,什么都不做does nothing
- 查看
objc_sync_exit
方法
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;
}
- 如果
obj
存在,则调用id2data
方法获取对应的SyncData
,对threadCount
、lockCount
进行递减操作
。 - 如果obj为nil,什么也不做。
objc_sync_enter
和objc_sync_exit
中的核心代码都是id2data
函数,参数传入的ACQUIRE
和RELEASE
有所区别,但最终都获取到一个SyncData
对象。
- 在
objc_sync_enter
中,对SyncData
对象中的mutex
,调用lock
进行加锁; - 在
objc_sync_exit
中,对SyncData
对象中的mutex
,调用tryUnlock
进行解锁。
SyncData结构
- 查看
SyncData
定义
typedef struct alignas(CacheLineSize) SyncData {
// SyncData属于单项链表
struct SyncData* nextData;//指向下一条数据
DisguisedPtr object;//伪装,用于封装类型
int32_t threadCount; // number of THREADS using this block 多线程访问,记录多线程操作数
recursive_mutex_t mutex;//递归锁,可以递归使用,但不支持多线程递归
} SyncData;
通过SyncData
的结构可以看出@synchronized
为递归互斥锁
,支持多线程递归
使用,比recursive_mutex_t
更加强大。
synchronized整个数据结构
- 查看
id2data
方法
static SyncData* id2data(id object, enum usage why)
{
//1、传入object,从哈希表中获取数据
//传入object,从哈希表中获取lock,用于保证分配SyncData代码的线程安全
spinlock_t *lockp = &LOCK_FOR_OBJ(object);
//传入object,从哈希表中获取SyncData的地址,等同于SyncList
SyncData **listp = &LIST_FOR_OBJ(object);
SyncData* result = NULL;
#if SUPPORT_DIRECT_THREAD_KEYS
bool fastCacheOccupied = NO;
//2、在当前线程的tls(线程局部存储)中寻找
SyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY); // 通过KVC方式对线程进行获取 线程绑定的data
if (data) {
fastCacheOccupied = YES;
//SyncData中的对象和传入的对象相同
if (data->object == object) {
//可以进入到这里,应该是同一线程中对同一对象,进行嵌套@synchronized
uintptr_t lockCount;
result = data;
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: {
//锁的次数+1
lockCount++;
//存储到tls中
tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
break;
}
case RELEASE:
//锁的次数-1
lockCount--;
//存储到tls中
tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
if (lockCount == 0) {
//删除tls线程局部存储
tls_set_direct(SYNC_DATA_DIRECT_KEY, NULL);
//对SyncData对象的threadCount进行-1,因为当前线程中的对象已经解锁
OSAtomicDecrement32Barrier(&result->threadCount);
}
break;
case CHECK:
break;
}
return result;
}
}
#endif
//3、tls中未找到,在各自线程的缓存中查找
SyncCache *cache = fetch_cache(NO);
if (cache) {
unsigned int i;
//遍历缓存
for (i = 0; i < cache->used; i++) {
SyncCacheItem *item = &cache->list[i];
//item中的对象和传入的对象不一致,跳过
if (item->data->object != object) continue;
result = item->data;
if (result->threadCount <= 0 || item->lockCount <= 0) {
_objc_fatal("id2data cache is buggy");
}
switch(why) {
case ACQUIRE:
//锁的次数+1
item->lockCount++;
break;
case RELEASE:
//锁的次数-1
item->lockCount--;
if (item->lockCount == 0) {
//从缓存中删除
cache->list[i] = cache->list[--cache->used];
//对SyncData对象的threadCount进行-1,因为当前线程中的对象已经解锁
OSAtomicDecrement32Barrier(&result->threadCount);
}
break;
case CHECK:
// do nothing
break;
}
return result;
}
}
//加锁,保证下面分配SyncData代码的线程安全(第一次进来,所有缓存都找不到)
lockp->lock();
{
SyncData* p;
SyncData* firstUnused = NULL;
//4、遍历SyncList,如果无法遍历,证明当前object第一次进入,需要分配新的SyncData
for (p = *listp; p != NULL; p = p->nextData) {
//遍历如果链表中存在SyncData的object和传入的object相等
if ( p->object == object ) {
//将p赋值给result
result = p;
//对threadCount进行+1
OSAtomicIncrement32Barrier(&result->threadCount);
//跳转至done
goto done;
}
//找到一个未使用的SyncData
if ( (firstUnused == NULL) && (p->threadCount == 0) )
firstUnused = p;
}
//未找到与对象关联的SyncData,如果当前非ACQUIRE逻辑,直接进入done
if ( (why == RELEASE) || (why == CHECK) )
goto done;
//从SyncList中找到未使用的SyncData,进行覆盖
if ( firstUnused != NULL ) { //第一次进来,没有找到
//赋值给result
result = firstUnused;
result->object = (objc_object *)object;
result->threadCount = 1;
//跳转至done
goto done;
}
}
//5、分配一个新的SyncData并添加到SyncList中,并且支持内存对齐
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:
//解锁,保证上面分配SyncData代码的线程安全
lockp->unlock();
if (result) {
//一些错误处理,应该只有ACQUIRE时,产生新SyncData时进入这里
//所有的RELEASE和CHECK和递归ACQUIRE,都应该由上面的线程缓存处理
if (why == RELEASE) {
return nil;
}
if (why != ACQUIRE) _objc_fatal("id2data is buggy");
if (result->object != object) _objc_fatal("id2data is buggy");
//6、保存到tls线程或者缓存中
if (!fastCacheOccupied) {
//保存到当前线程的tls中
tls_set_direct(SYNC_DATA_DIRECT_KEY, result);
tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)1);
} else
#endif
{
//tls还在占用,保存到缓存
if (!cache) cache = fetch_cache(YES);
cache->list[cache->used].data = result;
cache->list[cache->used].lockCount = 1;
cache->used++;
}
}
return result;
}
主要步骤
- 传入
object
从哈希表中获取数据 - 在当前线程的
tls
(线程局部存储)中寻找 -
tls
中未找到,在各自线程的缓存中查找 - 遍历
SyncList
找到SyncData
,相当于在所有线程中寻址
- 分配一个新的
SyncData
并添加到SyncList
中 - 将
SyncData
保存到tls线程
或者缓存
中
- 查看
LOCK_FOR_OBJ
和LIST_FOR_OBJ
#define LOCK_FOR_OBJ(obj) sDataLists[obj].lock
#define LIST_FOR_OBJ(obj) sDataLists[obj].data
static StripedMap sDataLists;
-
sDataLists
是全局哈希表
,断点打印sDataLists
image.png SyncList
里面是SyncData
struct SyncList {
SyncData *data;
spinlock_t lock;
constexpr SyncList() : data(nil), lock(fork_unsafe_lock) { }
};
遵循下面拉链法
TLS线程相关解释
线程局部存储
(Thread Local Storage,TLS):是操作系统为线程单独提供的私有空间,通常只有有限的容量
Linux系统下通常使用pthread
库中的API
pthread_key_create()
pthread_getspecific()
pthread_setspecific()
pthread_key_delete()
synchronized的原理分析下
上面对id2data
方法已经分析过了,这里对synchronized
底层原理做一个总结
-
sDataLists
是一个全局哈希表
,采用的是拉链法
,拉链的是SyncData
- 拉链的过程中会形成
sDataLists
,里面存放的是SyncList
,SyncList
绑定了需要加锁的object
- 数据结构中封装了
objc_sync_enter
与objc_sync_exit
方法,这俩方法成对出现,里面封装的是系统底层递归锁 - 支持两种存储方式
tls
和cache
缓存 - 第一次执行的时候会创建
SyncData
,进行头插法
创建链表结构,并标记threadCount = 1
- 第二次执行的时候判断当前对象是不是同一个对象,如果是同一个对象,意味着
tls
中能够找到,会对lockCount ++
;如果tls
中找不到,重新创建SyncData
并对threadCount ++
- 如果是
objc_sync_exit
的话,执行lockCount--
、threadCount--
Synchronized为什么具备可重入
、可递归
,并且还具备多线程?
- TLS保障了threadCount(多少条线程对锁对象加锁)
- lockCount++ 标记进来了多少次
synchronized的注意事项
-
@synchronized
为递归互斥锁,lockCount
表示可递归使用,threadCount
表示可在多线程中使用; - 使用
@synchronized
时,不能传入nil
,使用nil锁的功能无法生效; - 在日常开发中,经常会传入
self
,它的好处可以保证生命周期同步
,对象不会提前释放; - 不能使用
非OC对象
作为加锁对象,因为其object
的参数为id类型
; - 底层的缓存和链表都使用
循环遍历查找
,所以性能偏低。但开发中使用方便简单,并且不用解锁,所以使用频率较高。
@synchronized (self) { }
为什么传参数为self
?
- 参数使用self,保证生命周期同步
- 方便存储和释放
真机和模拟器测试锁的性能差异很大
,原因是StripeCount
值不同
template
class StripedMap {
#if TARGET_OS_IPHONE && !TARGET_OS_SIMULATOR
enum { StripeCount = 8 };
#else
enum { StripeCount = 64 };
#endif
下面代码这样写,会有什么问题?
for (int i = 0; i < 200000; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
self.testArray = [NSMutableArray array];
});
}
崩溃的原因: testArray
在某一瞬间变成了nil
,从@synchronized
底层流程知道,如果加锁的对象成了nil
是锁不住的,相当于下面这种情况,block内部不停的retain
、release
,会在某一瞬间上一个还未release
,下一个已经准备release
,这样会导致野指针
的产生
打开edit scheme
-> run
-> Diagnostics
中勾选Zombie Objects
,查看僵尸对象
使用@synchronized (self)
,主要是因为_testArray
的持有者是self
注意:野指针 vs 过渡释放
- 野指针:是指由于过渡释放产生的指针还在进行操作
- 过渡释放:每次都会
retain
和release