程序调用pthread_join()时卡住，Factory线程疑似挂起求助

这种线程挂起导致主线程卡在pthread_join的情况我之前排查过好多次，给你几个实用的方向：

• 先确认终止信号的传递有效性
  如果你用全局变量作为线程退出的标志，一定要确保它是原子类型或者加了volatile修饰，不然编译器优化可能让线程看不到变量的更新，一直死循环。比如把普通的bool running = true;改成：

  _Atomic bool factory_running = true; // C11标准
  // 或者兼容旧版本的写法
  volatile sig_atomic_t factory_running = 1;
  

  另外检查线程内部的循环逻辑，有没有某个分支跳过了终止标志的检查？比如线程在处理某个任务时，一直卡在子流程里没回到循环头部判断退出条件。

• 排查线程阻塞的系统调用
  如果Factory线程里用到了pthread_cond_wait、sem_wait、read这类会阻塞的调用，即使设置了终止标志，线程也会一直挂在这些调用上：

  • 要是用了条件变量，在主线程设置终止标志后，必须调用pthread_cond_broadcast()唤醒所有等待该条件变量的线程；
  • 对于IO操作，可以改成非阻塞模式，或者给文件描述符设置超时（比如用select/epoll包裹）；
  • 信号量的话，要确保在终止时释放足够的信号量，让等待的线程能退出。

• 用工具直接定位线程挂起位置
  光靠打印有时候找不到卡点，直接用调试工具看调用栈最直接：

  • 用pstack <进程PID>，终端会输出所有线程的当前调用栈，一眼就能看到哪个线程卡在了哪个函数上；
  • 或者用GDB：gdb attach <进程PID>，输入info threads列出所有线程，切换到目标Factory线程（thread <线程编号>），再输入bt查看完整调用栈，精准定位卡点。

• 检查是否存在死锁
  有没有可能线程在退出时需要获取某个锁，但主线程已经持有这个锁？或者主线程在pthread_join前拿着锁，而线程退出时也在等这个锁，互相卡住？
  可以在加解锁的地方加打印，或者用pthread_mutex_trylock替代普通的pthread_mutex_lock，如果返回EBUSY就说明锁被占用，能快速定位死锁场景。

• 验证pthread_join的调用逻辑
  确认你循环pthread_join时传入的线程ID都是有效的，而且每个线程只被join一次。如果不小心重复join同一个已退出的线程ID，或者传入了错误的ID，也可能导致异常阻塞。可以在每次调用pthread_join前打印线程ID，和创建线程时保存的ID对比。

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