C语言多线程统计目录文件大小遇Mutex互斥锁性能下降问题求助

核心性能问题点 #

• 工作线程忙等开销极大：你当前getQueue函数中没有使用条件变量，当队列无任务时，线程会持续循环抢锁、释放锁，完全占满CPU核心，线程数量越多，锁竞争开销越大，反而会拖累整体性能。
• 队列操作效率低且锁持有时间过长：用数组实现队列，出队时需要遍历移动所有剩余元素，时间复杂度为O(n)，且整个操作都在持有mutex的临界区内，锁被长时间占用，进一步加剧锁竞争。
• 临界区包含慢操作，完全丧失并发收益：execute函数中持有mutex1的临界区包含了两次getFileSize（即lstat系统调用）、路径匹配遍历、数组移动等大量慢操作，lstat本身是会触发磁盘IO的阻塞操作，持锁执行时所有其他线程都会被阻塞，多线程完全没法并行执行，反而多了线程切换和锁竞争的额外开销。
• 重复调用慢函数：同一个任务路径下getFileSize被调用了两次，白白浪费了一倍的IO开销。
• 统计数组操作效率极低：每次更新统计值时都要遍历并移动整个listOfArg数组，时间复杂度O(n)，且在临界区内执行，进一步拉长锁持有时间。

优化方案 #

• 新增条件变量解决忙等问题：
  定义pthread_cond_t cond，队列空时线程调用pthread_cond_wait释放锁并休眠，主线程添加任务时调用pthread_cond_signal唤醒等待线程，设置结束标记后调用pthread_cond_broadcast唤醒所有线程退出，完全消除空轮询的开销。
• 优化队列实现：
  改用链表或者环形缓冲区实现任务队列，出队、入队操作时间复杂度降到O(1)，大幅缩短mutex的持有时间。
• 缩小mutex1的临界区范围：
  先在无锁状态下调用一次getFileSize拿到文件大小，再持锁更新统计值，不要把lstat这类慢操作放到临界区内。
• 优化统计逻辑：
  不要每次更新时移动listOfArg数组，直接遍历数组匹配路径即可，也可以提前建立路径到统计结构体的哈希映射，把查找复杂度降到O(1)。
• 消除重复调用：
  同一个任务只调用一次getFileSize，将结果存到临时变量后复用。

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