一、并发真正难的不是写，而是“不出错”

前面你已经掌握：

thread / mutex / unique_lock / cv / atomic / 线程池

👉 但现实是：

并发 bug 很隐蔽 ❗

👉 常见问题：

✔ 死锁
✔ 数据错乱
✔ 性能下降
✔ 卡死 / 偶现 bug

👉 所以这一篇解决：

如何写“正确的并发代码”

二、死锁（最危险）

经典死锁

std::mutex m1, m2;

void t1() {
std::lock_guard<std::mutex> l1(m1);
std::lock_guard<std::mutex> l2(m2);
}

void t2() {
std::lock_guard<std::mutex> l1(m2);
std::lock_guard<std::mutex> l2(m1);
}

👉 可能发生：

t1 拿 m1 等 m2
t2 拿 m2 等 m1

→ 永远卡住 ❗

✅ 解决方案

✔ 固定加锁顺序（最重要🔥）
✔ 使用 std::lock（避免死锁）

👉 推荐：std::lock(m1, m2);

意思是：同时锁住多个 mutex，并且保证不会发生死锁

三、锁范围过大（性能杀手）

错误

std::lock_guard<std::mutex> lock(m);

do_heavy_work(); // ❌ 不需要锁

👉 问题：

锁时间过长 → 其他线程阻塞 ❗

✅ 正确

{
std::lock_guard<std::mutex> lock(m);
update_shared_data();
}

do_heavy_work(); // ✔ 无锁执行

👉 原则：

锁只保护“共享数据”，不要包业务逻辑🔥

四、忘记加锁（数据竞争）

错误

int a = 0;

void func() {
a++; // ❌ 不安全
}

👉 结果：数据错乱（不可预测）

✅ 解决

✔ mutex（通用）
✔ atomic（简单变量）

五、cv 使用错误（高频坑）

错误1：不用条件

cv.wait(lock); // ❌

👉 问题： 虚假唤醒 → 程序异常

✅ 正确

cv.wait(lock, [] { return ready; });

错误2：先 notify 后改条件

cv.notify_one();
ready = true; // ❌

👉 结果：线程被唤醒 → 条件不满足 → 又睡回去 ❗

✅ 正确顺序

ready = true;
cv.notify_one();

六、锁嵌套过多（设计问题）

lock(m1)
lock(m2)
lock(m3)

👉 问题： 复杂度爆炸 + 容易死锁

👉 原则：

✔ 降低锁层级
✔ 尽量单锁模型

七、atomic 误用（容易被忽略）

错误

std::atomic<int> a;

if (a > 0) {
a--; // ❌ 非原子逻辑
}

👉 问题：多个操作不是原子

正确

使用 CAS（compare_exchange）

八、线程忘记 join（直接崩）

错误

std::thread t(func);
// 没 join ❌

👉 结果：程序 terminate ❗

✅ 正确

t.join();

九、Java 对比（帮助理解）

问题	C++	Java
死锁	mutex	synchronized
等待	cv.wait	wait
通知	notify_one	notify
原子	atomic	AtomicXXX

👉 本质：问题是一样的，语言不同

十、工程纪律（最重要）

并发代码原则：

1️⃣ 一定用 RAII（不要手动 lock/unlock）
2️⃣ 锁范围最小化
3️⃣ 固定加锁顺序（防死锁）
4️⃣ cv 必须带条件
5️⃣ 简单变量优先 atomic
6️⃣ 线程必须 join

十一、笔记版（手写🔥）

并发排障：

死锁：
✔ 固定加锁顺序

性能：
✔ 锁范围要小

cv：
✔ 必须带条件
✔ 先改条件再 notify

atomic：
✔ 只用于简单变量

线程：
✔ 必须 join

原则：
安全 > 性能

十二、你现在的层级（实话🔥）

你已经完成：

thread → 执行
mutex → 安全
cv → 协作
atomic → 优化
线程池 → 工程
排障 → 正确性🔥

👉 这意味着：

你已经具备完整并发工程能力🔥

总结

并发的本质不是多线程，而是如何在多个执行流中保证数据正确 + 执行有序