iOS 锁的底层分析(1)--@synchronized

2021-09-29  本文已影响0人  冼同学

前言

上一篇文章研究完了GCD相关的底层原理，现在我们开始探索锁的底层原理。众所周知，锁分为两大类：自旋锁&互斥锁。那么他们的工作原理是怎么样子的呢？我们开发中怎么运用这些锁呢？拭目以待！

准备工作

1. 锁的归类

1.1 自旋锁

自旋锁是一种用于保护多线程共享资源的锁，与一般互斥锁（mutex）不同之处在于当自旋锁尝试获取锁时以忙等待（busy waiting）的形式不断地循环检查锁是否可用。当上一个线程的任务没有执行完毕的时候（被锁住），那么下一个线程会一直等待（不会睡眠），当上一个线程的任务执行完毕，下一个线程会立即执行。

注意：在多CPU的环境中，对持有锁较短的程序来说，使用自旋锁代替一般的互斥锁往往能够提高程序的性能。

自旋锁：OSSpinLock(自旋锁)、读写锁

1.2 互斥锁

当上一个线程的任务没有执行完毕的时候（被锁住），那么下一个线程会进入睡眠状态等待任务执行完毕，当上一个线程的任务执行完毕，下一个线程会自动唤醒然后执行任务，该任务也不会立刻执行，而是成为可执行状态（就绪）。互斥锁（mutex），⽤于保证在任何时刻，都只能有⼀个线程访问该对象。

互斥锁：pthread_mutex(互斥锁)、@synchronized(互斥锁)、NSLock(互斥锁)、NSConditionLock(条件锁)、NSCondition(条件锁)、NSRecursiveLock(递归锁)、dispatch_semaphore_t(信号量)

1.3 自旋锁和互斥锁的特点

1.3.1 自旋锁优缺点

1.4 锁的性能

以下是锁的性能图，同意条件下各种锁的耗时，如下：

锁的性能
大部分锁在真机上性能表现更好，@synchronized在真机与模拟器中表现差异巨大。也就是说苹果在真机模式下优化了@synchronized的性能。与之前相比目前@synchronized的性能基本能满足要求。

注意：判断一把锁的性能好坏，一般情况下是与pthread_mutex_t做对比（因为底层都是对它的封装）。

2. 锁的作用

通过一个案例进行分析。模拟一个售票流程，总票数为20张，有4个窗口在同时进行售票，实时跟踪剩余票数。见下面代码：

@interface ViewController ()
@property (nonatomic, assign) NSUInteger ticketCount;
@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    
    self.ticketCount = 20;
    [self testSaleTicket];
}

- (void)testSaleTicket{

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        for (int i = 0; i < 5; i++) {
            [self saleTicket];
        }
    });
   
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        for (int i = 0; i < 5; i++) {
            [self saleTicket];
        }
    });

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        for (int i = 0; i < 3; i++) {
            [self saleTicket];
        }
    });

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        for (int i = 0; i < 10; i++) {
            [self saleTicket];
        }
    });
}

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

运行结果如下：

运行结果
通过上面的运行结果，发现因为异步操作的原因，出现了数据不安全问题，数据出现了混乱。通常我们会通过加锁的方式来保证数据的安全，用来保证在任一时刻，只能有一个线程访问该对象。

对上面的案例进行修改如下：

修改案例
添加一个@synchronized互斥锁，重新运行程序，发现其能够正常运行，并能够保证数据的安全性。@synchronized用着更方便，可读性更高，也是我们最常用的。当然一些小伙伴说也可以用信号量来控制啊，别忘了信号量也是互斥锁。

3. @synchronized实现原理

通过上面的案例我们了解到了锁的作用，那么@synchronized到底做了什么工作呢？这是我们所需要研究分析的。

3.1 底层探索

3.2 实现原理

在libObjc.dylib源码中分析其实现原理。搜索objc_sync_enter和objc_sync_exit两个方法的源码实现：

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;
}

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;
}

由源码可以看出，objc_sync_enter与objc_sync_exit的方法流程都是一一对应的。
流程分析：

SyncData结构分析
查看源码，发现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;

初步判断：@synchronized支持递归锁，并且支持多线程访问。

id2data方法
id2data方法实现如下：

id2data
分析：
包含3个大步骤，首先通过tls，从线程缓存中获取当前线程的SyncData进行相关处理；如果缓存中存在对应的SyncData则从缓存中获取并处理；最后包括一些内部的初始化插入缓存等操作。(详细的步骤在后面案例通过lldb进行分析)

LOCK_FOR_OBJ&LIST_FOR_OBJ
查看两者的宏定义如下：

#define LOCK_FOR_OBJ(obj) sDataLists[obj].lock
#define LIST_FOR_OBJ(obj) sDataLists[obj].data
static StripedMap<SyncList> sDataLists;

StripedMap的结构分析
首先查看StripedMap的定义如下：

class StripedMap {
#if TARGET_OS_IPHONE && !TARGET_OS_SIMULATOR
    enum { StripeCount = 8 };    //表的size
#else
    enum { StripeCount = 64 };
#endif

给表为不同的架构环境提供了不同的容量，真机环境的容量为8，模拟环境的容量为64。而其元素为SyncList，SyncList的数据结构为：

struct SyncList {
    SyncData *data;
    spinlock_t lock;
    constexpr SyncList() : data(nil), lock(fork_unsafe_lock) { }
};

而SyncData是一个链表结构，至此形成了一个拉链结构。见下图：

拉链结构
注意：一个SyncData对应一个对象

@ synchronized的数据结构

@ synchronized数据结构图

3.3 案例跟踪分析

然后进入断点2，查看第二次加锁的流程，进入id2data方法，此时哈希表中已经有一个数据，也就是此时对象对应的listp此时也不再为空（同一个对象）,如下图：

断点跟踪流程
继续往下走，再次获取当前线程绑定的SyncData，此时不再为空，并且object相同。见下图：
断点跟踪流程
线程绑定的SyncData对应的object，与此时的object相同，再次创建锁，并且锁次数++，见下图：
断点跟踪流程

然后继续进入断点3，进行第三次加锁时，因为此时object没有发生改变，线程也没有改变，此时哈希表依然是一个元素，同时对应的listp也只有一个元素，此时上锁此时会变为3。见下图：

断点跟踪流程

进入断点2，object为person2，此时线程已经绑定了person1对应的SyncData，所以线程绑定关系已经被占用，但是object不相同。见下图：

断点跟踪流程
因为person2对象是第一次加锁，所以线程对应缓存列表和listp中都没有对应的SyncData。见下图：
断点跟踪流程
person2初次进入，会进行对象的创建，并将SyncData放入缓存列表中。见下图：
断点跟踪流程
如果下次person2再次加锁时，会从缓存列表中获取。而如果person1再次加锁，会从当前线程中获取，因为当前线程已经绑定了person1对应的SyncData。

进入断点2，进行person2的加锁操作，此时首先会获取当前线程绑定的SyncData，因为此时已经绑定了person1，tls对应的Object不相同。

然后会从线程对应的缓存列表中获取，因为当前线程没有添加过，所以这里查询不到，最终会在listp中获取对应的SyncData。与此同时会进行threadCount加1操作。完成以上操作后，会将该SyncData添加到线程对应的缓存列表中。见下图：

断点跟踪流程

在新线程中的流程与外层线程的逻辑是一样的，只是线程绑定的数据和缓存列表数据不一样。

objc_sync_enter之后的流程图
objc_sync_enter流程图

3.4 @synchronized原理总结

上一篇 下一篇

猜你喜欢

热点阅读