上篇把线程创建与管理聊了。今天聊多线程里最让人头疼的问题——数据竞争和死锁。

先讲个真实的bug故事。

之前做一个多传感器融合的项目，激光雷达和IMU的数据分别由两个线程读取，融合之后发布。上线测试的时候，程序跑着跑着就卡死了——不是崩溃，是卡住不动了。没有任何错误日志，就是所有线程都不干活了。

排查了两天，最后发现是死锁。

问题出在哪？两个线程各自持有两把锁，但加锁顺序不一样：

// 线程A：先锁lidar_mutex，再锁fusion_mutex
void lidarThread() {
    while (running_) {
        lock_guard<mutex> lock1(lidar_mutex_);
        auto scan = latestScan_;
        
        lock_guard<mutex> lock2(fusion_mutex_);  // 等fusion_mutex
        fusionData_.lidar = scan;
    }
}

// 线程B：先锁fusion_mutex，再锁imu_mutex
void imuThread() {
    while (running_) {
        lock_guard<mutex> lock1(imu_mutex_);
        auto imu = latestImu_;
        
        lock_guard<mutex> lock2(fusion_mutex_);  // 也等fusion_mutex
        fusionData_.imu = imu;
    }
}

某个时刻，线程A拿了lidar_mutex_等fusion_mutex_，线程B拿了imu_mutex_也要等fusion_mutex_——等等，这其实不是死锁，只是竞争。真正的死锁是互相等对方手里的锁。让我还原一下当时的真实场景：

// 真正的死锁场景
void threadA() {
    mutex1_.lock();   // A拿了mutex1
    // ... 做一些事
    mutex2_.lock();   // A等mutex2
}

void threadB() {
    mutex2_.lock();   // B拿了mutex2
    // ... 做一些事
    mutex1_.lock();   // B等mutex1
    // 死锁！A等B的mutex2，B等A的mutex1
}

mutex的基本用法

C++11提供了std::mutex来解决数据竞争。基本用法很简单：

mutex mtx;
int sharedCounter = 0;

void increment() {
    mtx.lock();
    sharedCounter++;     // 临界区，同一时间只有一个线程能访问
    mtx.unlock();
}

但直接用lock/unlock很危险——如果临界区里抛了异常，unlock不会被执行，锁就永远不会释放。所以C++推荐使用RAII方式的lock_guard或unique_lock：

void increment() {
    lock_guard<mutex> lock(mtx);  // 构造时加锁
    sharedCounter++;
    // 析构时自动解锁，即使抛异常也安全
}

lock_guard是最简单的锁包装——构造加锁，析构解锁，没有别的选项。unique_lock更灵活，支持延迟加锁、手动解锁、try_lock：

void flexibleLock() {
    unique_lock<mutex> lock(mtx, defer_lock);  // 先不锁
    
    // 做一些不需要锁的事
    prepareData();
    
    lock.lock();   // 现在才加锁
    criticalSection();
    lock.unlock(); // 可以手动解锁
    
    // 非阻塞尝试
    if (lock.try_lock()) {
        // 拿到锁了
    } else {
        // 没拿到，做别的事
    }
}

死锁的四个必要条件

死锁的发生需要同时满足四个条件：

互斥——资源同一时间只能被一个线程持有。锁天然是互斥的，这个没法消除。

持有并等待——线程持有一把锁的同时，等待另一把锁。

不可抢占——锁不能被强制从持有者手里夺走。

循环等待——线程A等B持有的锁，B等C持有的锁，C又等A持有的锁。

要防止死锁，只要打破其中任意一个条件就行。最实用的做法是打破"循环等待"——让所有线程按相同的顺序加锁。

// 解决方案：统一加锁顺序
void threadA() {
    lock_guard<mutex> lock1(mutex1_);  // 先锁1
    lock_guard<mutex> lock2(mutex2_);  // 再锁2
}

void threadB() {
    lock_guard<mutex> lock1(mutex1_);  // 同样的顺序！
    lock_guard<mutex> lock2(mutex2_);  // 先锁1再锁2
}

C++17还提供了一个更方便的工具——std::lock，可以同时锁多把锁而不死锁：

void transferMoney(Account& from, Account& to, double amount) {
    // std::lock同时锁两个mutex，内部用try-and-back-off避免死锁
    lock(from.mutex_, to.mutex_);
    lock_guard<mutex> lockFrom(from.mutex_, adopt_lock);
    lock_guard<mutex> lockTo(to.mutex_, adopt_lock);
    
    from.balance_ -= amount;
    to.balance_ += amount;
}

机器人开发中的典型数据竞争

在机器人系统里，数据竞争最常出现在传感器数据和共享状态上。

class SensorFusion {
    mutex mtx_;
    Pose currentPose_;
    
public:
    void updateFromImu(const ImuData& data) {
        lock_guard<mutex> lock(mtx_);
        currentPose_ = integrateImu(data);
    }
    
    void updateFromLidar(const LidarScan& scan) {
        lock_guard<mutex> lock(mtx_);
        currentPose_ = matchLidar(scan);
    }
    
    Pose getPose() {
        lock_guard<mutex> lock(mtx_);
        return currentPose_;
    }
};

这个设计是对的，但要注意锁的粒度。如果临界区太大（锁住了大量计算），其他线程就得等着，并行度下降。如果临界区太小（只锁了一个赋值），可能保护不够。经验法则是：只锁住访问共享数据的那几行代码，计算逻辑放在锁外面。

面试中的关键考点

"mutex和spinlock有什么区别？"mutex拿不到锁时会阻塞线程，让出CPU；spinlock拿不到锁时会一直循环尝试（忙等），不让出CPU。mutex适合临界区较长的场景，spinlock适合临界区极短（几个指令）的场景。

"recursive_mutex是什么？"允许同一个线程对同一把mutex多次加锁而不会死锁。但一般不推荐用——如果你发现需要recursive_mutex，多半是设计有问题。

"怎么排查死锁？"Linux下可以用gdb attach到进程，看每个线程的调用栈，找出各自持有什么锁、在等什么锁。工具层面可以用ThreadSanitizer（TSan），编译时加-fsanitize=thread就能检测潜在的数据竞争。

给正在准备面试的你

互斥锁和死锁是面试高频考点。基本的mutex用法必须熟练，lock_guard和unique_lock的区别要能讲清楚。死锁的四个条件和预防方法也要能说出来。

最重要的是：写代码的时候要有"锁的意识"。拿到一把锁的时候，脑子里就要想清楚——这把锁和其他锁有没有顺序冲突？会不会和其他线程的加锁顺序形成环路？养成这个好习惯能帮你避免绝大多数死锁问题，在面试和实际项目开发中都非常有用。

下篇聊条件变量——生产者消费者模型在传感器数据流中的实际应用。这是多线程协作的核心机制和重要基础。

---

如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。 你的支持是我持续更新的最大动力。

「机器人软件开发面试·从入门到精通」连载系列 上一篇：第54篇 多线程之线程创建与管理——机器人系统中为什么必须用多线程 下一篇预告：第56篇 多线程之条件变量——生产者消费者模型在传感器数据中的应用

有任何问题欢迎评论区留言，我会尽量回复。