操作系统Mutexes死锁可能性判定及规避方案相关技术问题

死锁判断结论 #

当前场景不会发生死锁。

核心原因 #

死锁需要同时满足四个必要条件：互斥访问、持有并等待、资源不可剥夺、循环等待。
当前场景中两个线程的加锁顺序完全统一，均为先申请guard_mtx_1，成功拿到锁之后才会尝试申请guard_mtx_2，直接破坏了死锁必需的「循环等待」条件：不可能出现某线程持有guard_mtx_2同时等待guard_mtx_1的情况，因此不存在永久阻塞的死锁风险。

原有回答的疏漏点 #

你给出的结论是正确的，但推理逻辑存在不严谨的地方：

• 你默认线程会连续执行完从加guard_mtx_1到解guard_mtx_1的完整流程，实际上操作系统的线程调度是可抢占的，线程在拿到guard_mtx_1后、申请guard_mtx_2前完全可能被调度切走，让其他线程运行。
• 但即便发生上述调度，其他线程因为拿不到已经被占用的guard_mtx_1，根本无法进入申请guard_mtx_2的逻辑，因此永远不会出现循环等待的情况，最终仍然不会发生死锁。

代码优化建议 #

虽然当前代码不会触发死锁，但仍然存在可优化的点：
解锁顺序不符合「加锁逆序解锁」的常规最佳实践：当前代码先解guard_mtx_1、再解guard_mtx_2，会导致guard_mtx_2的持有时间被不必要拉长，降低并发度。建议调整为修改完list_2后先解guard_mtx_2，再解guard_mtx_1，优化后代码如下：

...
lock(guard_mtx_1);
Add(list_1, var_1);
lock(guard_mtx_2);
Add(list_2, var_2);
unlock(guard_mtx_2);
unlock(guard_mtx_1);
...

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