pthreads中pthread_cond_wait出现死锁问题求助

嘿，我来帮你排查这个多线程统计行数的阻塞/死锁问题！虽然你没贴全代码，但结合这类场景的常见坑，我给你列几个最可能的原因，以及对应的排查方向：

最可能的元凶：互斥锁未正确释放 #

如果你的线程是用全局变量来累加总行数，那肯定用到了互斥锁来保护这个变量。这时候最容易出问题的就是锁的加解锁不成对——比如某个线程在获取锁之后，因为文件读取失败（你省略了错误检查，这种概率很高）直接退出，没执行解锁操作，导致其他线程永远拿不到锁，全部阻塞在pthread_mutex_lock上。

举个典型的错误示例：

pthread_mutex_lock(&count_mutex);
// 假设这里fgets读取失败，直接return，锁没释放！
if (fgets(buf, sizeof(buf), fp) == NULL) {
    pthread_exit(NULL); // 或者直接return
}
total_lines++;
pthread_mutex_unlock(&count_mutex);

这种情况会把锁彻底“占死”，所有后续尝试加锁的线程都会卡住，表现为整个程序阻塞。

主线程同步逻辑出错 #

如果主线程是通过pthread_join等待所有子线程结束，那要检查是不是：

• 有没有漏加某个线程的pthread_join？比如创建了10个线程，但只join了9个，主线程会一直等那个没被join的线程，哪怕该线程已经退出，也会变成僵尸线程，导致主线程永久阻塞。
• 有没有用了其他同步机制（比如条件变量）但逻辑错误？比如主线程在条件变量上等待，但子线程忘记发送信号，或者信号发送时机不对，导致主线程永远等不到唤醒。

文件资源相关的阻塞（非死锁，但表现类似） #

虽然你是每个线程处理一个独立文件，但如果某个线程打开文件后没关闭，导致系统文件描述符耗尽，后续线程调用fopen就会阻塞（或者返回错误，但你省略了错误检查，线程可能卡在那里）。这种情况偏向资源耗尽，但也会表现为程序卡住。

排查建议 #

1. 检查锁的成对性：把所有加锁的地方都找出来，确保每个pthread_mutex_lock都对应一个pthread_mutex_unlock，尤其是在分支退出、循环中断的地方，哪怕出错也要解锁。可以用goto来统一处理解锁逻辑，比如：

pthread_mutex_lock(&count_mutex);
if (some_error) {
    goto unlock_and_exit;
}
// 业务逻辑
unlock_and_exit:
pthread_mutex_unlock(&count_mutex);
pthread_exit(NULL);

2. 加日志定位：在每个线程的关键节点（比如锁操作前后、文件打开/关闭、线程退出前）打印日志，看哪个线程停在了哪个步骤，就能快速定位阻塞点。
3. 用调试工具：用gdb attach到阻塞的进程，输入info threads查看所有线程的状态，再用bt查看每个线程的调用栈，就能清楚看到线程是不是卡在加锁或者等待操作上。

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