信号量卡死最常见原因是sem_init调用失败未检查返回值，导致后续sem_wait操作未初始化的sem_t；务必检查sem_init返回值，并注意共享参数、内存分配、线程生命周期及sem_destroy调用时机。
sem_wait 一直阻塞却不报错，怎么确认是不是信号量初始化错了
信号量卡死最常见原因是 sem_init 调用失败但没检查返回值，导致后续 sem_wait 对未初始化或非法的 sem_t 操作，行为未定义（常表现为静默卡死）。Linux 下 sem_init 失败时返回 -1 并设置 errno，但很多人直接忽略。
- 务必检查
sem_init返回值：if (sem_init(&sem, 0, 1) != 0) { perror("sem_init"); } - 注意第二个参数：0 表示线程间共享（需在进程内同一地址空间），非 0（如
SEM_PROCESS_SHARED）才用于进程间，但需配合mmap分配内存，否则卡死 - 避免在栈上声明后跨线程传递 —— 线程函数返回后栈变量销毁，
sem_t变成悬垂指针
多线程调用 sem_post 和 sem_wait 顺序混乱，怎么定位资源竞争点
卡死往往不是单次调用问题，而是多个线程对同一信号量的 sem_wait/sem_post 缺少配对或顺序颠倒。比如一个线程反复 sem_wait 却没人 sem_post，或两个线程互相等待对方先释放。
- 用
gdb附加运行中的进程：gdb -p <pid>，然后info threads查看各线程当前阻塞在哪个系统调用（通常是sem_wait或futex） - 对每个阻塞线程执行
bt，确认调用栈是否卡在预期位置；若卡在__lll_lock_wait或类似 futex 等待，大概率是信号量值已为 0 且无 post - 加日志时不要只打 “wait”/“post”，要带线程 ID 和信号量当前值（用
sem_getvalue，注意它返回的是近似值，仅作调试用）
std::thread + POSIX semaphore 混用时，主线程提前 exit 导致子线程卡死
用 std::thread 创建线程，但主线程未 join 或 detach 就调用 exit 或返回 main，整个进程终止，所有线程强制结束 —— 此时若子线程正阻塞在 sem_wait，不会触发清理，现象就是“看起来卡死”，实则是进程已消亡但调试器还没刷新状态。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 确认主线程是否显式等待所有工作线程：
t.join()，而非依赖 RAII 或忘记处理 - 避免在
std::thread析构前既不join也不detach—— 这会触发std::terminate，进程直接退出 - 如果必须提前退出，用
pthread_cancel配合清理函数（不推荐），更稳妥的是设计退出标志 +sem_post唤醒等待线程
sem_destroy 没调用或重复调用引发后续操作异常
sem_destroy 不是可选的善后操作，而是 POSIX 要求的必要步骤。未调用会导致资源泄漏；重复调用（尤其在多线程环境下误判生命周期）可能破坏内核信号量结构，造成后续任意线程调用 sem_wait 卡死或崩溃。
立即学习“C++免费学习笔记（深入）”；
- 只在确定没有线程再访问该信号量后调用
sem_destroy—— 通常放在所有join完成之后、对象析构时 - 避免在类成员中直接用栈上
sem_t，改用std::unique_ptr<sem_t, void(*)(sem_t*)>管理，绑定自定义删除器 - 注意：一旦调用
sem_destroy，该sem_t对象不可再用于任何操作，包括再次sem_init—— 必须重新声明或分配内存
sem_post 被条件分支跳过，或者线程 A 在 B 还没 start 前就 sem_wait，这些逻辑缺陷不会报编译错误，只能靠日志+gdb+明确的初始化/销毁边界来揪出来。 
