Zephyr RTOS内核基础：线程同步之互斥量从一次现场崩溃说起去年在做一个工业网关项目，三块STM32H743通过CAN-FD互联，每块板子跑Zephyr 2.7。现场调试时发现一个诡异现象：系统运行大约47分钟后，某块板子的LCD显示突然卡死，但串口还能响应。用调试器挂上去一看，一个负责更新UI的线程正卡在k_mutex_lock()调用上，已经等了超过30秒。更奇怪的是，持有该互斥量的线程明明已经退出了——至少代码逻辑上是这么写的。翻看代码，问题出在一个共享的传感器数据结构上。线程A负责从SPI读取数据并更新结构体，线程B负责将数据通过MQTT上传。两个线程都用了同一个互斥量保护这个结构体，但线程A在某个异常分支里调用了k_mutex_unlock()两次——第一次正常释放，第二次释放了一个已经被释放的互斥量。结果就是互斥量的内部计数变成负数，内核直接把这个互斥量标记为“损坏”，后续所有等待的线程全部死锁。这个坑让我意识到，互斥量看似简单，但Zephyr的实现细节和POSIX标准有微妙差异，稍不注意就会踩雷。互斥量在Zephyr中的真实面目Zephyr的互斥量本质上是一个信号量加上优先级继承机制。内核源码里struct k_mutex包含一个owner字段指向当前持有线程，一个lock_count记录重入次数，还有一个wait_q管理等待队列。与裸机上的自旋锁不同，