iOS——线程安全、线程同步与线程通信

最新推荐文章于 2024-09-10 17:30:17 发布

糸师凛

最新推荐文章于 2024-09-10 17:30:17 发布

阅读量1.5k

点赞数 17

文章标签： ios 安全 cocoa

本文链接：https://blog.csdn.net/m0_73348697/article/details/141941087

版权

线程安全和线程同步

线程安全：如果你的代码所在的进程中有多个线程在同时运行，而这些线程可能会同时运行这段代码。如果每次运行结果和单线程运行的结果是一样的，而且其他的变量的值也和预期的是一样的，就是线程安全的。

若每个线程中对全局变量、静态变量只有读操作，而无写操作，一般来说，这个全局变量是线程安全的；若有多个线程同时执行写操作（更改变量），一般都需要考虑线程同步，否则的话就可能影响线程安全。

线程同步：可理解为线程 A 和线程 B 一块配合，A 执行到一定程度时要依靠线程 B 的某个结果，于是停下来，示意 B 运行；B 依言执行，再将结果给 A；A 再继续操作。

多线程的安全隐患

资源共享
1块资源可能会被多个线程共享，也就是多个线程可能会访问同一块资源
比如多个线程访问同一个对象、同一个变量、同一个文件
当多个线程访问同一块资源时，很容易引发数据错乱和数据安全问题

例子：
如以下的抢票代码：

@interface ViewController ()
@property (assign, nonatomic) int ticketsCount;
@end

@implementation ViewController

- (void) viewDidLoad {
    [super viewDidLoad];
    
    self.ticketsCount = 100;
    [self test];
}

- (void) test {
    dispatch_queue_t queue = dispatch_get_global_queue(0, 0);
    dispatch_async(queue, ^{
        for (int i = 0; i < 100; i++) {
            [NSThread sleepForTimeInterval:0.1];
            [self cunTicket];
        }
    });
    
    dispatch_async(queue, ^{
        for (int i = 0; i < 100; i++) {
            [NSThread sleepForTimeInterval:0.1];
            [self quTicket];
        }
    });
}

- (void) cunTicket {
    int oldTicket = self.ticketsCount;
    self.ticketsCount = oldTicket + 1;
    NSLog(@"加1票：%d", self.ticketsCount);
}

- (void) quTicket {
    int oldTicket = self.ticketsCount;
    self.ticketsCount = oldTicket - 1;
    NSLog(@"减1票：%d", self.ticketsCount);
}

@end

执行结果：
请添加图片描述

数据发生了错误

多线程安全隐患分析

请添加图片描述

解决方案：使用线程同步技术（同步，就是协同步调，按预定的先后次序进行）
常见的线程同步技术是：加锁

请添加图片描述

线程A访问Integer的时候先加锁，访问完成后解锁
在线程B访问加锁，完成后解锁。

线程同步

iOS中的线程同步方案

OSSpinLock
os_unfair_lock
pthread_mutex
dispatch_semaphore
dispatch_queue(DISPATCH_QUEUE_SERIAL) //串行队列
NSLock
NSRecursiveLock
NSCondition
NSConditionLock
@synchronized

OSSpinLock（自旋锁）

自旋锁与互斥锁有点类似，只是自旋锁不会引起调用者睡眠，所以自旋锁的效率远高于互斥锁。如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，"自旋"一词就是因此而得名。

虽然它的效率比互斥锁高，但是它也有些不足之处：

自旋锁的等待锁的线程会处于忙等（busy-wait）状态，一直占用着CPU资源。如果等待锁的线程优先级较高，它会一直占用着CPU资源，优先级低的线程就无法释放锁。
使用自旋锁不容易解决优先级反转问题。
在用自旋锁时有可能造成死锁，当递归调用时有可能造成死锁，调用有些其他函数也可能造成死锁，如 copy_to_user()、copy_from_user()、kmalloc()等。

自旋锁只有在内核可抢占式或SMP的情况下才真正需要，在单CPU且不可抢占式的内核下，自旋锁的操作为空操作。自旋锁适用于锁使用者保持锁时间比较短的情况下。

优先级反转问题

例子：
请添加图片描述

线程A在一个比较低的优先级上工作, 假设是10吧。然后在时间点T1的时候，线程A锁定了一把互斥锁，并开始操作互斥数据。
这时有个高优线级线程C（比如优先级20）在时间点T2被唤醒，它也也需要操作互斥数据。当它加锁互斥锁时，因为互斥锁在T1被线程A锁掉了，所以线程C放弃CPU进入阻塞状态，而线程A得以占据CPU，继续执行。
事情到这一步还是正确的，虽然优先级10的A线程看上去抢了优先级20的C线程的时间，但因为程序逻辑，C确实需要退出CPU等完成互斥数据操作后，才能获得CPU。
但是，假设我们有个线程B在优先级15上，在T3时间点上醒了过来，因为他比当前执行的线程A优先级高，所以它会立即抢占CPU。而线程A被迫进入READY状态等待。
一直到时间点T4，线程B放弃CPU，这时优先级10的线程A是唯一READY线程，它再次占据CPU继续执行，最后在T5解锁了互斥锁。
在T5，线程A解锁的瞬间，线程C立即获取互斥锁，并在优先级20上等待CPU。因为它比线程A的优先级高，系统立刻调度线程C执行，而线程A再次进入READY状态。

上面这个时序里，线程B从T3到T4占据CPU运行的行为，就是事实上的优先级反转。一个优先级15的线程B，通过压制优线级10的线程A，而事实上导致高优先级线程C无法正确得到CPU。这段时间是不可控的，因为线程B可以长时间占据CPU（即使轮转时间片到时，线程A和B都处于可执行态，但是因为B的优先级高，它依然可以占据CPU），其结果就是高优先级线程C可能长时间无法得到 CPU。

优先级反转问题和自旋锁

优先级反转问题的出现跟自旋锁没有关系
不使用自旋锁时也可能出现优先级反转问题。只要是线程或任务有多个优先级，理论上就可能有反转问题。操作系统在优先级反转发生时通常都会有自动的解决方案，比如提高低优先级线程的优先级等

在使用iOS中的OSSpinLock自旋锁时，由于这种锁不会记录持有它的线程信息，所有当发生优先级反转时，系统找不到低优先级的线程，可能因此无法通过提高优先级解决优先级反转问题。再加上，高优先级线程使用自旋锁进行轮训等待锁时在一直占用CPU时间片，使得低优先级线程拿到时间片的概率降低

总结下来是

优先级反转问题的出现跟自旋锁没有关系
但一旦出现优先级反转问题，自旋锁会让优先级反转问题不容易解决，甚至造成更严重的线程等待问题

互斥锁

互斥锁和自旋锁的区别是，当线程获取锁操作失败的时候，线程会进入睡眠，即它是sleep-waiting，而自旋锁是会使线程进入忙等busy-waiting。如果线程是使用pthread_spin_lock操作去请求自旋锁，那么线程就会一直进行忙等待并不停的进行锁请求，直到得到这个锁为止。

互斥锁用于临界区持锁时间比较长的操作，比如下面这些情况都可以考虑

临界区有IO操作
临界区代码复杂或者循环量大
临界区竞争非常激烈
单核处理器

两种锁的加锁原理

自旋锁：线程一直是running(加锁——>解锁)，死循环检测锁的标志位，机制不复杂。
互斥锁：线程会从sleep（加锁）——>running（解锁），过程中有上下文的切换，cpu的抢占，信号的发送等开销。

对比 :互斥锁的起始原始开销要高于自旋锁，但是基本是一劳永逸，临界区持锁时间的大小并不会对互斥锁的开销造成影响，而自旋锁是死循环检测，加锁全程消耗cpu，起始开销虽然低于互斥锁，但是随着持锁时间，加锁的开销是线性增长。

两种锁的使用

自旋锁的使用

在使用自旋锁之前，需要导入头文件#import<libkern/OSAtomic.h>

//初始化
OSSpinLock lock = OS_SPINLOCK_INIT;
//加锁
OSSpinLockLock(&lock);
//解锁
OSSpinLockUnlock(&lock);

互斥锁的使用

OSSpinLock在iOS10.0以后就被弃用了，可以使用os_unfair_lock替代:
需要导入头文件#import <os/lock.h>:

//初始化
os_unfair_lock lock = OS_UNFAIR_LOCK_INIT;
//加锁
os_unfair_lock_lock(&lock);
//解锁
os_unfair_lock_unlock(&lock);

pthread_mutex：
mutex叫做”互斥”，等待锁的线程会处于休眠状态。需要导入头文件#import <pthread.h>

1、初始化锁的属性
//声明一个互斥锁属性变量
pthread_mutexattr_t attr;
//初始化该属性变量，使其包含默认值
pthread_mutexattr_init(&attr);
//将互斥锁属性设置为递归锁类型
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);

/*
* Mutex type attributes
*/

#define PTHREAD_MUTEX_NORMAL        0   // 普通锁
#define PTHREAD_MUTEX_ERRORCHECK    1   // 错误检查锁
#define PTHREAD_MUTEX_RECURSIVE     2   // 递归锁
#define PTHREAD_MUTEX_DEFAULT       PTHREAD_MUTEX_NORMAL // 默认锁类型

2、初始化锁
pthread_mutex_init(mutex, &attr);

3、初始化锁结束以后，销毁属性
pthread_mutexattr_destroy(&attr);

4、加锁解锁
pthread_mutex_lock(&_mutex);
pthread_mutex_unlock(&_mutex);

5、// 初始化条件
pthread_cond_t condition
pthread_cond_init(&_cond, NULL);

6、// 等待条件
pthread_cond_wait(&_cond, &_mutex);

7、//激活一个等待该条件的线程
pthread_cond_signal(&_cond);
//激活所有等待该条件的线程
pthread_cond_broadcast(&_cond);

8、//销毁资源
pthread_mutex_destroy(&_mutex);
pthread_cond_destroy(&_cond);

备注：我们可以不初始化属性，在传属性的时候直接传NULL，表示使用默认属性PTHREAD_MUTEX_NORMAL。pthread_mutex_init(mutex, NULL);

PTHREAD_MUTEX_RECURSIVE递归锁：允许同一个线程对同一把锁进行重复加锁。要看着重点同一个线程和同一把锁

NSLock:
NSLock是对mutex普通锁的封装。pthread_mutex_init(mutex, NULL);
NSLock 遵循 NSLocking 协议。Lock 方法是加锁，unlock 是解锁，tryLock 是尝试加锁，如果失败的话返回 NO，lockBeforeDate: 是在指定Date之前尝试加锁，如果在指定时间之前都不能加锁，则返回NO

其他实现同步的方法

NSRecursiveLock

NSRecursiveLock是对mutex递归锁的封装，API跟NSLock基本一致

NSCondition

NSCondition是对mutex和cond的封装，更加面向对象，我们使用起来也更加的方便简洁

NSConditionLock

NSConditionLock是对NSCondition的进一步封装，可以设置具体的条件值

@interface NSConditionLock : NSObject <NSLocking>

// 初始化方法，根据给定的条件初始化锁
- (instancetype)initWithCondition:(NSInteger)condition;
// 只读属性，返回当前锁的条件
@property (readonly) NSInteger condition;
// 当条件满足时锁定
- (void)lockWhenCondition:(NSInteger)condition;
// 尝试锁定，如果锁已经被其他线程占用则返回 NO
- (BOOL)tryLock;
// 当条件满足时尝试锁定，如果锁已经被其他线程占用或条件不满足则返回 NO
- (BOOL)tryLockWhenCondition:(NSInteger)condition;
// 解锁并设置新的条件
- (void)unlockWithCondition:(NSInteger)condition;
// 在指定的时间之前尝试锁定，如果成功返回 YES，否则返回 NO
- (BOOL)lockBeforeDate:(NSDate *)limit;
// 在指定的时间之前当条件满足时尝试锁定，如果成功返回 YES，否则返回 NO
- (BOOL)lockWhenCondition:(NSInteger)condition beforeDate:(NSDate *)limit;
// 锁的名称，可用于调试
@property (nullable, copy) NSString *name;

@end

dispatch_semaphore

semaphore叫做”信号量”
信号量的初始值，可以用来控制线程并发访问的最大数量
信号量的初始值为1，代表同时只允许1条线程访问资源，保证线程同步

dispatch_semaphore_create(5);
// 如果信号量的值 > 0，就让信号量的值减1，然后继续往下执行代码
// 如果信号量的值 <= 0，就会休眠等待，直到信号量的值变成>0，就让信号量的值减1，然后继续往下执行代码
dispatch_semaphore_wait(self.semaphore, DISPATCH_TIME_FOREVER);
// 让信号量的值+1
dispatch_semaphore_signal(self.semaphore);

dispatch_queue

直接使用GCD的串行队列，也是可以实现线程同步的

dispatch_queue_t queue = dispatch_queue_create("test", DISPATCH_QUEUE_SERIAL);

dispatch_sync(queue, ^{
    // 追加任务1
    for (int i = 0; i < 2; ++i) {
        NSLog(@"1---%@",[NSThread currentThread]);
    }
});

dispatch_sync(queue, ^{
    // 追加任务2
    for (int i = 0; i < 2; ++i) {
        NSLog(@"2---%@",[NSThread currentThread]);
    }
});

@synchronized

@synchronized是对mutex递归锁的封装，
@synchronized(obj)内部会生成obj对应的递归锁，然后进行加锁、解锁操作
使用例子：

//假设有段使用锁的方法是这样写的
- (void)push:(id)element
{
    [_lock lock];
    [_elements addObject:element];
    [_lock unlock];
}

它等同于这样使用@synchronized：

- (void)increment
{
    @synchronized (self) {
        [_elements addObject:element];
    }
}

你可以给任何 Objective-C 对象上加个 @synchronized。那么我们也可以在上面的例子中用 @synchronized(_elements) 来替代 @synchronized(self)，效果是相同的。

@synchronized底层实现

@synchronized block 会变成 objc_sync_enter 和 objc_sync_exit 的成对儿调用。

// 定义 SyncData 结构体
typedef struct SyncData {
    //我们传给 @synchronized 的对象
    id object;
    //与 object 关联的递归锁                     
    recursive_mutex_t mutex;    
    //指向下一个 SyncData 对象的指针，形成一个链表结构    
    struct SyncData* nextData;   
    //当前使用或等待这个 SyncData 对象锁的线程数量   
    int threadCount;                
} SyncData;

// 定义 SyncList 结构体
typedef struct SyncList {
  //指向 SyncData 链表头部的指针
    SyncData *data;                
    //一个自旋锁，用于防止多个线程并发修改这个列表 
    spinlock_t lock;                
} SyncList;

// 定义宏和全局变量
 //定义了数组的大小（16）
#define COUNT 16 

// HASH(obj) 是一个哈希函数，将对象的指针地址转换为数组的索引。这个哈希函数通过右移对象指针五位，再与 15（即 COUNT - 1）进行按位与操作来计算索引。
#define HASH(obj) ((((uintptr_t)(obj)) >> 5) & (COUNT - 1))

// LOCK_FOR_OBJ(obj) 宏获取与对象关联的锁
#define LOCK_FOR_OBJ(obj) sDataLists[HASH(obj)].lock 

// LIST_FOR_OBJ(obj) 宏获取与对象关联的 SyncData 链表头
#define LIST_FOR_OBJ(obj) sDataLists[HASH(obj)].data 

//SyncList结构体数组，大小为 16
static SyncList sDataLists[COUNT];

一开始，我们有一个 struct SyncData 的定义。这个结构体包含一个 object（即我们传给 @synchronized 的对象）和一个关联的 recursive_mutex_t，它就是那个跟 object 关联在一起的锁。每个 SyncData 也包含一个指向另一个 SyncData 对象的指针，叫做 nextData，所以你可以把每个 SyncData 结构体看作是链表中的一个元素。最后，每个 SyncData 包含一个 threadCount，这个 SyncData 对象中的锁会被一些线程使用或等待，threadCount 就是此时这些线程的数量。它很有用处，因为 SyncData 结构体会被缓存，threadCount==0 就暗示了这个 SyncData 实例可以被复用。

下面是 struct SyncList 的定义。正如我在上面提过，你可以把 SyncData 当做是链表中的节点。每个 SyncList 结构体都有个指向 SyncData 节点链表头部的指针，也有一个用于防止多个线程对此列表做并发修改的锁。

上面代码块的最后一行是 sDataLists 的声明 - 一个 SyncList 结构体数组，大小为 16。通过定义的一个哈希算法将传入对象映射到数组上的一个下标。值得注意的是这个哈希算法设计得很巧妙，是将对象指针在内存的地址转化为无符号整型并右移五位，再跟 0xF 做按位与运算，这样结果不会超出数组大小。LOCK_FOR_OBJ(obj) 和 LIST_FOR_OBJ(obj) 这两个宏就更好理解了，先是哈希出对象的数组下标，然后取出数组对应元素的 lock 或 data。一切都是这么顺理成章哈。

当你调用 objc_sync_enter(obj) 时，它用 obj 内存地址的哈希值查找合适的 SyncData，然后将其上锁。当你调用 objc_sync_exit(obj) 时，它查找合适的 SyncData 并将其解锁。

源码：

BOOL objc_sync_try_enter(id obj)
{
    BOOL result = YES;

    if (obj) {
        SyncData* data = id2data(obj, SyncKind::atSynchronize, ACQUIRE);
        ASSERT(data);
        result = data->mutex.tryLock();
    } 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();
        if (DebugNilSync == Fatal)
            _objc_fatal("@synchronized(nil) is fatal");
    }

    return result;
}


// End synchronizing on 'obj'. 
// Returns OBJC_SYNC_SUCCESS or OBJC_SYNC_NOT_OWNING_THREAD_ERROR
int objc_sync_exit(id obj)
{
    int result = _objc_sync_exit_kind(obj, SyncKind::atSynchronize);
    if (result != OBJC_SYNC_SUCCESS)
        OBJC_DEBUG_OPTION_REPORT_ERROR(DebugSyncErrors,
            "objc_sync_exit(%p) returned error %d", obj, result);
    return result;
}

当一个对象在 @synchronized block 当中被释放或设为 nil 时会发生什么
会注意到 objc_sync_enter 里面没有 retain 和 release。所以它要么没有保持传递给它的对象，要么或是在 ARC 下被编译。我们可以用下面的代码来做个测试：

NSDate *test = [NSDate date];
//打印 test 的 retainCount，它应当是 1。
NSLog(@"%@", @([test retainCount]));

@synchronized (test) {
  //进入 @synchronized 块，并打印 test 的 retainCount。
//如果 @synchronized 对 test 进行了 retain，retainCount 应为 2。否则，仍为 1。
    NSLog(@"%@", @([test retainCount]));
}

运行结果显示两次输出都是 1，这表明 @synchronized 没有对传入的对象进行 retain 操作。
@synchronized 块中没有 retain 操作，对象在同步块内被释放后，其内存地址可能被重用。这会导致其他线程在同步同一地址的对象时发生阻塞。
但是这是设计者预见并接受的情况，因为在内存地址相同的情况下，阻塞等待确保了同步块的正确性。添加 retain 操作可能会增加复杂性和性能开销，但没有特别好的替代方案来避免此问题。

假如对象在 “synchronized block” 中被设成 nil 呢

NSString *test = @"test";
@try {
    //给 test 分配一个锁并锁定它。
    objc_sync_enter(test);
    //然后将test设为 nil。
    test = nil;
} @finally {
    //调用 objc_sync_exit(test)。因为 test 已被设为 nil，传递给 objc_sync_exit 的是 nil，这会导致锁不会被解锁或释放。
    objc_sync_exit(test);   
}

在 @synchronized 块中将对象设为 nil 的潜在问题：传递 nil 给objc_sync_exit是一个空操作，导致锁不会被释放。

在 @synchronized 块中将对象设为 nil 不会导致死锁，因为编译器确保 objc_sync_enter 和 objc_sync_exit 传入的是相同对象。
如果传递给 @synchronized 的对象为 nil，不会获得任何锁，代码不会是线程安全的。

这个机制确保了在 @synchronized 块中将对象设为 nil 时不会导致锁未释放的问题。
验证了 @synchronized 在这种情况下的正确性，确保了多线程环境下的线程安全性。

你调用 sychronized 的每个对象，Objective-C runtime 都会为其分配一个递归锁并存储在哈希表中。
如果在 sychronized 内部对象被释放或被设为 nil 看起来都 OK。不过这没在文档中说明，所以我不会再生产代码中依赖这条。
注意不要向你的 sychronized block 传入 nil！这将会从代码中移走线程安全。你可以通过在 objc_sync_nil 上加断点来查看是否发生了这样的事情。

@synchronized(id)参数问题

有如下代码：

- (void)lg_crash{
    for (int i = 0; i < 200000; i++) {
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            @synchronized (_testArray) {
                _testArray = [NSMutableArray array];
            }
        });
    }
}

_testArray在某个时刻可能会变为nil，而当_testArray变为nil时，多线程下的操作会导致@synchronized传入的参数为nil而调用objc_sync_nil函数，也就没有了加锁的效果了，从而导致崩溃的出现。
所以我们在使用@synchronized确保多线程数据安全的时候，要保证传入的绝对不能如上例子为nil的情况。修改成如下则不会再有问题：

- (void)lg_crash{
    for (int i = 0; i < 200000; i++) {
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            @synchronized (self) {
                _testArray = [NSMutableArray array];
            }
        });
    }
}

atomic

atomic用于保证属性setter、getter的原子性操作，相当于在getter和setter内部加了线程同步的锁
它并不能保证使用属性的过程是线程安全的, 只能保证存取值的完整性

pthread_rwlock：读写锁

pthread_rwlock经常用于文件等数据的读写操作，需要导入头文件#import <pthread.h>
iOS中的读写安全方案需要注意一下场景：（多读单写）

同一时间，只能有1个线程进行写的操作
同一时间，允许有多个线程进行读的操作
同一时间，不允许既有写的操作，又有读的操作

锁的性能比较

性能从高到低排序

os_unfair_lock
OSSpinLock
dispatch_semaphore
pthread_mutex
dispatch_queue(DISPATCH_QUEUE_SERIAL)
NSLock
NSCondition
pthread_mutex(recursive)
NSRecursiveLock
NSConditionLock
@synchronized

补充

CPU抢占

CPU 由操作系统统一进行分配，每个进程根据进程优先级的高低都有机会得到 CPU，但是，如果运行时间超过了一定的时间，操作系统会暂停该进程，将 CPU 资源分配给其他等待运行的进程。这种 CPU 的分配方式即所谓的** 抢占式**，操作系统可以强制剥夺 CPU 资源并且分配给它认为目前最需要的进程，如果操作系统分配给每个进程的时间都很短，即 CPU 在多个进程间快速的切换，从而造成了很多进程在同时运行的假象，这个就是并行的实质。

糸师凛

关注

17
点赞
踩
8

收藏

觉得还不错? 一键收藏
0
评论
iOS——线程安全、线程同步与线程通信

若每个线程中对全局变量、静态变量只有读操作，而无写操作，一般来说，这个全局变量是线程安全的；若有多个线程同时执行写操作（更改变量），一般都需要考虑线程同步，否则的话就可能影响线程安全。
复制链接

扫一扫