为何解锁unique_lock会导致程序崩溃？请求技术解答

嘿，这个崩溃的原因其实很典型——你犯了一个RAII锁使用的常见错误：直接操作底层互斥量的unlock，绕过了unique_lock的管理逻辑，导致了重复解锁的未定义行为。

咱们一步步拆解你的代码流程：

1. 在main函数里，std::unique_lock lock(myMutex);执行时，已经通过unique_lock的构造函数锁住了myMutex，并且这个锁的所有权是由lock对象来管理的。
2. 启动lockMe线程后，线程里的unique_lock会尝试获取myMutex，但此时锁被main里的lock持有，所以线程会阻塞等待。
3. 1秒后，你直接调用了myMutex.unlock();——这一步手动把互斥量解锁了，但lock对象完全不知道这件事，它内部仍然认为自己还持有锁。
4. 接下来lockMe线程拿到锁，输出"Thread"后，线程里的unique_lock析构，会正常解锁myMutex。
5. 最后main函数结束时，lock对象析构，它会尝试再次调用myMutex.unlock()来释放它“认为自己还持有”的锁——但此时myMutex已经处于未锁定状态，重复解锁互斥量是C++标准里明确的未定义行为，直接导致程序崩溃。

修复方案 #

你应该通过unique_lock提供的成员函数来管理锁的状态，而不是直接操作底层的mutex：

方案1：调用unique_lock的unlock()方法

把main里的myMutex.unlock();改成lock.unlock();，这样unique_lock会内部更新自己的状态，标记锁已释放，析构时就不会再尝试解锁了：

#include <iostream>
#include <string>
#include <mutex>
#include <thread>
#include <chrono>
std::mutex myMutex;
void lockMe() {
    std::unique_lock lock(myMutex);
    std::cout << "Thread\n";
}
int main() {
    std::unique_lock lock(myMutex);
    auto c = std::thread(lockMe);
    std::this_thread::sleep_for(std::chrono::seconds(1));
    std::cout << "Main\n";
    lock.unlock(); // 通过unique_lock解锁，而非直接操作mutex
    c.join();
    return 0;
}

方案2：利用作用域自动释放锁

更优雅的做法是把unique_lock放在一个局部作用域里，当作用域结束时，lock对象自动析构并解锁，完全不需要手动操作：

#include <iostream>
#include <string>
#include <mutex>
#include <thread>
#include <chrono>
std::mutex myMutex;
void lockMe() {
    std::unique_lock lock(myMutex);
    std::cout << "Thread\n";
}
int main() {
    {
        std::unique_lock lock(myMutex);
        std::this_thread::sleep_for(std::chrono::seconds(1));
        std::cout << "Main\n";
    } // lock在此处析构，自动解锁myMutex
    auto c = std::thread(lockMe);
    c.join();
    return 0;
}

核心总结 #

unique_lock这类RAII锁的核心价值就是帮你自动管理锁的生命周期，避免手动操作mutex带来的遗忘解锁、重复解锁等问题。永远不要绕过锁对象直接操作底层的mutex，否则就违背了使用RAII锁的初衷，很容易触发未定义行为。

内容的提问来源于stack exchange，提问作者iHowell