废话开篇
iOS 下的多线程的技术的应用衍生出了锁的机制，试想，如果 iOS 下没有多线程的概念，所有的代码都会在同步环境下执行，那么，也就不会产生争夺资源情况的发生，当然，也就没有办法利用多核的优势。所以，多线程的应用是广布的，而锁的应用是局部的，所以，二者应相辅相成，来达到提高运行效率的同时提高程序运行的稳定性。
思考一、对于锁的类型的理解
基本的三种锁的类型：互斥锁、自旋锁、读写锁。
其中，互斥锁 多线程在访问加锁中的临界区前，会进入休眠，一直等待解锁后系统调度
；自旋锁 多线程在访问加锁中的临界区前，不进入休眠，会一直忙等。 读写锁 是一种思想，本质就是利用 互斥锁 来实现特定的应用场景：多读并行、读与写互斥，写与写互斥；对于其他的类型的锁，比如：信号量、条件锁、递归锁，可以理解为是由以上基本类型的锁实现的上层封装。
思考二、读写锁的实现逻辑
如果有这样一块公共资源，它的写入是比较耗时，那么，在这段时间内要避免程序再次的进行写入操作和读取操作，这样可以避免产生争夺资源的问题，当然，读取的过程可以并行。
先上一段代码，这里模拟一个比较耗时的写入过程，在模拟一个快速读取的过程。
//读写锁
- (void)readAndWriteLock
{
//写
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"我开始写");
for (int i = 0; i < 10000; i++) {
}
NSLog(@"我写完了");
});
//读
for (int i = 0; i < 10; i++) {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"我开始读%d",i);
for (int j = 0; j < i; j++) {
}
NSLog(@"我读完了%d",i);
});
}
}
在写入的异步内执行了循环 10000 次的操作来模拟耗时任务；后面开辟了多线程进行读取，在读取的异步里，实现简单的不同数量的循环来模拟耗时任务，这里的耗时次数远小于写入。
打印如下
通过输出可以清晰的看到，写入过程中还有很多读取的操作在同时进行。致于是先开始读取还是开始写入，这里其实并不用去关心，本身它们也是由系统决定的，但是，这里需要控制一下代码，来实现读写互斥，即在写的过程中，禁止读取操作的介入。同时，也需要实现写写互斥。对于，多读，其实这里并不需要过多干涉，因为，本身就允许多读的逻辑。
思考三、简单封装读写锁，满足读写逻辑
利用互斥锁封装读取加、解锁；写入加、解锁
//初始化读取锁 static pthread_mutex_t r_plock = PTHREAD_MUTEX_INITIALIZER; //初始化写入锁 static pthread_mutex_t w_plock = PTHREAD_MUTEX_INITIALIZER; //记录当前读取次数，因为只要其值不为0，那么，就说明程序在读取操作，这里停止写入操作 static int current_read_times = 0;
进行读取加锁
//读加锁
- (void)readLock
{
pthread_mutex_lock(&r_plock);
current_read_times ++;
if (current_read_times == 1) {
pthread_mutex_lock(&w_plock);
}
pthread_mutex_unlock(&r_plock);
}
这里首先进行 读取锁 加锁，这里加锁的目的并不是锁定读取过程，而是锁定了修改 current_read_times 的过程，当 current_read_times 变更后，如果为 1，那么，就对 写入锁 加锁，这个写入锁就是锁住写入过程的。这两个锁的应用部分是有区别的。
进行读取解锁
//读解锁
- (void)readUnLock
{
pthread_mutex_lock(&r_plock);
current_read_times --;
if (current_read_times == 0) {
pthread_mutex_unlock(&w_plock);
}
pthread_mutex_unlock(&r_plock);
}
这里首先进行 读取锁 加锁，目的还是对 current_read_times 修改的锁，可以总结一下，读写锁本质并不对多读进行限制，所以，这里的读取锁是锁住 current_read_times 修改过程，在加锁的情况下进行 写入锁 状态的变更，实现 读与写的互斥。后面进行状态判断，如果 current_read_times 为 0，说明当前所以读取完成了，那么，对 写入锁 进行解锁，解锁后写入操作就可以正常进行。这里解锁的判断为 == 0 与 加锁的判断 == 1 是一对，这样就满足了，一个加锁过程对应一个解锁条件。不会出现只有加锁后而没有解锁的情况。
进行写入加锁
//写加锁
- (void)writeLock
{
pthread_mutex_lock(&w_plock);
}
这里仅仅是对 写入 操作进行加锁。
进行写入解锁
//写解锁
- (void)writeUnLock
{
pthread_mutex_unlock(&w_plock);
}
这里仅仅是对 写入 操作进行解锁。
最后的代码
//读写锁
- (void)readAndWriteLock
{
//写
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[self writeLock];
NSLog(@"我开始写");
for (int i = 0; i < 10000; i++) {
}
NSLog(@"我写完了");
[self writeUnLock];
});
//读
for (int i = 0; i < 10; i++) {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[self readLock];
NSLog(@"我开始读%d",i);
for (int j = 0; j < i; j++) {
}
NSLog(@"我读完了%d",i);
[self readUnLock];
});
}
}
打印如下
可以看待写入过程是完整的一个打印顺序，而读取过程由于没有锁的保护并没有按顺序执行。
一个简单的 读写锁 就完成了。代码拙劣，大神勿笑。
总结
到此这篇关于iOS中读写锁的简单实现的文章就介绍到这了,更多相关iOS读写锁实现内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！
原文链接：https://juejin.cn/post/7025421259231985677