销毁并重新初始化后Mutex永久等待的问题排查

你的核心问题出在循环内反复初始化、销毁互斥量的操作逻辑，以及可能存在的锁未正确释放就销毁的情况，具体分析和解决如下：

问题原因 #

1. 互斥量生命周期管理错误：
   虽然pthread规范允许销毁互斥量后再次调用pthread_mutex_init重新初始化，但这种操作非常危险——如果在pthread_mutex_destroy和下一次pthread_mutex_init之间，有任何代码（哪怕是当前线程的后续循环逻辑）尝试访问该互斥量，都会触发未定义行为。你第二次循环的死锁，大概率是第一次循环销毁互斥量时，锁并未完全释放，或者互斥量的内存状态被破坏，导致第二次初始化后的互斥量处于异常锁定状态。
2. 销毁时可能持有锁：
   如果在调用pthread_mutex_destroy时，互斥量还处于被锁定的状态，会直接导致未定义行为，这也是后续出现__pthread_mutex_cond_lock_adjust: Assertion (mutex->__data.__kind & 128) == 0' failed.断言错误的核心原因——pthread库检测到互斥量的状态不符合预期。
3. 不必要的反复初始化/销毁：
   互斥量的初始化和销毁并非轻量操作，循环内重复执行完全是资源浪费，且大幅提升了出现时序问题的概率。

解决方案 #

1. 调整互斥量生命周期，移到循环外初始化/销毁 #

这是最直接且安全的修复方式，让互斥量的生命周期覆盖整个循环的所有使用场景：

pthread_mutex_t mutexQueue;
// 仅初始化一次
pthread_mutex_init(&mutexQueue, NULL);

for(int i = 80; i<= 8080; i++)
{
    ...
    pthread_mutex_lock(&mutexQueue);
    // 执行你的临界区操作
    ...
    // 必须确保临界区操作完成后解锁
    pthread_mutex_unlock(&mutexQueue);
    ...
}

// 循环结束后再销毁
pthread_mutex_destroy(&mutexQueue);

2. 强制保证锁的正确释放 #

无论任何代码路径，只要调用了pthread_mutex_lock，就必须对应调用pthread_mutex_unlock，绝对不能在持有锁的情况下调用pthread_mutex_destroy。如果临界区内有分支逻辑，要特别注意每个分支都要解锁。

3. 静态初始化可选方案 #

如果你的互斥量是静态分配的，可以直接用PTHREAD_MUTEX_INITIALIZER宏初始化，省去显式调用pthread_mutex_init的步骤（注意这种方式没有错误检查）：

static pthread_mutex_t mutexQueue = PTHREAD_MUTEX_INITIALIZER;

for(int i = 80; i<= 8080; i++)
{
    pthread_mutex_lock(&mutexQueue);
    // 临界区操作
    pthread_mutex_unlock(&mutexQueue);
}

// 静态初始化的互斥量也可以调用destroy销毁
pthread_mutex_destroy(&mutexQueue);

补充官方文档要点 #

在默认互斥量属性适用的情况下，宏PTHREAD_MUTEX_INITIALIZER可用于初始化静态分配的互斥量。其效果等效于调用pthread_mutex_init()且attr参数为NULL的动态初始化，区别在于不执行错误检查。

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