生活中用到的锁，用途都比较简单粗暴，上锁基本是为了防止外人进来、电动车被偷等等。
但生活中也不是没有 BUG 的，比如加锁的电动车在「广西 - 窃·格瓦拉」面前，锁就是形同虚设，只要他愿意，他就可以轻轻松松地把你电动车给「顺走」，不然打工怎么会是他这辈子不可能的事情呢？牛逼之人，必有牛逼之处。
那在编程世界里，「锁」更是五花八门，多种多样，每种锁的加锁开销以及应用场景也可能会不同。
如何用好锁，也是程序员的基本素养之一了。
高并发的场景下，如果选对了合适的锁，则会大大提高系统的性能，否则性能会降低。
所以，知道各种锁的开销，以及应用场景是很有必要的。
接下来，就谈一谈常见的这几种锁：
先看看互斥锁，它只有两个状态，要么是加锁状态，要么是不加锁状态。假如现在一个线程a只是想读一个共享变量 i，因为不确定是否会有线程去写它，所以我们还是要对它进行加锁。但是这时又有一个线程b试图去读共享变量 i，发现被锁定了，那么b不得不等到a释放了锁后才能获得锁并读取 i 的值，但是两个读取操作即使是同时发生的，也并不会像写操作那样造成竞争，因为它们不修改变量的值。所以我们期望在多个线程试图读取共享变量的时候，它们可以立刻获取因为读而加的锁，而不是需要等待前一个线程释放。
读写锁可以解决上面的问题。它提供了比互斥锁更好的并行性。因为以读模式加锁后，当有多个线程试图再以读模式加锁时，并不会造成这些线程阻塞在等待锁的释放上。
读写锁是多线程同步的另外一个机制。在一些程序中存在读操作和写操作问题，对某些资源的访问会存在两种可能情况，一种情况是访问必须是排他的，就是独占的意思，这种操作称作写操作，另外一种情况是访问方式是可以共享的，就是可以有多个线程同时去访问某个资源，这种操作称为读操作。这个问题模型是从对文件的读写操作中引申出来的。把对资源的访问细分为读和写两种操作模式，这样可以大大增加并发效率。读写锁比互斥锁适用性更高，并行性也更高。
需要注意的是，这里只是说并行效率比互斥高，并不是速度一定比互斥锁快，读写锁更复杂，系统开销更大。并发性好对于用户体验非常重要，假设互斥锁需要0.5秒，使用读写锁需要0.8秒，在类似学生管理系统的软件中，可能90%的操作都是查询操作。如果突然有20个查询请求，使用的是互斥锁，则最后的查询请求被满足需要10秒，估计没人接收。使用读写锁时，因为读锁能多次获得，所以20个请求中，每个请求都能在1秒左右被满足，用户体验好的多。
自旋锁（spinlock）：是指当一个线程在获取锁的时候，如果锁已经被其它线程获取，那么该线程将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才会退出循环。
获取锁的线程一直处于活跃状态，但是并没有执行任何有效的任务，使用这种锁会造成busy-waiting。
二 读写锁特点
1 如果一个线程用读锁锁定了临界区，那么其他线程也可以用读锁来进入临界区，这样可以有多个线程并行操作。这个时候如果再用写锁加锁就会发生阻塞。写锁请求阻塞后，后面继续有读锁来请求时，这些后来的读锁都将会被阻塞。这样避免读锁长期占有资源，防止写锁饥饿。
2 如果一个线程用写锁锁住了临界区，那么其他线程无论是读锁还是写锁都会发生阻塞。
自旋锁不会使线程状态发生切换，一直处于用户态，即线程一直都是active的；不会使线程进入阻塞状态，减少了不必要的上下文切换，执行速度快
非自旋锁在获取不到锁的时候会进入阻塞状态，从而进入内核态，当获取到锁的时候需要从内核态恢复，需要线程上下文切换。 （线程被阻塞后便进入内核（Linux）调度状态，这个会导致系统在用户态与内核态之间来回切换，严重影响锁的性能）
可重入的自旋锁和不可重入的自旋锁
锁支不支持重入的，即当一个线程第一次已经获取到了该锁，在锁释放之前又一次重新获取该锁，第二次就不能成功获取到。由于不满足CAS，所以第二次获取会进入while循环等待，而如果是可重入锁，第二次也是应该能够成功获取到的。
而且，即使第二次能够成功获取，那么当第一次释放锁的时候，第二次获取到的锁也会被释放，而这是不合理的。
为了实现可重入锁，我们需要引入一个计数器，用来记录获取锁的线程数。
链接：https://www.jianshu.com/p/9d3660ad4358
三 读写锁使用的函数
操作
相关函数说明
初始化读写锁
pthread_rwlock_init 语法
读取读写锁中的锁
pthread_rwlock_rdlock 语法
读取非阻塞读写锁中的锁
pthread_rwlock_tryrdlock 语法
写入读写锁中的锁
pthread_rwlock_wrlock 语法
写入非阻塞读写锁中的锁
pthread_rwlock_trywrlock 语法
解除锁定读写锁
pthread_rwlock_unlock 语法
销毁读写锁
pthread_rwlock_destroy 语法
读写锁是用来解决读者写者问题的，读操作可以共享，写操作是排他的，读可以有多个在读，写只有唯一个在写，同时写的时候不允许读。
具有强读者同步和强写者同步两种形式
强读者同步：当写者没有进行写操作，读者就可以访问；
强写者同步：当所有写者都写完之后，才能进行读操作，读者需要最新的信息，一些事实性较高的系统可能会用到该所，比如定票之类的。
读写锁的操作：
读写锁的初始化：
定义读写锁： pthread_rwlock_t m_rw_lock;
函数原型： pthread_rwlock_init(pthread_rwlock_t * ,pthread_rwattr_t *);
返回值：0，表示成功，非0为一错误码
读写锁的销毁：
函数原型： pthread_rwlock_destroy(pthread_rwlock_t* );
返回值：0，表示成功，非0表示错误码
获取读写锁的读锁操作：分为阻塞式获取和非阻塞式获取,如果读写锁由一个写者持有，则读线程会阻塞直至写入者释放读写锁。
阻塞式:
函数原型：pthread_rwlock_rdlock(pthread_rwlock_t*);
非阻塞式：
函数原型：pthread_rwlock_tryrdlock(pthread_rwlock_t*);
返回值： 0，表示成功，非0表示错误码，非阻塞会返回ebusy而不会让线程等待
获取读写锁的写锁操作：分为阻塞和非阻塞，如果对应的读写锁被其它写者持有，或者读写锁被读者持有，该线程都会阻塞等待。
阻塞式：
函数原型：pthread_rwlock_wrlock(pthread_rwlock_t*);
非阻塞式：
函数原型：pthread_rwlock_trywrlock(pthread_rwlock_t*);
返回值： 0，表示成功
释放读写锁：
函数原型：pthread_rwlock_unlock(pthread_rwlock_t*);
总结（转）：
互斥锁与读写锁的区别：
当访问临界区资源时（访问的含义包括所有的操作：读和写），需要上互斥锁；
当对数据（互斥锁中的临界区资源）进行读取时，需要上读取锁，当对数据进行写入时，需要上写入锁。
读写锁的优点：
对于读数据比修改数据频繁的应用，用读写锁代替互斥锁可以提高效率。因为使用互斥锁时，即使是读出数据（相当于操作临界区资源）都要上互斥锁，而采用读写锁，则可以在任一时刻允许多个读出者存在，提高了更高的并发度，同时在某个写入者修改数据期间保护该数据，以免任何其它读出者或写入者的干扰。
读写锁描述：
获取一个读写锁用于读称为共享锁，获取一个读写锁用于写称为独占锁，因此这种对于某个给定资源的共享访问也称为共享-独占上锁。
有关这种类型问题（多个读出者和一个写入者）的其它说法有读出者与写入者问题以及多读出者-单写入者锁。
————————————————
版权声明：本文为CSDN博主「不材之木」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wonderisland/article/details/16940925
c++读写锁实现
c++读写锁实现_林多的博客-CSDN博客
C++17，提供了shared_mutex。配合C++14，提供的shared_lock。及C++11，提供的 unique_lock， 可以方便实现读写锁。
但上述的前提是，允许你使用C++17。在国内的开发环境下，别说C++17，连C++11用的也不多。
所以，大多数时候，我们需要自己实现一套C++读写锁（C++11环境下）。
RWLock.h
#ifndef RWLOCK__H
#define RWLOCK__H
#ifndef __cplusplus
# error ERROR: This file requires C++ compilation(use a .cpp suffix)
#endif
#include <mutex>
#include <condition_variable>
namespace linduo {
class RWLock {
public:
RWLock();
virtual ~RWLock() = default;
void lockWrite();
void unlockWrite();
void lockRead();
void unlockRead();
private:
volatile int m_readCount;
volatile int m_writeCount;
volatile bool m_isWriting;
std::mutex m_Lock;
std::condition_variable m_readCond;
std::condition_variable m_writeCond;
};
class ReadGuard {
public:
explicit ReadGuard(RWLock& lock);
virtual ~ReadGuard();
private:
ReadGuard(const ReadGuard&);
ReadGuard& operator=(const ReadGuard&);
private:
RWLock &m_lock;
};
class WriteGuard {
public:
explicit WriteGuard(RWLock& lock);
virtual ~WriteGuard();
private:
WriteGuard(const WriteGuard&);
WriteGuard& operator=(const WriteGuard&);
private:
RWLock& m_lock;
};
} /* namespace linduo */
#endif // RWLOCK__H
RWLock.cpp
#include "RWLock.h"
namespace linduo {
RWLock::RWLock()
: m_readCount(0)
, m_writeCount(0)
, m_isWriting(false) {
}
void RWLock::lockRead() {
std::unique_lock<std::mutex> gurad(m_Lock);
m_readCond.wait(gurad, [=] { return 0 == m_writeCount; });
++m_readCount;
}
void RWLock::unlockRead() {
std::unique_lock<std::mutex> gurad(m_Lock);
if (0 == (--m_readCount)
&& m_writeCount > 0) {
// One write can go on
m_writeCond.notify_one();
}
}
void RWLock::lockWrite() {
std::unique_lock<std::mutex> gurad(m_Lock);
++m_writeCount;
m_writeCond.wait(gurad, [=] { return (0 == m_readCount) && !m_isWriting; });
m_isWriting = true;
}
void RWLock::unlockWrite() {
std::unique_lock<std::mutex> gurad(m_Lock);
m_isWriting = false;
if (0 == (--m_writeCount)) {
// All read can go on
m_readCond.notify_all();
} else {
// One write can go on
m_writeCond.notify_one();
}
}
ReadGuard::ReadGuard(RWLock &lock)
: m_lock(lock) {
m_lock.lockRead();
}
ReadGuard::~ReadGuard() {
m_lock.unlockRead();
}
WriteGuard::WriteGuard(RWLock &lock)
: m_lock(lock) {
m_lock.lockWrite();
}
WriteGuard::~WriteGuard() {
m_lock.unlockWrite();
}
} /* namespace linduo */
使用
RWLock m_Lock;
void func() {
// 写锁
WriteGuard autoSync(m_Lock);
}
void func() {
// 读锁
ReadGuard autoSync(m_Lock);
}
多线程访问共享资源的时候，避免不了资源竞争而导致数据错乱的问题，所以我们通常为了解决这一问题，都会在访问共享资源之前加锁。
最常用的就是互斥锁，当然还有很多种不同的锁，比如自旋锁、读写锁、乐观锁等，不同种类的锁自然适用于不同的场景。
如果选择了错误的锁，那么在一些高并发的场景下，可能会降低系统的性能，这样用户体验就会非常差了。
所以，为了选择合适的锁，我们不仅需要清楚知道加锁的成本开销有多大，还需要分析业务场景中访问的共享资源的方式，再来还要考虑并发访问共享资源时的冲突概率。
对症下药，才能减少锁对高并发性能的影响。
那接下来，针对不同的应用场景，谈一谈「互斥锁、自旋锁、读写锁、乐观锁、悲观锁」的选择和使用。
最底层的两种就是会「互斥锁和自旋锁」，有很多高级的锁都是基于它们实现的，你可以认为它们是各种锁的地基，所以我们必须清楚它俩之间的区别和应用。
加锁的目的就是保证共享资源在任意时间里，只有一个线程访问，这样就可以避免多线程导致共享数据错乱的问题。
当已经有一个线程加锁后，其他线程加锁则就会失败，互斥锁和自旋锁对于加锁失败后的处理方式是不一样的：
互斥锁加锁失败后，线程会释放 CPU ，给其他线程；
自旋锁加锁失败后，线程会忙等待，直到它拿到锁；
互斥锁是一种「独占锁」，比如当线程 A 加锁成功后，此时互斥锁已经被线程 A 独占了，只要线程 A 没有释放手中的锁，线程 B 加锁就会失败，于是就会释放 CPU 让给其他线程，既然线程 B 释放掉了 CPU，自然线程 B 加锁的代码就会被阻塞。
对于互斥锁加锁失败而阻塞的现象，是由操作系统内核实现的。当加锁失败时，内核会将线程置为「睡眠」状态，等到锁被释放后，内核会在合适的时机唤醒线程，当这个线程成功获取到锁后，于是就可以继续执行。如下图：
所以，互斥锁加锁失败时，会从用户态陷入到内核态，让内核帮我们切换线程，虽然简化了使用锁的难度，但是存在一定的性能开销成本。
那这个开销成本是什么呢？会有两次线程上下文切换的成本：
当线程加锁失败时，内核会把线程的状态从「运行」状态设置为「睡眠」状态，然后把 CPU 切换给其他线程运行；
接着，当锁被释放时，之前「睡眠」状态的线程会变为「就绪」状态，然后内核会在合适的时间，把 CPU 切换给该线程运行。
线程的上下文切换的是什么？当两个线程是属于同一个进程，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的数据。
上下切换的耗时有大佬统计过，大概在几十纳秒到几微秒之间，如果你锁住的代码执行时间比较短，那可能上下文切换的时间都比你锁住的代码执行时间还要长。
所以，如果你能确定被锁住的代码执行时间很短，就不应该用互斥锁，而应该选用自旋锁，否则使用互斥锁。
自旋锁是通过 CPU 提供的 CAS 函数（Compare And Swap），在「用户态」完成加锁和解锁操作，不会主动产生线程上下文切换，所以相比互斥锁来说，会快一些，开销也小一些。
一般加锁的过程，包含两个步骤：
第一步，查看锁的状态，如果锁是空闲的，则执行第二步；
第二步，将锁设置为当前线程持有；
CAS 函数就把这两个步骤合并成一条硬件级指令，形成原子指令，这样就保证了这两个步骤是不可分割的，要么一次性执行完两个步骤，要么两个步骤都不执行。
使用自旋锁的时候，当发生多线程竞争锁的情况，加锁失败的线程会「忙等待」，直到它拿到锁。这里的「忙等待」可以用 while 循环等待实现，不过最好是使用 CPU 提供的 PAUSE 指令来实现「忙等待」，因为可以减少循环等待时的耗电量。
自旋锁是最比较简单的一种锁，一直自旋，利用 CPU 周期，直到锁可用。需要注意，在单核 CPU 上，需要抢占式的调度器（即不断通过时钟中断一个线程，运行其他线程）。否则，自旋锁在单 CPU 上无法使用，因为一个自旋的线程永远不会放弃 CPU。
自旋锁开销少，在多核系统下一般不会主动产生线程切换，适合异步、协程等在用户态切换请求的编程方式，但如果被锁住的代码执行时间过长，自旋的线程会长时间占用 CPU 资源，所以自旋的时间和被锁住的代码执行的时间是成「正比」的关系，我们需要清楚的知道这一点。
自旋锁与互斥锁使用层面比较相似，但实现层面上完全不同：当加锁失败时，互斥锁用「线程切换」来应对，自旋锁则用「忙等待」来应对。
它俩是锁的最基本处理方式，更高级的锁都会选择其中一个来实现，比如读写锁既可以选择互斥锁实现，也可以基于自旋锁实现。
读写锁从字面意思我们也可以知道，它由「读锁」和「写锁」两部分构成，如果只读取共享资源用「读锁」加锁，如果要修改共享资源则用「写锁」加锁。
所以，读写锁适用于能明确区分读操作和写操作的场景。
读写锁的工作原理是：
当「写锁」没有被线程持有时，多个线程能够并发地持有读锁，这大大提高了共享资源的访问效率，因为「读锁」是用于读取共享资源的场景，所以多个线程同时持有读锁也不会破坏共享资源的数据。
但是，一旦「写锁」被线程持有后，读线程的获取读锁的操作会被阻塞，而且其他写线程的获取写锁的操作也会被阻塞。
所以说，写锁是独占锁，因为任何时刻只能有一个线程持有写锁，类似互斥锁和自旋锁，而读锁是共享锁，因为读锁可以被多个线程同时持有。
知道了读写锁的工作原理后，我们可以发现，读写锁在读多写少的场景，能发挥出优势。
另外，根据实现的不同，读写锁可以分为「读优先锁」和「写优先锁」。
读优先锁期望的是，读锁能被更多的线程持有，以便提高读线程的并发性，它的工作方式是：当读线程 A 先持有了读锁，写线程 B 在获取写锁的时候，会被阻塞，并且在阻塞过程中，后续来的读线程 C 仍然可以成功获取读锁，最后直到读线程 A 和 C 释放读锁后，写线程 B 才可以成功获取读锁。如下图：
而写优先锁是优先服务写线程，其工作方式是：当读线程 A 先持有了读锁，写线程 B 在获取写锁的时候，会被阻塞，并且在阻塞过程中，后续来的读线程 C 获取读锁时会失败，于是读线程 C 将被阻塞在获取读锁的操作，这样只要读线程 A 释放读锁后，写线程 B 就可以成功获取读锁。如下图：
读优先锁对于读线程并发性更好，但也不是没有问题。我们试想一下，如果一直有读线程获取读锁，那么写线程将永远获取不到写锁，这就造成了写线程「饥饿」的现象。
写优先锁可以保证写线程不会饿死，但是如果一直有写线程获取写锁，读线程也会被「饿死」。
既然不管优先读锁还是写锁，对方可能会出现饿死问题，那么我们就不偏袒任何一方，搞个「公平读写锁」。
公平读写锁比较简单的一种方式是：用队列把获取锁的线程排队，不管是写线程还是读线程都按照先进先出的原则加锁即可，这样读线程仍然可以并发，也不会出现「饥饿」的现象。
互斥锁和自旋锁都是最基本的锁，读写锁可以根据场景来选择这两种锁其中的一个进行实现。
前面提到的互斥锁、自旋锁、读写锁，都是属于悲观锁。
悲观锁做事比较悲观，它认为多线程同时修改共享资源的概率比较高，于是很容易出现冲突，所以访问共享资源前，先要上锁。
那相反的，如果多线程同时修改共享资源的概率比较低，就可以采用乐观锁。
乐观锁做事比较乐观，它假定冲突的概率很低，它的工作方式是：先修改完共享资源，再验证这段时间内有没有发生冲突，如果没有其他线程在修改资源，那么操作完成，如果发现有其他线程已经修改过这个资源，就放弃本次操作。
放弃后如何重试，这跟业务场景息息相关，虽然重试的成本很高，但是冲突的概率足够低的话，还是可以接受的。
可见，乐观锁的心态是，不管三七二十一，先改了资源再说。另外，你会发现乐观锁全程并没有加锁，所以它也叫无锁编程。
这里举一个场景例子：在线文档。
我们都知道在线文档可以同时多人编辑的，如果使用了悲观锁，那么只要有一个用户正在编辑文档，此时其他用户就无法打开相同的文档了，这用户体验当然不好了。
那实现多人同时编辑，实际上是用了乐观锁，它允许多个用户打开同一个文档进行编辑，编辑完提交之后才验证修改的内容是否有冲突。
怎么样才算发生冲突？这里举个例子，比如用户 A 先在浏览器编辑文档，之后用户 B 在浏览器也打开了相同的文档进行编辑，但是用户 B 比用户 A 提交改动，这一过程用户 A 是不知道的，当 A 提交修改完的内容时，那么 A 和 B 之间并行修改的地方就会发生冲突。
服务端要怎么验证是否冲突了呢？通常方案如下：
由于发生冲突的概率比较低，所以先让用户编辑文档，但是浏览器在下载文档时会记录下服务端返回的文档版本号；
当用户提交修改时，发给服务端的请求会带上原始文档版本号，服务器收到后将它与当前版本号进行比较，如果版本号一致则修改成功，否则提交失败。
实际上，我们常见的 SVN 和 Git 也是用了乐观锁的思想，先让用户编辑代码，然后提交的时候，通过版本号来判断是否产生了冲突，发生了冲突的地方，需要我们自己修改后，再重新提交。
乐观锁虽然去除了加锁解锁的操作，但是一旦发生冲突，重试的成本非常高，所以只有在冲突概率非常低，且加锁成本非常高的场景时，才考虑使用乐观锁。
开发过程中，最常见的就是互斥锁的了，互斥锁加锁失败时，会用「线程切换」来应对，当加锁失败的线程再次加锁成功后的这一过程，会有两次线程上下文切换的成本，性能损耗比较大。
如果我们明确知道被锁住的代码的执行时间很短，那我们应该选择开销比较小的自旋锁，因为自旋锁加锁失败时，并不会主动产生线程切换，而是一直忙等待，直到获取到锁，那么如果被锁住的代码执行时间很短，那这个忙等待的时间相对应也很短。
如果能区分读操作和写操作的场景，那读写锁就更合适了，它允许多个读线程可以同时持有读锁，提高了读的并发性。根据偏袒读方还是写方，可以分为读优先锁和写优先锁，读优先锁并发性很强，但是写线程会被饿死，而写优先锁会优先服务写线程，读线程也可能会被饿死，那为了避免饥饿的问题，于是就有了公平读写锁，它是用队列把请求锁的线程排队，并保证先入先出的原则来对线程加锁，这样便保证了某种线程不会被饿死，通用性也更好点。
互斥锁和自旋锁都是最基本的锁，读写锁可以根据场景来选择这两种锁其中的一个进行实现。
另外，互斥锁、自旋锁、读写锁都属于悲观锁，悲观锁认为并发访问共享资源时，冲突概率可能非常高，所以在访问共享资源前，都需要先加锁。
相反的，如果并发访问共享资源时，冲突概率非常低的话，就可以使用乐观锁，它的工作方式是，在访问共享资源时，不用先加锁，修改完共享资源后，再验证这段时间内有没有发生冲突，如果没有其他线程在修改资源，那么操作完成，如果发现有其他线程已经修改过这个资源，就放弃本次操作。
但是，一旦冲突概率上升，就不适合使用乐观锁了，因为它解决冲突的重试成本非常高。
不管使用的哪种锁，我们的加锁的代码范围应该尽可能的小，也就是加锁的粒度要小，这样执行速度会比较快。再来，使用上了合适的锁，就会快上加快了。