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
查看底层代码编译:
通过上面查看.cpp
代码,知道@synchronized
核心的方法是objc_sync_enter
和objc_sync_exit
方法,下面就探究这两个方法。在探究之前首先找到objc_sync_enter
和objc_sync_exit
方法是属于哪个源码库,给objc_sync_enter
和objc_sync_exit
下符号断点:
很明显示属于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
,注意obj
是id
类型,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
方法就是解锁功能,如果obj
= nil
什么也不做
总结:
objc_sync_enter
方法作用是任务开始时进行加锁操作,而objc_sync_exit
方法作用是在任务结束时进行解锁操作。如果参数为nil
相当于没有加锁解锁的作用,这就是@synchronized
内部自己实现的加锁解锁功能- 在
objc_sync_enter
方法和objc_sync_exit
方法都有id2data
方法而且加锁解锁的功能也是通过id2data
方法的返回值调用的。下面探究下id2data
方法
2.3 id2data
方法探究
整体流程梳理及数据结构分析
id2data
方法源码比较多,先理一下整体流程,然后在对每一部分进行详细的探究
图中的整体流程如下
- 首先从
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
也是一个结构体里面包含了SyncData
和lockCount
当前线程当前对象锁的次数
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
- 如果
why
是ACQUIRE
表示加锁,此时lockCount++
,并把lockCount
更新到tls
中 - 如果
why
是RELEASE
表示解锁,此时lockCount--
,并把lockCount
更新到tls
中,如果lockCount
==0
表示当前线程中没有加锁的对象或者已经全部解锁。此时threadCount
减1
,返回result
- 如果
data->object
和object
不是同一个对象则进行线程缓存查找流程
线程缓存查找流程
// 检查已拥有锁的每个线程缓存,以查找匹配的对象
// 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
去为SyncCache
和SyncCacheItem
开辟内存空间第一次开辟4
个SyncCacheItem
,初始化的个数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
中查找data
,create
= 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
,然后判断SyncList
的data
有值 - 如果
SyncList
的data
有值中有值,则在单向链表找到相应的加锁对象,进行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
流程
-
当前线程第一个进行加锁操作的对象,此时会把
SyncData
和lockCout
=1
存储在tls
,而且当前线程的tls
不会改变除非解锁。一个线程的tls
只存储第一次加锁的SyncData
和lockCout
-
当在同一线程对另一个对象进行加锁注意(上一个加锁的对象没有进行解锁),此时的
SyncData
和lockCount
存储在线程缓存中
至此整个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
打下断点进行调试
第一次给对象加锁*listp
、data
以及cache
都是空,说哈希表中和tls以及线程缓存中都没有查找到。 那么就会进入创建SyncData
流程,为了方便测试我把在非真机状态下的 StripeCount
= 2
图中显示此时的哈希表中的数据都是空的没有数据,断点往下走一步,继续调试
*listp = result
更新哈希表中data
的值,此时result
的nextData
等于*listp
,*listp
前面打印的值是空的,所以result
的nextData
也是空的,*listp = result
以后此时*listp
已经被赋值。继续调试走到done
流程
图中断点显示此时第一次创建的SyncData
和lockCount
存储在tls
中
在第二个@synchronized
打下断点进行调试
对同一个对象再次加锁此时*listp
和data
都有值,那么此时会走到tls
查找data
的流程, lockCount
= 2
说明又加锁一次,然后更新tls
中lockCount
的值,然后直接返回result
在第三个@synchronized
打下断点进行调试
很明显在单线程中对同一个对象进行递归加锁,SyncData
和lockCount
存储在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
对象进行加锁,此时创建的SyncData
和lockCount
存储在tls
中,这个上面已经探究过了
在第二个@synchronized
打下断点进行调试
*listp
有值说明p
和p1
的哈希下标是一样的,此时cache
中也没有数据,tls
中的是有data
不过和p1
不是同一个对象,所以此时会重新创建SyncData
,然后用头插法的方式形成单向链表
最新创建的SyncData
放在拉链的最前面,此时p1
的SyncData
的nextData
存储着p
的SyncData
地址
因为当前线程的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)
打下断点进行调试
哈希表中只有一个SyncList
有值,而且SyncData
里面的值threadCount
= 10
,说明走了多线程的流程。而nextData
的值为空,说明此时只有一个对象进行了多线程加锁,如果多线程多对象实际就是每个对象走单个对象的加锁流程
@synchronized
总结
objc_sync_exit
流程和objc_sync_enter
流程走的是一样的只不过一个是加锁一个是解锁@synchronized
底层是链表查找、缓存查找以及递归,是非常耗内存以及性能的@synchronized
底层封装了是一把递归锁,可以自动进行加锁解锁,这也是大家喜欢使用它的原因@synchronized
中lockCount
控制递归,而threadCount
控制多线程@synchronized
加锁的对象尽量不要为nil
,不然起不到加锁的效果