上篇把线程创建与管理聊了。今天聊多线程里最让人头疼的问题——数据竞争和死锁。先讲个真实的bug故事。之前做一个多传感器融合的项目激光雷达和IMU的数据分别由两个线程读取融合之后发布。上线测试的时候程序跑着跑着就卡死了——不是崩溃是卡住不动了。没有任何错误日志就是所有线程都不干活了。排查了两天最后发现是死锁。问题出在哪两个线程各自持有两把锁但加锁顺序不一样// 线程A先锁lidar_mutex再锁fusion_mutex void lidarThread() { while (running_) { lock_guardmutex lock1(lidar_mutex_); auto scan latestScan_; lock_guardmutex lock2(fusion_mutex_); // 等fusion_mutex fusionData_.lidar scan; } } // 线程B先锁fusion_mutex再锁imu_mutex void imuThread() { while (running_) { lock_guardmutex lock1(imu_mutex_); auto imu latestImu_; lock_guardmutex 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的mutex2B等A的mutex1 }mutex的基本用法C11提供了std::mutex来解决数据竞争。基本用法很简单mutex mtx; int sharedCounter 0; void increment() { mtx.lock(); sharedCounter; // 临界区同一时间只有一个线程能访问 mtx.unlock(); }但直接用lock/unlock很危险——如果临界区里抛了异常unlock不会被执行锁就永远不会释放。所以C推荐使用RAII方式的lock_guard或unique_lockvoid increment() { lock_guardmutex lock(mtx); // 构造时加锁 sharedCounter; // 析构时自动解锁即使抛异常也安全 }lock_guard是最简单的锁包装——构造加锁析构解锁没有别的选项。unique_lock更灵活支持延迟加锁、手动解锁、try_lockvoid flexibleLock() { unique_lockmutex lock(mtx, defer_lock); // 先不锁 // 做一些不需要锁的事 prepareData(); lock.lock(); // 现在才加锁 criticalSection(); lock.unlock(); // 可以手动解锁 // 非阻塞尝试 if (lock.try_lock()) { // 拿到锁了 } else { // 没拿到做别的事 } }死锁的四个必要条件死锁的发生需要同时满足四个条件互斥——资源同一时间只能被一个线程持有。锁天然是互斥的这个没法消除。持有并等待——线程持有一把锁的同时等待另一把锁。不可抢占——锁不能被强制从持有者手里夺走。循环等待——线程A等B持有的锁B等C持有的锁C又等A持有的锁。要防止死锁只要打破其中任意一个条件就行。最实用的做法是打破循环等待——让所有线程按相同的顺序加锁。// 解决方案统一加锁顺序 void threadA() { lock_guardmutex lock1(mutex1_); // 先锁1 lock_guardmutex lock2(mutex2_); // 再锁2 } void threadB() { lock_guardmutex lock1(mutex1_); // 同样的顺序 lock_guardmutex lock2(mutex2_); // 先锁1再锁2 }C17还提供了一个更方便的工具——std::lock可以同时锁多把锁而不死锁void transferMoney(Account from, Account to, double amount) { // std::lock同时锁两个mutex内部用try-and-back-off避免死锁 lock(from.mutex_, to.mutex_); lock_guardmutex lockFrom(from.mutex_, adopt_lock); lock_guardmutex lockTo(to.mutex_, adopt_lock); from.balance_ - amount; to.balance_ amount; }机器人开发中的典型数据竞争在机器人系统里数据竞争最常出现在传感器数据和共享状态上。class SensorFusion { mutex mtx_; Pose currentPose_; public: void updateFromImu(const ImuData data) { lock_guardmutex lock(mtx_); currentPose_ integrateImu(data); } void updateFromLidar(const LidarScan scan) { lock_guardmutex lock(mtx_); currentPose_ matchLidar(scan); } Pose getPose() { lock_guardmutex lock(mtx_); return currentPose_; } };这个设计是对的但要注意锁的粒度。如果临界区太大锁住了大量计算其他线程就得等着并行度下降。如果临界区太小只锁了一个赋值可能保护不够。经验法则是只锁住访问共享数据的那几行代码计算逻辑放在锁外面。面试中的关键考点mutex和spinlock有什么区别mutex拿不到锁时会阻塞线程让出CPUspinlock拿不到锁时会一直循环尝试忙等不让出CPU。mutex适合临界区较长的场景spinlock适合临界区极短几个指令的场景。recursive_mutex是什么允许同一个线程对同一把mutex多次加锁而不会死锁。但一般不推荐用——如果你发现需要recursive_mutex多半是设计有问题。怎么排查死锁Linux下可以用gdb attach到进程看每个线程的调用栈找出各自持有什么锁、在等什么锁。工具层面可以用ThreadSanitizerTSan编译时加-fsanitizethread就能检测潜在的数据竞争。给正在准备面试的你互斥锁和死锁是面试高频考点。基本的mutex用法必须熟练lock_guard和unique_lock的区别要能讲清楚。死锁的四个条件和预防方法也要能说出来。最重要的是写代码的时候要有锁的意识。拿到一把锁的时候脑子里就要想清楚——这把锁和其他锁有没有顺序冲突会不会和其他线程的加锁顺序形成环路养成这个好习惯能帮你避免绝大多数死锁问题在面试和实际项目开发中都非常有用。下篇聊条件变量——生产者消费者模型在传感器数据流中的实际应用。这是多线程协作的核心机制和重要基础。如果这篇文章对你有帮助欢迎点赞、在看、转发三连。 你的支持是我持续更新的最大动力。「机器人软件开发面试·从入门到精通」连载系列上一篇第54篇 多线程之线程创建与管理——机器人系统中为什么必须用多线程 下一篇预告第56篇 多线程之条件变量——生产者消费者模型在传感器数据中的应用有任何问题欢迎评论区留言我会尽量回复。