一、线程互斥
引入
要理解线程互斥的概念，首先我们要先从为什么线程需要互斥这个点切入。
我们先来看看下面这串代码，这是一段有关抢票的代码。
C++算法
Linux 线程同步与互斥机制详解
Linux 多线程编程中，线程互斥通过锁机制（如 mutex）保护临界资源，防止数据竞争；线程同步利用条件变量协调执行顺序，解决生产者消费者模型中的阻塞与唤醒问题；同时需警惕死锁风险，通过固定顺序获取资源或一次性获取所有资源来避免。核心在于原子性操作与合理的锁管理。
Linux 多线程编程中，线程互斥通过锁机制（如 mutex）保护临界资源，防止数据竞争；线程同步利用条件变量协调执行顺序，解决生产者消费者模型中的阻塞与唤醒问题；同时需警惕死锁风险，通过固定顺序获取资源或一次性获取所有资源来避免。核心在于原子性操作与合理的锁管理。
要理解线程互斥的概念，首先我们要先从为什么线程需要互斥这个点切入。
我们先来看看下面这串代码，这是一段有关抢票的代码。
运行结果：
我们让三个线程同时进行抢票，发现票数被抢到了负数，这样的结果当然不符合我们的预期。
票数抢到负数是因为线程产生了竞态关系，当一个线程达到 0 时，另一个线程可能刚好执行了 -- 的代码，此时当前的线程在进行 -- 就出现了负数。
当多个线程访问共享资源时，如果不考虑线程安全问题，可能会导致数据丢失、错误等原因。
互斥就是相互排斥，有你没我，与互斥相对的一组是并发，并发就是可以同时存在。
我们将这组概念带入线程中，互斥就是在同一时间，只能有一个线程对共享资源进行访问；线程并发就是在同一时间，线程同时竞争共享资源。
同步与异步是相对的，同步必须等待被调用方执行完毕并返回结果才能继续执行后续操作，相当于线程被阻塞住了。异步就是多个线程自己执行自己的内容，不需要关心其他的线程。
原子性操作是指当一个线程执行一段代码的时候，此时不能切换到其他线程，必须执行完当前线程的代码才能进行切换。
临界资源是指在多线程环境下，不能被线程同时访问和使用的资源，即被使用的共享资源就是临界资源。临界区指访问临界资源的代码块，从起点到终点，这块地方就是临界资源。
为了保护这些临界资源，操作系统提供了一些机制。给临界资源进行上锁，使用信号量进行访问控制等等。
对于上述的抢票代码，票数产生了负数。在线程代码中 usleep 进行了一段休眠，这会导致很多线程进入该代码段，而且 ticket-- 本身就不是一个原子操作，所以说，要解决上述的问题，我们就要对临界区进行保护，于是我们便有了锁，用来对临界资源进行上锁，使得在临界区当中，每次运行只允许一个线程执行。
操作系统给出了互斥锁（mutex）用于解决当前情况。它可以保证在相同时间下，只有一个线程可以访问共享资源或代码段。互斥锁的用法也很简单，首先定义一个互斥锁对象，在临界区处进行上锁，在临界区末尾释放锁。线程拿到锁进行原子操作，执行完临界区代码后会释放锁，其他的线程会在临界区外部等待锁，只有拿到了锁才能进入临界区进行访问。这样使得临界区每次进行访问只有拥有锁的线程才能进行访问，保证了线程执行的安全性。
下面我们来介绍一下 POSIX 线程库封装的一些线程互斥接口。
POSIX 线程库中用于操作互斥量的函数都以 pthread_mutex 打头：
初始化互斥量：
静态初始化互斥量：pthread_mutex_t
静态初始化的互斥量不需要进行 destroy 操作，程序结束会自动回收
动态初始化互斥量：pthread_mutex_init
参数：
mutex：指向类型变量的指针
mutexattr：给 mutex 设置属性，我们一般使用 nullptr 默认值
销毁互斥量：
动态分配后的互斥锁若不使用需要进行回收
pthread_mutex_destroy：
参数：
mutex：指向类型变量的指针
互斥量加锁和解锁：
对临界区资源进行加锁解锁，当互斥量处于未锁状态，该函数会将互斥量锁定，若其他线程已经锁定该互斥量，那么该执行流会被阻塞挂起，等待互斥量解锁
pthread_mutex_lock：
pthread_mutex_unlock:
参数：
mutex：指向类型变量的指针
全局锁与局部锁
全局锁：
全局锁是全局变量或静态变量，所有线程都可以访问，优点是可以保护全局资源，缺点在于所有的线程都可以访问，频繁的访问导致并发效率降低
局部锁：
局部锁是定义在局部变量的锁，它服务于局部某个特定的函数当中，虽然作用范围有限，但服务于专一对象并发效率高。
上锁解锁都是原子性的操作，原子性的操作要求 CPU 在执行指令的时候要尽可能的短，只执行一条语句。我们来看一下伪代码
锁的操作是原子的，当一把锁被频繁的调用时，意味着它对 CPU 性能的开销也逐渐增大。
互斥锁的创建销毁，加锁解锁，等待唤醒，竞争阻塞都会对资源进行消耗。所以说，我们要合理规划使用锁资源，尽量减少互斥锁的保护范围，缩短锁的持有时间尽快释放锁，根据不同场景用不同的锁来进一步提升效率。
互斥锁和自旋锁是两种常见的同步机制，它们的区别在于，当一个线程获取一个被占用的锁时，互斥锁会进行挂起等待，等待锁的释放；而自旋锁会不断地循环访问，直到锁的释放。互斥锁可以避免浪费 CPU 资源，不需要频繁进行访问，但是会增加上下文切换开销；自旋锁频繁访问会增加 CPU 资源消耗，但可以减少上下文的切换。
#pragma once
#include <iostream>
#include <pthread.h>
using namespace std;
class Mutex {
public:
Mutex() {
int n = pthread_mutex_init(&mutex, nullptr);
(void)n;
}
void Lock() {
pthread_mutex_lock(&mutex);
}
void Unlock() {
pthread_mutex_unlock(&mutex);
}
~Mutex() {
int n = pthread_mutex_destroy(&mutex);
}
private:
pthread_mutex_t mutex;
};
class LockGuard {
public:
LockGuard(Mutex &mutex) : _mutex(mutex) {
_mutex.Lock();
}
~LockGuard() {
_mutex.Unlock();
}
private:
Mutex &_mutex;
};
什么是同步？同步就是在安全的前提下你，线程按照某种顺序访问临界资源。什么是竞态条件？在多线程中，同时访问或修改共享资源，最终结果依赖于线程执行的相对顺序，从而导致程序出现不可预测行为的现象。
条件变量就是一个条件，当线程不满足该条件时，就主动进行阻塞，不需要轮询的访问；当条件满足时，根据队列排序对线程进行唤醒。这样节省了 CPU 的资源消耗，它通常与互斥锁绑定。
下面我们来介绍一下 POSIX 线程库封装的一些线条件变量接口。
POSIX 线程库中用于操作条件变量的函数都以 pthread_cond 打头：
初始化：
静态初始化条件变量：pthread_cond_t
静态初始化的条件变量不需要 destroy 进行销毁，但是只能指向一个对象
动态初始化条件变量：pthread_cond_init
动态创建的条件变量较为灵活，可以更改指向的锁对象，当我们不使用该条件变量时，我们需要 进行 destroy 销毁
销毁：
动态创建的条件变量在结尾需要进行销毁
pthread_cond_destroy：
参数：
cond：当前条件变量指针
返回值：
成功返回 0，失败返回错误码
等待条件：
当条件不满足时，线程会自动释放锁进入阻塞状态，其他的线程可以拿被释放的锁执行任务，被阻塞的线程需要等待唤醒信号，被唤醒的线程将会重新获取锁
pthread_cond_wait：
参数：
cond：当前条件变量指针
mutex：互斥量，即互斥锁
返回值：
成功返回 0，失败返回错误码
唤醒等待：
通常与等待线程的接口一同使用，用于唤醒线程（等待前必须有锁）
pthread_cond_broadcast：
唤醒所有等待条件变量的线程
参数：
cond：当前条件变量指针
返回值：
成功返回 0，失败返回错误码
pthread_cond_signal：
唤醒单个等待条件变量的线程
参数：
cond：当前条件变量指针
返回值：
成功返回 0，失败返回错误码
线程唤醒和线程等待必须配合锁进行使用，类似于我们使用一个公共微波炉，只有持有锁的人才能使用这个微波炉。如果我们在持有锁前进行等待，就相当于微波炉是空的，但你确一直在等待。当我们进入临界区后，相当于一排人排队等着微波炉（wait 等待），唤醒相当于前一个人使用完微波炉轮询到下一个。
下面我们来讲一下虚假唤醒，所谓的虚假唤醒是因为错误的认为'条件已满足'，从而执行不符合的操作，最典型的就是 if 语句。
我们来看一下下面这串代码
当线程队列为空时，if 语句为 true，进入了 if 循环体当中进入线程等待，若线程等待成功后，此时不会再次进行 if 判断，此时直接执行 pop 操作，就会导致出错。
处理虚假唤醒的唯一方法就是使用 while 循环而不是 if 条件语句的判断，我们来看一下正确的代码
此时，线程等待成功后会再次进入 while 循环进行判断，队列不为空才继续向下执行。
线程的唤醒信号是不被缓存的，当一个线程发送了一个唤醒信号时，如果没有任何线程在等待该条件变量，这个信号就会直接'失效'不会进行缓存。例如，当我们将唤醒信号放在等待操作前，当信号丢失时，等待线程会永久阻塞。
我们来看一下正确的使用方法
我们可以使用一个计数器用来记录信号传递次数，用计数器的方式代替信号唤醒机制，这样即使信号失效了，也可以让线程知道是否需要进行等待。
避免信号丢失的关键在于用共享变量记录条件状态在等待前先检查变量
生产者消费者模型要符合'321'原则，即 3 种关系，2 个角色，1 个交易场所。下面我们按照 321 来讲解生产者消费者模型。
类似于我们日常生活，在我们生活中，工厂一般扮演着生产者的角色生产各种各样的东西，许多工厂的货物被集中到超市进行售卖，由消费者来在超市中购买货物。工厂不会直接的把货物交到消费者的手中，消费者也不会直接的去工厂进行购入货物。将这套模型运用到计算机中，此时，工厂就是生产者，负责生产数据，任务，消息等等；超市就是共享缓冲区，来获取数据提供数据；消费者在超市中取数据将数据进行进一步处理。这套模型完成了数据生成与数据处理的解耦，提升了程序的稳定性。
1 个交易场所就是共享内存，2 个角色分别是生产者消费者，3 种关系为生产者与生产者的关系消费者与消费者的关系，生产者与消费者的关系。
下面我们就来讲讲者这三种关系。
生产者与生产者的关系是竞争关系，不同的生产者需要竞争锁，因为向共享区中写入数据需要保证原子性，它们之间需要竞争缓冲区的写入权。
消费者和消费者的关系是竞争关系，不同的消费者也需要竞争锁，保证消费者取数据不取重，消费者之间需要竞争读取数据权。
生产者与消费者之间是协助关系，生产者向共享区当中写入数据，此时应该通知消费者共享区当中有数据；消费者进入共享区当中消费数据，当数据消耗完后，需要通知生产者及时生产数据。
生产者消费者模型完成了数据生产和数据使用之间的解耦操作，生产者无需知道消费者的存在消费者也无需生产者的存在。后续可以加入新的生产者或者消费者扩展性强。同时，该模型还可以处理速度不匹配的问题，例如生产速度快，可以在缓冲区当中进行缓存。
#include <iostream>
#include <queue>
#include <pthread.h>
#include "Mutex.hpp"
#include "Cond.hpp"
using namespace std;
static int defaultnum = 10;
template <typename T>
class Blockqueue {
private:
bool _isfull() { return _q.size() >= defaultnum; }
bool _isempty() { return _q.empty(); }
public:
Blockqueue(int cap = defaultnum) : _s_sleep(0), _p_sleep(0), _cap(cap) { }
void Enqueue(const T &in) {
{
LockGuard(_mutex);
while (_isfull()) {
_p_sleep++;
cout << "生产队列已满" << endl;
_full_cond.Wait(_mutex);
_p_sleep--;
}
q.push(in); // 修正逻辑错误
if (_s_sleep > 0) {
_empty_cond.Signal();
cout << "唤醒消费者" << endl;
}
}
}
T Pop() {
T data;
{
LockGuard(_mutex);
while (_isempty()) {
_s_sleep++;
cout << "消费队列为空" << endl;
_empty_cond.Wait(_mutex);
_s_sleep--;
}
data = q.front();
q.pop();
if (_p_sleep > 0) {
_full_cond.Signal();
cout << "唤醒生产者" << endl;
}
}
return data;
}
~Blockqueue() { }
private:
queue<T> _q; // 存放
int _cap; // 容量
int _s_sleep; // 消费者休眠数
int _p_sleep; // 生产者休眠数
Mutex _mutex;
Cond _full_cond; // 队列满条件
Cond _empty_cond; // 队列空条件
};
等待条件代码：
给条件发送信号代码：
条件变量接口封装：
#pragma once
#include <iostream>
#include <pthread.h>
#include "Mutex.hpp"
using namespace std;
class Cond {
public:
Cond() {
int n = pthread_cond_init(&cond,nullptr);
}
void Wait(Mutex &mutex) {
pthread_cond_wait(&cond,mutex.Get());
}
void Signal() {
pthread_cond_signal(&cond);
}
void Broadcast() {
pthread_cond_broadcast(&cond);
}
~Cond() {
int n = pthread_cond_destroy(&cond);
}
private:
pthread_cond_t cond;
};
POSIX 信号量与 SystemV 信号量作用相同，都是原子操作的计数器，但 POSIX 的信号量主要服务于线程和进程中。
下面我们来介绍一下相关接口：
sem_init：
信号量初始化
参数：
sem：指向信号量的指针
pshared：0 表示线程间共享，非 0 表示进程间共享
value：信号量初始值
返回值：
成功返回 0，失败返回 -1
sem_destroy：
信号量销毁
参数：
sem：指向信号量的指针
返回值：
成功返回 0，失败返回 -1
sem_wait：
信号量等待，信号量数量 -1
参数：
sem：指向信号量的指针
返回值：
成功返回 0，失败返回 -1
sem_post：
归还信号量，信号量数量 +1
参数：
sem：指向信号量的指针
返回值：
成功返回 0，失败返回 -1
Ringqueue.hpp：
Main.cc：
死锁指在进程中各个进程占有不会释放的资源，但因互相申请被其他进程所占用的资源导致处于一种永久的等待状态。
假设现在有两个线程，访问临界资源需要两把锁，此时线程 A 占了一把锁，线程 B 占了一把锁，它们互相都想要对方的锁，导致进入两边都在等待对方手里的锁因此进入了线程等待。
此时，线程 A 持有锁 1，线程 B 持有锁 2，线程 A 尝试获取锁 2，线程 B 尝试获取锁 1.它们都互相申请对方的锁但是不释放自己的锁。
那么该如何避免死锁呢？拿上述的例子来讲。
方法一：
设置一个时间限制，若超出了当前的时间还未获取到锁那么就主动释放锁。
方法二：
我们可以让所有线程必须按照固定顺序获取资源，必须先获取锁 1 之后才能获取锁 2。我们按照顺序给临界资源上锁即可。
错误示范：
正确示范：
方法三：
一次性的获取所有的资源，我们可以让线程一次性获取两把锁，这样就不会造成一人一把锁的状况。
正确示范：
线程同步与互斥是多线程编程的'基石'，核心目标是解决'数据安全'和'顺序可控'问题：
互斥：用锁（互斥锁、读写锁）保证共享资源的原子访问，避免数据竞争；
同步：用条件变量、信号量协调线程执行顺序，满足逻辑依赖；
避坑重点：锁必须成对使用，条件变量需处理虚假唤醒，同步逻辑需避免死锁。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML转Markdown在线工具，online
通过删除不必要的空白来缩小和压缩JSON。 在线工具，JSON 压缩在线工具，online