1. 项目概述：为什么我们需要深入理解C++中的锁？

如果你写过一段时间的C++多线程程序，大概率已经和锁打过交道了。可能是在一个共享的std::vector上加了把std::mutex，也可能是为了解决生产者-消费者问题而使用了条件变量。刚开始时，锁看起来很简单：不就是lock()和unlock()吗？但当你写的程序并发量上来，或者线程间交互变得复杂时，各种诡异的问题就冒出来了：程序偶尔会卡死、性能莫名其妙地下降、数据竞争导致结果时对时错。这时候你才会意识到，锁远不止“上锁解锁”那么简单，它是一门需要深入理解的学问。

C++标准库从C++11开始，为我们提供了一套相对完整的线程支持库，其中锁相关的设施是核心。但标准库提供的更多是“积木”，如何用这些积木搭建出既稳固又高效的多线程程序，需要我们对锁的类型、特性、使用场景和陷阱有深刻的认识。这篇文章不会停留在简单的API介绍上，而是会从一个有实际多线程开发经验的工程师视角，拆解C++中各种锁的原理、适用场景，并分享那些在文档里找不到，但在实际项目中用血泪换来的经验和避坑指南。无论你是正在学习多线程的新手，还是已经踩过一些坑、希望系统梳理锁机制的老手，这篇文章都能提供直接的参考价值。

2. 锁的核心类型与适用场景解析

C++标准库中的锁，主要可以分为几大类：互斥锁、读写锁、递归锁，以及用于锁管理的RAII包装器。选择哪种锁，往往取决于你的数据访问模式。

2.1 互斥锁：最基础的守卫者

std::mutex是最基础的互斥锁。它的行为很直观：一次只允许一个线程持有锁。当一个线程调用lock()时，如果锁未被占用，则获得锁；如果已被占用，则线程被阻塞，直到锁被释放。

为什么需要它？这是为了解决最基本的“数据竞争”问题。当多个线程同时读写同一块非原子内存区域时，程序行为是未定义的。std::mutex通过强制串行化访问，确保了临界区内代码的独占执行。

一个典型的坑：忘记解锁。这是新手最容易犯的错误。如果临界区内代码抛出异常，或者你简单地return了，锁就可能永远无法释放，导致其他所有等待该锁的线程永久阻塞，也就是死锁的一种常见形式。

std::mutex mtx; std::vector<int> shared_data; void problematic_push(int val) { mtx.lock(); shared_data.push_back(val); if (val == 0) { return; // 糟糕！如果val为0，这里直接返回，锁没有释放！ } mtx.unlock(); // 只有val不为0时才会执行到这里 }

注意：永远不要直接调用lock()和unlock()。这正是std::lock_guard和std::unique_lock这些RAII包装器存在的意义。

2.2 RAII包装器：让锁管理变得安全

RAII（资源获取即初始化）是C++管理资源的核心理念，锁作为一种资源，自然也不例外。

std::lock_guard：轻量级的自动守卫。它在构造时获取锁，在析构时自动释放锁。代码简洁，开销小，是大多数情况下的首选。

void safe_push(int val) { std::lock_guard<std::mutex> guard(mtx); // 构造时上锁 shared_data.push_back(val); // guard析构时自动解锁，即使push_back抛出异常也没问题 }

std::unique_lock：功能更丰富的管理者。它提供了比lock_guard更多的灵活性：

• 延迟上锁：构造时不立即上锁，可以稍后调用lock()。
• 手动解锁：可以在锁的生命周期结束前，主动调用unlock()释放锁，这在需要精细控制锁的持有时间时很有用。
• 所有权转移：unique_lock对象本身可以移动，但不能复制，这符合其“独占所有权”的语义。
• 与条件变量配合：std::condition_variable的wait函数必须接收一个std::unique_lock<std::mutex>作为参数，这是因为它需要在等待时释放锁，并在被唤醒时重新获取锁。

std::mutex mtx; std::condition_variable cv; bool data_ready = false; void producer() { std::this_thread::sleep_for(std::chrono::seconds(1)); { std::lock_guard<std::mutex> lk(mtx); data_ready = true; } cv.notify_one(); // 通知前最好先释放锁，减少消费者被唤醒后的竞争 } void consumer() { std::unique_lock<std::mutex> lk(mtx); // wait会原子地释放lk并阻塞线程，被唤醒后重新获取lk cv.wait(lk, []{ return data_ready; }); // 此时lk已被重新锁定，可以安全访问共享数据 std::cout << "Data is ready!\n"; }

选择建议：默认使用std::lock_guard。只有当需要延迟上锁、手动解锁、转移所有权或与条件变量配合时，才使用std::unique_lock。

2.3 读写锁：提升读多写少场景的性能

互斥锁不区分读写操作。但在很多场景下，数据的读取操作远多于写入操作，且读取操作本身不会修改数据，理论上可以并发进行。std::shared_mutex（C++17）就是为解决这个问题而生的。

• 共享锁（读锁）：通过lock_shared()或shared_lock获取。多个线程可以同时持有共享锁，用于并发读取。
• 独占锁（写锁）：通过lock()或unique_lock获取。与互斥锁行为一致，一次只能有一个线程持有，用于写入或修改数据。

性能考量：读写锁的内部实现比互斥锁更复杂，因此其本身的开销也更大。只有在读操作非常频繁，且临界区代码执行时间不是特别短的情况下，使用读写锁带来的并发读收益才能覆盖其额外的开销。如果临界区只是做一两个简单的赋值操作，那么使用互斥锁可能反而更快。

一个实际场景：一个内存中的配置信息缓存。配置可能每小时才更新一次（写），但每秒钟有成千上万的请求来读取配置。使用std::shared_mutex可以极大地提升读取的吞吐量。

class ConfigCache { private: std::unordered_map<std::string, std::string> cache_; mutable std::shared_mutex rw_mutex_; // mutable允许const成员函数上读锁 public: std::string get(const std::string& key) const { std::shared_lock<std::shared_mutex> lock(rw_mutex_); // 读锁 auto it = cache_.find(key); return it != cache_.end() ? it->second : ""; } void set(const std::string& key, const std::string& value) { std::unique_lock<std::shared_mutex> lock(rw_mutex_); // 写锁 cache_[key] = value; } };

2.4 递归锁：允许同一线程重复上锁

std::recursive_mutex允许同一个线程多次获取同一个锁，而不会导致死锁。内部维护一个锁计数，每次lock()计数加一，每次unlock()计数减一，只有当计数减到0时，锁才真正被释放。

什么时候用？通常来说，需要递归锁的设计可能暗示着代码结构有待优化。一个典型的使用场景是：一个公有成员函数需要加锁，而这个函数内部又调用了一个需要加锁的私有辅助函数，且两者操作的是同一个互斥量。

class RecursiveExample { std::recursive_mutex mtx_; int data_ = 0; void internal_update(int delta) { std::lock_guard<std::recursive_mutex> lock(mtx_); data_ += delta; } public: void update(int a, int b) { std::lock_guard<std::recursive_mutex> lock(mtx_); data_ += a; internal_update(b); // 这里会再次尝试获取mtx_，如果是std::mutex则会死锁 } };

重要警告：递归锁容易掩盖设计问题，并且使用它需要格外小心。你必须确保lock和unlock的次数严格匹配。如果在一个递归调用链中，你用了lock_guard，那没问题，RAII会帮你管理。但如果你混用了手动lock()和unlock()，就极易出错。我的建议是：尽量避免使用递归锁，重新审视你的类设计，看能否通过将公共锁区域提取出来、或使用可重入函数等方式来规避。

3. 高级锁策略与死锁预防实战

掌握了基本锁类型，只是多线程编程的第一步。真正的挑战在于如何组织这些锁，让它们协同工作而不至于陷入僵局——也就是死锁。

3.1 死锁的经典条件与场景再现

死锁通常需要四个条件同时满足：互斥、持有并等待、不可剥夺、循环等待。在实际编码中，最常见的是由“持有并等待”和“循环等待”引发的。

场景一：锁顺序不一致。这是死锁的“头号杀手”。

// 线程A std::lock_guard<std::mutex> lock1(mutex_a); std::this_thread::sleep_for(10ms); // 模拟一些操作，增加了死锁触发的概率 std::lock_guard<std::mutex> lock2(mutex_b); // 线程B std::lock_guard<std::mutex> lock2(mutex_b); // 先锁b！ std::this_thread::sleep_for(10ms); std::lock_guard<std::mutex> lock1(mutex_a); // 再锁a！

线程A持有mutex_a等待mutex_b，线程B持有mutex_b等待mutex_a，循环等待形成，死锁发生。sleep不是死锁的原因，但它放大了竞态窗口，让问题更容易稳定复现。

3.2 死锁预防的核心策略

策略一：固定锁顺序。这是最有效、最常用的方法。为程序中所有的互斥量定义一个全局的获取顺序（例如，按内存地址排序），任何线程在任何时候都必须按照这个顺序来申请锁。

void fixed_order_transfer(Mutex& m1, Mutex& m2) { // 确保总是先锁地址小的那个互斥量 auto& first = std::min(&m1, &m2, std::less<Mutex*>()); auto& second = (&m1 == first) ? &m2 : &m1; std::lock_guard<Mutex> lock_first(*first); std::lock_guard<Mutex> lock_second(*second); // ... 操作共享资源 }

在实际项目中，你可能无法直接比较mutex的地址，但可以为它们关联一个唯一的ID或层级，并强制按此顺序加锁。

策略二：使用std::lock进行锁聚合。C++标准库提供了std::lock函数，它可以一次性锁定两个或更多的互斥量，并且保证不会因为顺序问题导致死锁。它通常与std::lock_guard或std::unique_lock的延迟锁定特性配合使用。

void safe_transaction(std::mutex& mtx_a, std::mutex& mtx_b) { // 同时锁定mtx_a和mtx_b，避免死锁 std::unique_lock<std::mutex> lock_a(mtx_a, std::defer_lock); std::unique_lock<std::mutex> lock_b(mtx_b, std::defer_lock); std::lock(lock_a, lock_b); // 关键的一步：原子地锁定两个锁 // 现在lock_a和lock_b都已锁定，可以安全地操作受它们保护的资源了 // ... // 函数结束时，unique_lock会按相反顺序自动释放锁 }

std::lock内部使用了一种避免死锁的算法（如std::try_lock的循环重试），它确保了无论以何种参数顺序调用，都能安全地获取所有锁。这是处理需要同时获取多个锁的情况时的首选方案。

策略三：使用层次锁。这是一种将锁顺序设计融入到类型系统中的方法。你为每一类锁分配一个层级编号，规定只能持有高层级锁的线程去获取低层级的锁，而不能反向操作。这可以通过一个线程局部变量来跟踪当前线程所持有的最高层级锁来实现。虽然标准库没有直接提供，但我们可以自己实现其思想。

class hierarchical_mutex { std::mutex internal_mtx; unsigned long const hierarchy_value; unsigned long previous_hierarchy; static thread_local unsigned long this_thread_hierarchy; // 线程局部存储 void check_for_hierarchy_violation() { if (this_thread_hierarchy <= hierarchy_value) { throw std::logic_error("mutex hierarchy violated"); } } void update_hierarchy() { previous_hierarchy = this_thread_hierarchy; this_thread_hierarchy = hierarchy_value; } public: explicit hierarchical_mutex(unsigned long value): hierarchy_value(value), previous_hierarchy(0) {} void lock() { check_for_hierarchy_violation(); internal_mtx.lock(); update_hierarchy(); } void unlock() { this_thread_hierarchy = previous_hierarchy; internal_mutex.unlock(); } // ... 其他成员函数 };

使用层次锁可以在运行时或测试阶段提前发现锁顺序违规，将死锁风险扼杀在编码阶段。

策略四：避免嵌套锁。尽可能减少持有一个锁的同时去获取另一个锁的情况。如果逻辑必须如此，则务必使用上述方法（固定顺序或std::lock）进行严格管理。审视你的设计，看能否通过缩小临界区、重新组织数据或使用回调等方式来减少锁的嵌套。

3.3 尝试锁与超时控制：增加系统弹性

有时候，我们不想让线程无限期地阻塞等待一个锁。std::mutex提供了try_lock()方法，std::unique_lock则可以配合std::adopt_lock、std::try_to_lock和std::defer_lock标签使用。C++11还引入了std::timed_mutex和std::recursive_timed_mutex，它们提供了带超时的try_lock_for和try_lock_until方法。

使用场景：

1. 避免长时间阻塞：比如一个UI线程，不能因为等待一个后台任务的锁而卡住界面。
2. 死锁恢复：在可能发生死锁的代码路径中，使用尝试锁，如果一段时间内获取不到所有需要的锁，就释放已持有的锁，回退操作，并可能进行重试或报告错误。
3. 测试锁的可用性：在某些特定逻辑中，需要判断资源是否正被占用。

std::timed_mutex mtx; void maybe_do_work() { std::unique_lock<std::timed_mutex> lock(mtx, std::chrono::milliseconds(50)); // 尝试获取锁，最多等50ms if (lock.owns_lock()) { // 成功获取锁，执行工作 do_critical_work(); } else { // 超时未获取锁，执行替代方案 fallback_operation(); // 或者可以选择记录日志、重试等 } }

实操心得：不要滥用尝试锁。将其作为死锁预防或系统弹性设计的一部分是好的，但如果只是为了“不让线程阻塞”而到处使用try_lock，往往会导致逻辑复杂化，并且可能引发活锁（多个线程不断尝试-失败-重试）或饥饿问题。在大多数需要互斥的场景下，阻塞式的lock()才是最简单正确的选择。

4. 锁的性能考量与无锁编程的边界

锁是保证正确性的利器，但也是性能的潜在瓶颈。不当的锁使用会导致严重的性能下降。

4.1 锁带来的性能开销来源

1. 直接开销：调用锁API本身有开销，包括用户态到内核态的切换（对于需要操作系统介入的锁）、原子操作等。
2. 间接开销（缓存失效）：这是更隐蔽、影响更大的开销。当一个持有锁的线程在临界区内修改了共享数据，这些数据所在的缓存行（Cache Line）会变成“脏”的。当该线程释放锁，另一个线程获取锁并访问同一数据时，它必须从主内存或另一个CPU核心的缓存中加载这个已经变脏的缓存行，这个过程比从本地缓存读取慢得多。如果多个线程频繁争抢同一个锁（高争用），缓存行会在不同CPU核心间“乒乓”跳动，导致性能急剧下降。
3. 串行化开销：锁将并行操作强制串行化，降低了系统的吞吐量。临界区越长，串行化开销越大。

4.2 降低锁竞争的最佳实践

原则一：尽可能缩短临界区。只将真正需要互斥访问的代码放在锁的保护范围内。任何不需要共享的数据计算、文件I/O（除非是共享文件）、耗时的外部服务调用等，都应该移到锁的外面。

// 不好的做法：整个函数都在锁内 void process_data_slow(const Data& d) { std::lock_guard<std::mutex> lock(mtx); auto result = expensive_computation(d); // 耗时的计算！ shared_queue.push(result); } // 好的做法：只保护共享数据访问 void process_data_fast(const Data& d) { auto result = expensive_computation(d); // 在锁外计算 { std::lock_guard<std::mutex> lock(mtx); // 临界区非常短 shared_queue.push(result); } }

原则二：减小锁的粒度。不要用一个“万能大锁”保护所有数据。根据数据之间的独立性，使用多个锁来保护不同的数据集合。这样，操作不同数据的线程就可以真正并行。

// 粗粒度锁 class MonolithicBuffer { std::vector<int> data_a; std::vector<double> data_b; std::mutex global_mtx; // 一个锁保护所有 // ... 操作data_a和data_b的函数都需要锁global_mtx }; // 细粒度锁 class FineGrainedBuffer { std::vector<int> data_a; std::vector<double> data_b; std::mutex mtx_a; // 只为data_a加锁 std::mutex mtx_b; // 只为data_b加锁 void add_to_a(int val) { std::lock_guard<std::mutex> lock(mtx_a); data_a.push_back(val); } void add_to_b(double val) { std::lock_guard<std::mutex> lock(mtx_b); data_b.push_back(val); } // 同时操作a和b时才需要锁两个，此时需用std::lock防死锁 };

原则三：使用读写锁替代互斥锁。如前所述，在读多写少的场景下，std::shared_mutex可以显著提升并发读性能。

原则四：考虑无锁数据结构。对于极度高性能要求的场景，可以考虑使用无锁（Lock-Free）队列、栈、哈希表等。C++11的原子操作（std::atomic）为编写无锁代码提供了基础。但请注意，无锁编程极其复杂，容易出错，且并非在所有情况下都比有锁方案快。它通常只在锁争用成为绝对性能瓶颈时才值得考虑。

4.3 锁与原子操作的选择边界

std::atomic提供了一种无需锁就能进行线程安全操作的基础类型（如atomic<int>）。对于单个标量数据的简单操作（读、写、递增、交换等），原子操作通常是性能最优的选择。

std::atomic<int> counter{0}; void increment() { counter.fetch_add(1, std::memory_order_relaxed); // 原子递增，比用锁快得多 }

何时用锁，何时用原子？

• 用原子：当你的共享状态可以浓缩为一个简单的标量（整型、指针等），且操作是单一的读、写、或已知的原子RMW（读-改-写，如fetch_add）操作时。
• 用锁：当需要保护一个复杂的数据结构（如链表、树、容器），或者需要执行一个涉及多个变量的、不可分割的复合操作时。锁可以让你轻松地定义一个“事务”边界。

一个关键陷阱：原子操作解决的是单个数据的原子性，但很多时候我们需要的是多个操作合在一起的原子性（一致性）。例如，从一个账户向另一个账户转账，需要原子地减少A账户余额并增加B账户余额。两个独立的atomic操作无法保证这个组合的原子性，中间状态可能被其他线程观察到。这时就必须使用锁。

5. 条件变量：让线程学会等待与通知

锁解决了互斥访问的问题，但线程间协作还需要另一种机制：等待某个条件成立。这就是std::condition_variable的用武之地。它允许一个线程阻塞，直到被另一个线程通知，并且通常与一个布尔条件（谓词）和互斥锁一起使用。

5.1 条件变量的基本使用模式

条件变量的使用有一个固定的“套路”，不遵循这个套路很容易出错。

std::mutex mtx; std::condition_variable cv; std::queue<Data> data_queue; bool finished = false; // 条件谓词 // 生产者线程 void producer() { for (int i = 0; i < 10; ++i) { Data data = produce_data(); { std::lock_guard<std::mutex> lock(mtx); data_queue.push(std::move(data)); } // 注意：通知前释放锁！ cv.notify_one(); // 通知一个等待的消费者 } { std::lock_guard<std::mutex> lock(mtx); finished = true; } cv.notify_all(); // 通知所有消费者结束 } // 消费者线程 void consumer() { while (true) { std::unique_lock<std::mutex> lock(mtx); // 使用带谓词的wait，防止虚假唤醒 cv.wait(lock, []{ return !data_queue.empty() || finished; }); if (finished && data_queue.empty()) { break; // 生产结束且队列为空，退出循环 } // 条件满足，处理数据 Data data = std::move(data_queue.front()); data_queue.pop(); lock.unlock(); // 尽早释放锁，让其他消费者可以运行 process_data(data); } }

5.2 条件变量的核心要点与陷阱

1. 为什么必须用std::unique_lock？condition_variable::wait的内部实现需要先释放锁（让其他线程能修改条件），然后将线程加入等待队列并阻塞。当被notify唤醒时，它会在返回前重新获取锁。这个“释放-等待-重新获取”的过程需要锁对象支持手动解锁和重新上锁，std::lock_guard没有这个能力，所以只能用std::unique_lock。

2. 虚假唤醒。即使没有线程调用notify，等待的线程也可能被操作系统唤醒。因此，永远不要假设被唤醒就意味着条件已经满足。必须将条件检查放在一个循环中，或者直接使用wait的重载版本，它接受一个谓词（如上面的例子cv.wait(lock, predicate)）。这个版本等价于：

while (!predicate()) { cv.wait(lock); }

它能完美处理虚假唤醒。

3. 通知前释放锁。在上面的生产者代码中，我在调用cv.notify_one()之前，先通过作用域{}释放了锁。这是一个重要的优化。如果在持有锁的情况下通知，被唤醒的消费者线程会立即尝试获取锁，但发现锁还被生产者持有，于是它又会被阻塞（这次是阻塞在获取锁上），导致一次不必要的上下文切换。先释放锁再通知，可以让被唤醒的线程有更大机会立即获得锁并执行，提升性能。

4. 丢失唤醒。如果消费者线程在调用wait之前，生产者就已经调用了notify，那么这个通知可能会被“丢失”，消费者将永远等待下去。使用带谓词的wait可以避免这个问题，因为即使通知先发生，消费者检查谓词发现条件不满足，也不会进入等待。但更根本的保证是，确保“修改条件”和“发送通知”在同一个锁的保护下进行，这样它们的顺序对其他线程就是原子的。在上面的例子中，生产者修改data_queue和finished、消费者检查这些条件，都在mtx的保护下，这就保证了正确的同步顺序。

6. 实战中的锁：设计模式与典型问题排查

理论最终要服务于实践。在实际项目中，锁的使用往往被封装在更高的抽象层次中。

6.1 线程安全的数据结构封装

设计一个线程安全的类，通常有两种思路：

1. 基于锁的封装：在类的每个公有成员函数内部加锁。这是最直接的方法，但可能粒度较粗，且要注意返回引用或迭代器时可能破坏封装（调用者可能在外界持有这些引用时进行非线程安全操作）。
2. 基于并发数据结构：提供专门的线程安全接口，而不是简单包装所有方法。例如，一个线程安全队列通常只提供push、try_pop、wait_and_pop这样的接口，而不是暴露底层的std::deque的所有功能。

template<typename T> class threadsafe_queue { private: mutable std::mutex mtx; std::queue<T> data_queue; std::condition_variable cv; public: void push(T new_value) { std::lock_guard<std::mutex> lock(mtx); data_queue.push(std::move(new_value)); cv.notify_one(); } bool try_pop(T& value) { std::lock_guard<std::mutex> lock(mtx); if (data_queue.empty()) return false; value = std::move(data_queue.front()); data_queue.pop(); return true; } std::shared_ptr<T> wait_and_pop() { std::unique_lock<std::mutex> lock(mtx); cv.wait(lock, [this]{ return !data_queue.empty(); }); std::shared_ptr<T> res(std::make_shared<T>(std::move(data_queue.front()))); data_queue.pop(); return res; } // ... 其他方法，如empty(), size()等，也需要加锁 };

6.2 锁的典型问题与调试技巧

即使遵循了所有最佳实践，多线程程序依然可能出问题。以下是一些常见症状和排查思路：

症状：程序偶尔卡死，CPU占用率低。

• 可能原因：死锁。
• 排查方法：
  1. 检查所有锁的获取顺序是否一致。
  2. 检查是否存在嵌套锁，并确认嵌套锁使用了std::lock或固定顺序。
  3. 在调试器中暂停程序（例如gdb的thread apply all bt），查看所有线程的调用栈。死锁的线程通常会阻塞在lock()或wait()调用上。分析这些线程各自持有了哪些锁，又在等待哪些锁，很容易找出循环等待链。
  4. 使用工具，如valgrind --tool=helgrind或clang的ThreadSanitizer，它们可以在运行时检测数据竞争和死锁。

症状：程序性能随线程数增加不升反降，甚至比单线程还慢。

• 可能原因：锁竞争过于激烈。
• 排查方法：
  1. 使用性能剖析工具（如perf，VTune）查看热点，是否大量时间花费在锁相关的函数（如pthread_mutex_lock）内部。
  2. 检查临界区是否过长，能否将非共享操作移出去。
  3. 检查锁的粒度是否过粗，能否拆分成更细粒度的锁。
  4. 考虑是否能用读写锁（std::shared_mutex）替代互斥锁。
  5. 对于简单的计数器，考虑用std::atomic替代锁。

症状：程序运行结果不确定，有时正确有时错误。

• 可能原因：数据竞争。某个共享变量在没有被正确同步的情况下被多个线程访问。
• 排查方法：
  1. 这是最棘手的问题，因为可能不会立即崩溃。仔细审查所有共享数据，确保每一次读或写都在某种锁（或原子操作）的保护之下。
  2. 使用ThreadSanitizer是检测数据竞争最强大的武器。它在编译时插桩，能在运行时精准定位发生竞争的代码行。
  3. 对于非原子类型的布尔标志或状态变量，即使只是读取，也必须在锁的保护下进行，或者将其改为std::atomic类型。因为对于非原子类型的并发读写，C++标准定义为未定义行为，编译器可能进行意想不到的优化。

症状：条件变量等待的线程没有被唤醒，或唤醒后条件不成立。

• 可能原因：虚假唤醒处理不当，或丢失唤醒。
• 排查方法：
  1. 确认wait调用使用了带谓词的版本（cv.wait(lock, predicate)）。
  2. 确认“修改条件变量”和“发送通知”在同一个互斥锁的保护范围内，或者至少确保修改对等待线程是可见的（这通常意味着需要某种内存屏障，而锁的获取和释放本身就提供了这种屏障）。
  3. 检查通知用的是notify_one还是notify_all。如果多个线程在等待同一个条件，而条件可能被多个线程修改，使用notify_one可能只唤醒一个线程，而该线程消费掉条件后，其他线程可能永远无法被唤醒。这时需要考虑使用notify_all。

多线程调试是困难的，因为它具有不确定性。增加日志输出（注意日志输出本身也可能需要同步）、在关键点插入断言、以及系统地使用线程检查工具，是提高多线程代码质量的必备手段。记住，在编写多线程代码时，预防远比调试重要。从一开始就遵循严格的锁纪律和设计模式，能省去后期大量的调试时间。