std::mutex析构时仍有线程在wait/lock会导致崩溃，因底层pthread_mutex_t被回收后仍被访问，引发SIGSEGV或未定义行为；常见于栈上mutex被lambda捕获、类对象析构前未join线程、shared_ptr管理不善、误移动mutex、条件变量与mutex生命周期不匹配等情况。
std::mutex 被析构时仍有线程在 wait/lock 导致的崩溃
这是最典型的“锁被修改导致崩溃”场景：不是你主动改锁对象，而是锁对象（如 std::mutex）生命周期结束（比如局部变量出作用域、unique_ptr 释放、类成员被销毁），但还有线程正阻塞在 lock() 或条件变量的 wait() 上。此时底层 pthread_mutex_t 可能已被回收或复用，触发 SIGSEGV 或 undefined behavior。
常见于以下情况：
- 把
std::mutex声明为栈变量，却在线程中通过 lambda 捕获并长期使用 - 类中持有
std::mutex成员，但对象被析构前未确保所有工作线程已 join 或退出 - 用
std::shared_ptr管理含 mutex 的对象，但多个线程对 shared_ptr 的引用计数操作本身未同步（虽 rare，但若手动调reset()且无保护，也可能提前析构）
std::mutex 对象被 move 或赋值后继续使用
std::mutex 是不可复制、不可移动的类型（deleted copy/move ctor & assign）。但如果你误写了类似 m = std::move(other_mutex)，编译器会报错；更隐蔽的是——你把 mutex 放进容器（如 std::vector<:mutex></:mutex>），试图 push_back 或 resize，这会触发拷贝或移动，直接编译失败。但若你绕过编译检查（比如用指针或 void* 强转），运行时访问已失效的 mutex 内存，就会崩溃。
真正容易踩的坑是：用 std::unique_lock 或 std::shared_lock 时，误以为 lock 对象可转移，而把锁状态和 mutex 对象解耦了。记住：std::unique_lock 可以 move，但被它管理的 std::mutex 本身不能动。
立即学习“C++免费学习笔记（深入）”；
- ✅ 正确：
std::unique_lock<:mutex> lk(m); auto lk2 = std::move(lk);</:mutex>—— 锁权转移，m仍完好 - ❌ 危险：
std::mutex m; auto p = &m; m.~mutex(); new(p) std::mutex;—— 手动析构+重建，其他线程仍在用原地址，必崩
条件变量 wait() 期间 mutex 被意外销毁
调用 cv.wait(lock, pred) 时，wait 内部会先原子地释放 lock，再挂起线程；唤醒后重新获取锁。但整个过程假设 lock.mutex() 指向的 std::mutex 对象在整个 wait 期间都有效。如果另一个线程在此期间 delete 了该 mutex 所在对象，或让其离开作用域，那么唤醒后尝试 re-lock 就会访问野指针。
典型错误模式：
- 条件变量和 mutex 分属不同生命周期的对象（例如 mutex 在栈上，cv 在堆上，且 cv 的 wait 跨函数返回）
- 用
std::condition_variable配合std::shared_mutex时，误将shared_lock传给wait()（标准不支持，行为未定义） - 在
wait的 predicate 中抛异常，且异常处理路径里间接导致 mutex 所在对象被销毁
验证方法：加 ASan + TSan，开启 -D_GLIBCXX_DEBUG（GCC libstdc++ 调试模式）可捕获部分非法 mutex 使用。
调试这类崩溃的关键线索
崩溃点往往不在你写锁操作的地方，而在系统调用入口，比如 pthread_mutex_lock、__lll_lock_wait 或 libc 的 futex 系统调用内部。GDB 中看到 backtrace 停在 __pthread_mutex_lock 或 segfault 地址接近 0x0 / 0x8 / 0x10，基本可锁定是 mutex 对象已销毁。
- 用
gdb -ex 'set follow-fork-mode child' ./a.out捕获子线程崩溃 - 在 mutex 构造/析构处下断点：
break std::mutex::mutex和break std::mutex::~mutex - 检查崩溃线程栈帧里是否包含
wait、lock、unlock，再逆向追踪该 mutex 的生存期
最稳妥的做法，是让 mutex 的生命周期严格长于所有可能访问它的线程 —— 通常意味着它应该是全局、静态、或由主线程 long-lived 对象持有，并在线程 join 完成后再销毁。别图省事把它塞进临时作用域。
