[Linux——Lesson26.线程：线程安全及其他理论]-优快云博客

多核时代下，并发编程成为开发者核心能力，能显著提升程序性能，但也伴随死锁、内存紊乱、单例重复创建等线程安全问题。

本文按“问题定义—解决方案—实践落地”脉络，先解析死锁概念及解决策略，明确并发冲突诱因与规避思路。进而聚焦C++核心疑问：厘清STL容器与智能指针的线程安全边界；详解互斥锁等常见锁的设计与适用场景。针对单例模式，剖析原生懒汉模式隐患及双重检查锁定的实现精髓；最后通过自旋锁与读者写者问题，展现并发协调思路。

本文为初涉并发及进阶开发者提供清晰知识框架，助力规避风险、高效编码。🕵️

一、😗死锁概念

死锁是指在一组进程中的各个进程均占有不会释放的资源，但因互相申请被其他进程所站用不会释放的资源而处于的一种永久等待状态。

如果现在有两个线程thread1和thread2，整个体系之中存在两把锁，mutex1和mutex2，现在出现这这样一种情况：

thread1已经持有锁1，thread2已经持有锁2，
而此时thread1需要mutex2锁才能继续执行，那么thread1就等待mutex2释放，而thread2这时也需要mutex1才能继续执行，
所以thread2也需要等待thread1释放mutex1，这样两个线程相互等待对方释放锁才能继续运行后续代码。

这种情况是典型的死锁（Deadlock）现象。死锁是指两个或多个线程相互等待对方释放自己所需要的资源，从而导致所有线程都陷入无限期阻塞，无法继续执行的状态。

其实很简单，张三来到一个小吃摊前面，跟老板说，xxx好吃吗？我先来尝尝，好吃我就买。老板这时就急眼了，小本生意，不买就别吃。张三又说，我不吃怎么知道好不好吃，好吃我才买。总之张三跟老板谁也不让。这就是一种死锁，虽然现实当中这种事很荒唐，但是在计算机当中这种问题是非常重要的。

死锁会导致占用公共资源不释放，甚至可能会造成饥饿问题，所以程序员需要避免死锁的情况。

死锁产生的四个必要条件：

互斥条件：一个资源每次只能被一个执行流使用
请求与保持条件：一个执行流因请求资源而阻塞时，对已获得的资源保持不放
不剥夺条件: 一个执行流已获得的资源，在末使用完之前，不能强行剥夺
循环等待条件: 若干执行流之间形成一种头尾相接的循环等待资源的关系

二、🤔解决死锁方法

避免死锁只需破坏死锁产生的四个必要条件（互斥条件、请求与保持条件、不剥夺条件、循环等待条件）中的任意一条或多条。以下是一些具体的解决死锁的方法：

破坏互斥条件：尽量使用可共享的资源，减少互斥资源的使用。例如，对于打印机等资源，可通过 SPOOLing 技术将其虚拟化为可共享资源。对于一些读操作较多的场景，可使用读写锁，允许多个线程同时进行读操作，只在写操作时才需要互斥，从而减少锁的使用，降低死锁风险。
破坏请求与保持条件：
一次性分配策略：进程在启动前，一次性申请其运行过程中所需的所有资源。若所有资源都能满足，则进程开始执行；若不能满足，则进程等待直到所有资源可用。这种方法能有效避免进程持有部分资源又等待其他资源的情况，但资源利用率可能较低。
释放再申请策略：要求进程在申请新资源前，先释放其已持有的所有资源，然后再重新一次性申请所需的全部资源。

破坏不剥夺条件：
进程主动释放：如果占有某些资源的进程进一步请求其他资源被拒绝，那么该进程必须释放它最初占有的资源，之后可再次请求这些资源和其他资源。
操作系统抢占：如果一个进程请求当前被另一个进程占有的资源，操作系统可根据线程优先级等策略，抢占另一个进程的资源并分配给请求进程。但这种方式需要解决好进程状态回滚、数据一致性等问题，否则可能导致系统不稳定。

破坏循环等待条件：给所有资源编号，规定进程必须按照资源编号递增的顺序申请资源。例如，资源编号为 R1、R2、R3，进程只能先申请 R1，再申请 R2，最后申请 R3，不能反向申请，从而避免循环等待的发生。

此外，还有死锁检测与恢复策略。该策略允许死锁发生，通过死锁检测算法定期检查系统中是否存在死锁。一旦检测到死锁，选择一个或多个牺牲进程，回滚这些进程，释放它们持有的资源，以打破死锁循环。

三、😋C++中STL、智能指针是否线程安全

3-1 🍕STL 容器：默认不保证线程安全

STL 容器的设计核心目标是极致性能，而线程安全（如加锁）会显著增加性能开销，且不同容器的最优加锁方式存在差异（例如哈希表的 “锁表” 与 “锁桶” 策略效率不同），因此 C++ 标准未强制要求 STL 容器实现线程安全。

具体风险场景

当多个线程对同一 STL 容器执行写操作（如push_back、erase、insert）或读写混合操作时，可能导致容器内部数据结构（如链表节点、红黑树平衡、哈希桶索引）损坏，出现野指针、数据不一致或程序崩溃。

线程安全的实现方式

若需在多线程环境中使用 STL 容器，需由开发者自行保证线程安全，常见方案包括：

对容器的所有访问（读 + 写）加全局互斥锁（如std::mutex），确保同一时间只有一个线程操作容器；
针对高频读、低频写场景，使用读写锁（如std::shared_mutex），允许多线程同时读，仅写操作时互斥；
对哈希表等容器，采用细粒度锁（如 “锁桶”），仅对操作的目标桶加锁，提升并发效率。

3-2 🍔智能指针：分类型判断，部分保证线程安全

C++ 智能指针（unique_ptr、shared_ptr等）的线程安全特性与自身语义强相关，需按类型区分：

智能指针类型 线程安全特性 核心原因
unique_ptr 线程安全（无风险） 语义上 “独占所有权”，同一时间只有一个unique_ptr指向对象，且不允许拷贝（仅支持移动），不存在多线程竞争同一对象的场景，因此无需额外线程安全保障。
shared_ptr 部分线程安全
语义上 “共享所有权”，多个shared_ptr会共用一个引用计数变量：

1. 引用计数的操作（递增 / 递减）：标准库通过原子操作（CAS） 保证线程安全，避免计数竞争导致的内存泄漏或 double free；2. shared_ptr指向的对象本身：不保证线程安全。若多线程通过shared_ptr修改对象内容，仍需开发者自行加锁（如std::mutex）保护对象。

3-3 🍟总结

STL 容器：默认无线程安全，需开发者通过锁机制手动保障；
智能指针：unique_ptr天然无线程安全风险，shared_ptr仅保证 “引用计数操作” 的线程安全，对象本身的线程安全需额外处理。

四、😁其他常见各种锁

悲观锁：在每次取数据时，总是担心数据会被其他线程修改，所以会在取数据前先加锁（读锁，写锁，行锁等），当其他线程想要访问数据时，被阻塞挂起。
乐观锁：每次取数据时候，总是乐观的认为数据不会被其他线程修改，因此不上锁。但是在更新数据前，会判断其他数据在更新前有没有对数据进行修改。主要采用两种方式：版本号机制和CAS操作。
CAS操作：当需要更新数据时，判断当前内存值和之前取得的值是否相等。如果相等则用新值更新。若不等则失败，失败则重试，一般是一个自旋的过程，即不断重试。
自旋锁，公平锁，非公平锁？

我们前面学习的不论是互斥锁还是二元信号量都属于悲观锁的范畴，担心数据被其线程修改所以提前加锁。

五、😉单例模式线程安全

在设计模式体系中，单例模式是最基础且应用广泛的创建型模式之一。对于接触过设计模式的开发者来说，懒汉模式是单例模式的典型实现形式；即使是初学者，通过下文的梳理也能快速掌握其核心逻辑及线程安全要点。

5-1 🌭单例模式核心定义

单例模式的核心诉求非常明确：在整个进程的生命周期内，目标类有且仅存在一个实例对象，所有对该类实例的访问都指向这一唯一实例。需要特别说明的是，这种唯一性约束仅限于当前进程，跨进程场景下需结合进程间通信等机制额外控制。

根据实例创建时机的不同，单例模式主要分为两大实现类型：

饿汉模式：进程启动时（类加载阶段）就主动创建实例，无论后续是否会使用该实例。其优势是实现简单且天然线程安全，缺点是可能造成资源浪费（如实例未被使用但已占用内存）。

懒汉模式：遵循“延迟加载”原则，即直到第一次调用获取实例的接口时，才创建唯一实例。这种方式能避免不必要的资源消耗，但原生实现存在线程安全隐患，需要额外设计来保证唯一性。

5-2 🍿原生懒汉模式的线程安全隐患

懒汉模式的核心思想是“用的时候再创建”，以下是C++语言的基础实现代码：
template <typename T>
class Singleton {
    static T* inst; // 静态成员变量，存储唯一实例指针
public:
    static T* GetInstance() 
    {
        if (inst == NULL)  // 判断实例是否已创建
        {
            inst = new T(); // 未创建则新建实例
        }
        return inst; // 返回实例指针
    }
};

// 静态成员变量类外初始化
template <typename T>
T* Singleton<T>::inst = NULL;
上述代码在单线程环境下完全可行：第一次调用GetInstance()时，inst为NULL，执行new T()创建实例并赋值；后续调用时，因inst已非NULL，直接返回现有实例，保证了唯一性。

但在多线程并发场景下，这种实现会彻底失效。问题的根源在于if (inst == NULL)的判断和inst = new T()的创建操作并非“原子操作”，多个线程可能同时进入“实例未创建”的分支，从而创建多个实例。具体过程可拆解为以下场景：

线程A调用GetInstance()，判断inst == NULL为真，准备执行new T()，但尚未完成创建（如处于内存分配或构造函数执行阶段）。

此时线程B也调用GetInstance()，同样判断inst == NULL（因线程A的创建操作未完成，inst仍为NULL），也进入分支执行new T()。

最终线程A和线程B分别创建了一个实例，inst指针会被最后完成赋值的线程覆盖，导致前一个实例成为“野指针”（内存泄漏），且彻底破坏了单例的唯一性约束。

5-3 🧂线程安全的懒汉模式实现：双重检查锁定

要解决懒汉模式的线程安全问题，核心是对“实例创建”这一临界资源进行保护，确保同一时刻只有一个线程能执行创建逻辑。最经典的解决方案是双重检查锁定（Double-Checked Locking），其设计思路是“加锁前先判断、加锁后再判断”，兼顾线程安全和性能。

1️⃣核心实现逻辑

双重检查锁定的核心优化点在于：仅在实例未创建时才进行加锁操作，避免每次调用接口都加锁导致的性能损耗。具体实现代码如下：
template <typename T>
class Singleton {
    static T* inst;
    // 注意：实际开发中需使用对应编程语言的线程锁，如C++11的std::mutex
    static Mutex lock; // 线程锁，保护临界区
public:
    static T* GetInstance() 
    {
        // 第一次检查：未加锁，快速判断实例是否已创建
        if (nullptr == inst) 
        {
            lock.Lock(); // 加锁，进入临界区
            // 第二次检查：加锁后再次判断，避免多线程竞争导致重复创建
            if (nullptr == inst) 
            {
                inst = new T(); // 创建唯一实例
            }
            lock.Unlock(); // 解锁，释放临界区
        }
        return inst;
    }
};

// 静态成员变量类外初始化
template <typename T>
T* Singleton<T>::inst = nullptr;

template <typename T>
Mutex Singleton<T>::lock;
2️⃣关键设计解析

双重检查锁定的安全性和高效性，源于“两次检查 + 一次加锁”的组合设计，具体作用如下：

第一次检查（未加锁）：作为“快速通道”，如果实例已创建（inst != nullptr），直接返回实例，无需执行加锁操作。这能避免后续每次调用接口都加锁解锁带来的性能开销，是对“懒汉模式”效率的重要优化。

加锁操作：当第一次检查发现实例未创建时，通过加锁将后续逻辑变为“原子操作”，确保同一时刻只有一个线程能进入临界区执行实例创建逻辑。

第二次检查（加锁后）：防止多线程竞争导致的重复创建。例如，线程A加锁前，线程B已通过第一次检查并等待锁；当线程A创建实例并解锁后，线程B获取锁，此时第二次检查会发现inst != nullptr，直接退出临界区，避免重复创建。

3️⃣额外注意事项

此外，实际开发中还需考虑单例实例的销毁问题（如进程退出时释放资源），可通过添加静态析构函数或使用智能指针等方式优化，避免内存泄漏。

5-4 🥓总结

懒汉模式的线程安全问题本质是“临界资源竞争”，即多线程同时执行实例创建逻辑导致的重复实例化。双重检查锁定通过“两次判断 + 精准加锁”的设计，既保证了单例的唯一性（线程安全），又通过“首次无锁检查”优化了性能，是懒汉模式的标准线程安全实现方案。
需特别注意的是，不同编程语言的内存模型和线程库存在差异（如Java的volatile语义、C++的原子操作），在实际编码时需结合语言特性完善实现，避免因底层机制问题导致的安全隐患。

六、😃自旋锁：线程世界的“等待艺术”

在多线程编程中，我们常关注如何通过锁机制保护临界资源，但很少深入探讨：当线程无法立即获取临界资源时，应该“如何等待”❓不同的等待方式，对应着不同的锁设计，而自旋锁正是为特定场景量身定制的“高效等待方案”。

我们可以通过一个生活化的故事，轻松理解自旋锁的核心逻辑：

第一天，阿熊11点就到小美楼下约饭。小美一看时间还早，手头还有未完成的工作，便回复阿熊：“我得忙好一会儿，你要是着急就先自己吃吧。”阿熊心想“等这么久太浪费时间”，于是决定先去网吧打游戏，等小美忙完再联系他。到了下午1点，小美完成工作后联系阿熊，两人才一起去吃饭。
第二天，阿熊12点准时赴约，这次小美刚好饿了，手头也没有工作，立刻回电话：“我马上下来，你稍等一下！”阿熊一听“马上就好”，就站在楼下静静等待——果然，短短几分钟后小美就下来了。

这个故事恰好映射了线程获取临界资源时的两种核心等待策略，我们来逐一拆解：

1️⃣第一种等待：“暂时离开，回头再来”——对应互斥锁

故事中第一天的场景，阿熊发现小美需要“很久”才能赴约，于是选择“去网吧打游戏”（暂时放弃等待，去做其他事），这对应线程编程中的互斥锁（如pthread_mutex_t）逻辑。当线程尝试获取临界资源时，如果发现资源正被其他线程占用，且判断对方“在临界区内执行时间较长”，线程会主动放弃CPU使用权，进入阻塞挂起状态——就像阿熊离开楼下去网吧一样，不再消耗CPU资源，直到资源释放后被操作系统唤醒。

2️⃣第二种等待：“原地待命，即刻响应”——对应自旋锁

第二天的场景中，阿熊得知小美“马上就好”，选择“在楼下静静等待”，这种“不离开、持续等待直到目标就绪”的行为，就是自旋锁的核心逻辑。当线程尝试获取临界资源时，如果发现资源被占用，但判断对方“在临界区内执行时间极短”，线程会持续循环检查资源状态（即“自旋”），全程不放弃CPU使用权。一旦资源释放，线程就能“即刻抢占”，避免了线程阻塞-唤醒过程中的性能开销。

Linux pthread线程库中的自旋锁接口

正因为自旋锁在“短临界区”场景下的高效性，Linux的pthread线程库专门提供了自旋锁相关接口，核心操作包括初始化、加锁、解锁和销毁，具体如下：

接口函数

功能说明

关键注意事项

pthread_spin_init()

初始化自旋锁

需指定锁的共享属性（如PTHREAD_PROCESS_PRIVATE表示进程内线程共享）

pthread_spin_lock()

获取自旋锁（自旋等待直到成功）

若锁已被占用，当前线程会持续循环检查，不释放CPU

pthread_spin_trylock()

尝试获取自旋锁（非阻塞）

若锁已被占用，直接返回错误码，不自旋等待

pthread_spin_unlock()

释放自旋锁

必须由持有锁的线程调用，否则会导致未定义行为

pthread_spin_destroy()

销毁自旋锁

销毁前需确保所有线程已释放锁，且不再使用该锁

自旋锁的适用场景总结

结合前面的分析，自旋锁并非“万能锁”，其适用场景有严格限制，核心满足两个条件：

①临界区执行时间极短：确保自旋等待的总耗时远小于线程阻塞-唤醒的开销（如简单的变量赋值、状态检查等操作）；

②多核CPU环境：单核CPU下，自旋线程会独占CPU，导致持有锁的线程无法执行，引发“死锁”风险，因此自旋锁仅适用于多核场景。

简单来说，当线程对临界资源的访问“快进快出”时，自旋锁是比互斥锁更高效的选择——就像阿熊知道小美“马上下来”时，原地等待远比去网吧更省时一样。

接口函数	功能说明	关键注意事项
pthread_spin_init()	初始化自旋锁	需指定锁的共享属性（如PTHREAD_PROCESS_PRIVATE表示进程内线程共享）
pthread_spin_lock()	获取自旋锁（自旋等待直到成功）	若锁已被占用，当前线程会持续循环检查，不释放CPU
pthread_spin_trylock()	尝试获取自旋锁（非阻塞）	若锁已被占用，直接返回错误码，不自旋等待
pthread_spin_unlock()	释放自旋锁	必须由持有锁的线程调用，否则会导致未定义行为
pthread_spin_destroy()	销毁自旋锁	销毁前需确保所有线程已释放锁，且不再使用该锁

七、😊读者写者问题

在多线程编程领域，有两个经典的并发控制场景，分别是生产消费者模型和读者写者模型。这两种模型是解决实际并发问题的基础框架，其中读者写者模型以其“读多写少”的典型特征，在众多实际场景中有着广泛应用。

读者写者模型应用场景很多，以下几种仅为举例：在csdn发文章，杂志，出黑板报等等都是读者写者模型。读者写者模型常见情况是——读者众多，写者较少

这些场景的共同特征是：读者数量远多于写者数量，且读操作通常不会改变数据状态，写操作则会修改数据——这也是读者写者模型需要重点解决的核心矛盾。

读者写者模型也符合“321”原则，即：

3种关系：写者与写者，读者与写者，读者与读者。

1️⃣3种核心关系：定义并发协调的关键规则

读者写者模型中的3种关系本质是并发操作的“互斥”与“同步”关系，不同关系的协调规则直接决定了数据的一致性和并发效率：

写者与写者：互斥关系：多个写者同时对同一数据进行写入操作，必然会导致数据混乱。例如，两个编辑同时修改同一篇文章的同一段落，最终的文章内容会出现逻辑冲突；两个HR同时修改同一名员工的薪资信息，可能会导致最终薪资数据错误。因此，任意时刻只能有一个写者执行写操作，写者之间必须严格互斥。

读者与写者：互斥且同步关系：这种关系是模型的核心矛盾。一方面，互斥性是保障数据一致性的基础——若写者正在写入数据（如员工正在撰写未完成的工作报告），此时读者读取数据（接收人查看报告），会获取到不完整、不一致的数据，进而导致后续决策或操作错误。另一方面，同步性是保障业务流程顺畅的关键——写者完成数据写入后（工作报告撰写完成并提交），需要确保读者能够及时读取到最新数据（接收人获取完整报告以了解进度）。因此，读者与写者之间需满足“写时不读、读时不写”的互斥要求，同时通过同步机制确保数据更新后能被有效读取。

读者与读者：无互斥关系：与生产消费者模型中“消费者消耗资源”不同，读者写者模型中的读者仅对数据进行“读取拷贝”，不会修改数据的原始状态。例如，多名用户同时浏览同一篇博客文章，不会对文章内容造成任何影响；多个员工同时查询同一名同事的联系方式，也不会导致联系方式数据变化。因此，多个读者可同时执行读操作，无需互斥，这也是提升模型并发效率的关键设计。

2️⃣2个角色：明确参与主体的行为边界

2个角色：读者，写者。
1个场所：一个读写场所。

模型的参与主体仅有两类，角色定位清晰，行为特征明确：

读者：核心行为是“读取数据”，不修改数据状态，可多个同时执行操作，对共享数据仅产生“只读”影响。

写者：核心行为是“修改数据”，会改变数据的原始状态，同一时刻仅能有一个执行操作，对共享数据产生“写更新”影响。

3️⃣ 1个场所：界定共享资源的范围

模型中存在一个唯一的“读写场所”，即共享数据区域，这是读者和写者的操作对象所在的核心区域。例如，博客平台的文章数据库、黑板报的书写面板、员工信息管理系统的数据库表，均属于“读写场所”。所有读者的读操作和写者的写操作，都围绕这个共享区域展开，因此该区域的并发控制是模型实现的关键。

依照上述的321原则，再根据之前的生产消费者模型我们不难写出伪代码：

①核心实现逻辑

由于读者和写者的行为差异较大，需通过两把锁（读锁、写锁）分别控制，并引入“读者计数器（read_count）”记录当前活跃读者数量，具体逻辑如下：

读者操作流程：
读者申请读锁，进入临界区；

判断是否为“第一个进入的读者”：若是，需申请写锁——因为此时需确保没有写者正在执行写操作（保障读写互斥）；若不是，直接进入读操作（读者间无互斥）；

读者计数器（read_count）加1，标记活跃读者数量；

释放读锁，执行读操作（读取数据拷贝）；

读操作完成后，再次申请读锁，读者计数器（read_count）减1；

判断是否为“最后一个离开的读者”：若是，释放写锁——此时已无读者，可允许写者申请写操作；若不是，直接释放读锁离开；

写者操作流程：
写者申请写锁，若当前有读者或其他写者在操作，进入阻塞状态（保障写写互斥、读写互斥）；

申请成功后，执行写操作（修改数据）；

写操作完成后，释放写锁，允许其他写者或读者申请操作；

②常用核心接口（以POSIX线程库为例）

在实际开发中，无需手动实现复杂的锁协调逻辑，主流的线程库已封装好“读写锁”接口，直接调用即可实现读者写者模型的并发控制。以Linux系统的pthread线程库为例，核心接口如下：
#include <pthread.h>

// 1. 销毁读写锁：释放锁占用的资源，使用前需确保锁已解锁
int pthread_rwlock_destroy(pthread_rwlock_t *rwlock);

// 2. 初始化读写锁：创建读写锁，attr为锁属性（通常传NULL使用默认属性）
int pthread_rwlock_init(pthread_rwlock_t *restrict rwlock, const pthread_rwlockattr_t *restrict attr);

// 3. 读者加锁：读者申请读锁，成功后进入读操作；若有写者占用，阻塞等待
int pthread_rwlock_rdlock(pthread_rwlock_t* rwlock);

// 4. 写者加锁：写者申请写锁，成功后进入写操作；若有读者或其他写者占用，阻塞等待
int pthread_rwlock_wrlock(pthread_rwlock_t* rwlock);

// 5. 解锁：读者或写者操作完成后释放锁，唤醒阻塞的其他线程
int pthread_rwlock_unlock(pthread_rwlock_t* rwlock);

八、🤩读者优先与写者优先策略

在读者写者模型的实现中，除了基础的锁机制协调，还存在“读者优先”和“写者优先”两种核心同步顺序策略，其本质是解决当读者和写者同时竞争共享资源时，谁先获得访问权限的问题，两种策略各有特点及适用场景。

1️⃣ 读者优先策略

读者优先策略的核心规则是：若当前存在活跃读者，新到达的读者可直接获得读锁并进入读操作，无需等待；仅当所有活跃读者都完成读操作后，等待的写者才能获得写锁。这一策略完全契合“读多写少”的典型场景，因为它能最大化读操作的并发效率，减少读者的等待时间。

读者优先的优势在于读操作吞吐量高，能充分利用读者间无互斥的特性提升并发性能。但该策略存在一个关键问题——写者饥饿：若系统中读者持续不断地到达（如热门博客的高频浏览场景），新读者会一直抢占资源，导致等待中的写者始终无法获得写锁，长时间处于阻塞状态，无法完成写操作。

不过在多数实际场景中，写者饥饿问题并不严重。因为“读多写少”的场景下，写者操作本身频率较低（如博客作者不会频繁修改已发布的文章），且读者的访问通常存在间歇性，当读者流出现间隙时，写者即可获得资源完成操作。因此，读者优先是实际开发中更常用的默认策略。

2️⃣写者优先策略

写者优先策略的核心规则是：若当前存在等待的写者，新到达的读者需等待写者完成操作后才能获得读锁；写者到达后，会优先于后续到达的读者获得资源访问权限。这一策略的核心目标是保障写者的及时响应，避免写者饥饿问题。

写者优先的优势在于能确保写者的操作及时性，适用于写操作时效性要求高的场景（如实时数据更新系统，需确保数据修改能快速生效）。但该策略的代价是实现复杂度显著提升，需要额外的机制辅助：

状态标记：需添加“写者等待标记”，用于标识当前是否有写者在等待资源，若标记为真，则新读者需进入等待队列；

等待队列：需维护读者等待队列和写者等待队列，当写者完成操作后，需按照优先规则唤醒队列中的线程（如先唤醒后续等待的写者，或在无写者等待时唤醒所有等待读者）；

更精细的锁控制：除了基础的读写锁，可能还需要引入互斥锁来保护等待队列和状态标记的修改，避免出现队列操作混乱。

此外，写者优先会降低读操作的并发效率，因为即使当前无活跃读者，若有写者在等待，新读者也需排队，导致读操作的等待时间增加。

3️⃣策略选择建议

两种策略的选择需结合业务场景的核心需求：

若场景以读操作为主、写操作频率低，且对读操作效率要求高（如博客浏览、商品信息查询），优先选择读者优先；

若场景对写操作时效性要求高，需避免写者饥饿（如实时监控数据更新、交易记录修改），则选择写者优先，同时接受其实现复杂度提升和读效率下降的代价。

🗝️总结与提炼

本文精简梳理线程安全核心知识：死锁、C++组件安全性、锁机制、设计模式及经典并发问题的核心要点。

一、死锁：并发中的“僵局”核心

死锁：多线程相互持有对方所需资源且不释放，导致永久阻塞，核心是资源竞争的循环依赖，为并发基础风险。

二、死锁的解决思路：破局关键策略

死锁解决四维度：预防（破坏必要条件如按序分配）、避免（银行家算法）、检测（监控资源状态）、解除（强制释放资源），实践中预防与避免更常用。

三、C++核心组件线程安全：分场景判断

3.1 STL容器：默认无线程安全保障

STL容器：默认无线程安全，并发读写易致迭代器失效、数据破坏；需外部加锁（全局锁/分段锁）或线程局部存储保障安全。

3.2 智能指针：类型决定安全性边界

智能指针：安全性分类型——shared_ptr/weak_ptr保障引用计数原子性，但不保证指向对象安全；unique_ptr因独占所有权无需线程安全设计。核心：仅保障自身元数据安全，指向对象需额外控制。

3.3 核心结论

C++组件核心结论：STL需外部加锁，智能指针仅部分安全，需明确线程安全边界。

四、常见锁机制：并发控制的基础工具

常见锁机制：互斥锁、读写锁、递归锁、条件变量等，核心适配依据：并发强度、读写比例、锁持有时间。

五、单例模式线程安全：懒汉模式的关键优化

5.1 单例模式核心定义

单例模式：保证类仅一个实例并提供全局访问点，用于管理全局资源；懒汉模式（延迟初始化）的核心挑战是线程安全。

5.2 原生懒汉模式隐患

原生懒汉模式隐患：“判断实例存在”与“创建实例”非原子性，多线程易重复创建实例，破坏唯一性。

5.3 线程安全懒汉模式：双重检查锁定（DCL）

双重检查锁定（DCL）核心：两次判断实例+加锁——首次无锁判断避开销，加锁后二次判断防重复创建，保证唯一实例。

DCL关键：平衡安全与性能；C++11前需volatile防半初始化，C++11后可省略但需保证初始化原子性。

额外注意：需保障析构安全；C++11后局部静态变量初始化线程安全，可简化懒汉模式实现。

5.4 核心结论

单例结论：核心是初始化并发控制，DCL为经典方案；C++11后优先选局部静态变量方案。

六、自旋锁：轻量级等待的适用场景

自旋锁vs互斥锁：互斥锁放弃CPU等待唤醒（上下文切换开销大），自旋锁原地循环检测（无切换但CPU占用高）。

自旋锁适用场景：锁持有时间极短+CPU核心充足（如内核小粒度操作）；否则CPU空耗，性能不及互斥锁。Linux pthread提供标准接口（pthread_spin_init等）。

七、读者写者问题：读写并发的协调模型

读者写者问题核心“3-2-1”：3种关系（读-读并发、读-写互斥、写-写互斥）、2角色（读者/写者）、1资源（共享资源）。

实现核心：读写锁（POSIX pthread_rwlock系列接口）——读者加读锁（并发持有），写者加写锁（独占持有）。

八、读写策略选择：读者优先与写者优先的权衡

读者优先：新读者可插队，读效率高但写者易饥饿；适配读多写少、写可延迟场景（如日志查询）。

写者优先：写者申请时阻塞新读者，防写饥饿但读效率低；适配写优先级高、频繁场景（如实时更新）。

策略选择：依读写比例+业务优先级，极端场景选公平策略平衡。

整体核心脉络总结

核心脉络：线程安全核心是控制共享资源并发访问，围绕“风险识别（死锁）-工具选择（锁机制）-模式优化（单例等）”展开，最终平衡安全与性能。