持有全局mutex的线程被杀死后无法解锁该如何处理

核心前提：强制终止持有互斥锁的线程是并发编程的高危操作，绝大多数场景下都应该优先避免，你遇到的死锁问题是这类操作的典型副作用。

以下是按推荐优先级排序的解决方案：

1. 替换强制终止逻辑，采用协作式退出机制 #

这是最推荐的根因修复方案，完全规避资源泄漏风险。

• 为线程定义原子类型的退出标记，例如C++场景下的std::atomic<bool> thread_exit_req，C场景下的_Atomic bool thread_exit_req
• 线程的执行逻辑中增加定期检查退出标记的逻辑，一旦检测到退出标记为真，立刻主动释放当前持有的所有资源（包括互斥锁、动态内存、文件句柄等），再正常结束线程执行
• 需要终止线程时，仅需要将对应退出标记设为真，再调用join等待线程自然退出即可，不会出现互斥锁未释放的问题

2. 使用健壮属性的互斥锁 #

如果业务场景确实无法避免强制终止线程的操作，可以使用操作系统原生支持的健壮互斥锁处理异常场景：

• POSIX线程库中可通过pthread_mutexattr_setrobust()接口给互斥锁设置PTHREAD_MUTEX_ROBUST属性
• 当持有该类互斥锁的线程异常退出且未释放锁时，其他后续调用pthread_mutex_lock()的线程会收到EOWNERDEAD返回值
• 捕获到该返回值后，调用pthread_mutex_consistent()即可将互斥锁恢复到一致状态，后续可以正常执行解锁、加锁操作
• 注意该方案需要你自行处理互斥锁保护的共享数据的一致性：原持有锁的线程中途退出，共享数据可能处于未完成更新的中间状态，需要你自行判断数据是否可修复，或者执行重置逻辑

3. 互斥锁上层封装所有权校验 #

如果前两种方案都无法适配你的环境，可以在互斥锁上层增加一层封装做权限校验：

• 封装结构中额外记录当前持有互斥锁的线程ID，加锁成功时更新该ID，解锁时清空
• 执行线程终止操作前，先校验待终止的线程ID是否和当前持有锁的ID一致，如果一致，可选择等待线程释放锁后再执行终止，或者先做共享数据的备份再执行终止
• 该方案实现复杂度高，且需要修改所有加锁/解锁逻辑，仅作为极端场景的兜底方案

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