pthread_mutex_init 初始化失败主因是非法参数：未初始化的 mutex 变量直接传入、重复 init 已初始化锁、attr 参数非法；静态初始化仅用于全局/静态变量，局部变量须用动态初始化。
pthread_mutex_init 初始化失败的常见原因
初始化互斥锁时 pthread_mutex_init 返回非零值，通常不是“锁初始化失败”本身，而是传入了非法参数。最常踩的坑是把未初始化的 pthread_mutex_t 变量直接传进去，却忘了它不是 POD 类型、不能靠默认值安全使用。
- 必须用
PTHREAD_MUTEX_INITIALIZER静态初始化，或调用pthread_mutex_init动态初始化 —— 二者不可混用 - 动态初始化后若
pthread_mutex_init返回EINVAL，大概率是传入了已初始化过的锁（重复 init）或attr参数非法（如用了已销毁的 attr 对象） - 静态初始化仅适用于全局/静态变量；局部变量务必用
pthread_mutex_init，否则栈上未定义内存可能被当作锁状态读取，引发不可预测行为
加锁后忘记解锁导致的隐性死锁
这不是编译报错，也不会立刻 crash，但会让其他线程在 pthread_mutex_lock 处无限等待。尤其在有分支、异常路径（比如 goto 错误处理）、或早期 return 的函数里，pthread_mutex_unlock 很容易被漏掉。
- 推荐写法：加锁后紧跟着写好对应的解锁语句（哪怕先注释掉），再填业务逻辑
- 避免在持有锁期间调用可能阻塞或长耗时的函数（如
malloc、printf、文件 I/O），这些操作本身不保证线程安全，也可能间接触发锁竞争 - 检查是否在信号处理函数中调用了
pthread_mutex_lock—— 大多数互斥锁函数不是 async-signal-safe，这么做属于未定义行为
多锁顺序不一致引发的循环等待
两个线程分别按不同顺序获取两把锁，就构成死锁经典场景。例如线程 A 先 lock(mutex_a) 再 lock(mutex_b)，而线程 B 反过来，只要执行时机交错，就会卡死。
- 所有线程必须严格遵循**全局一致的锁获取顺序**，比如按变量地址大小排序：总是先 lock 地址小的那个
mutex - 可以用
pthread_mutex_trylock配合退避重试，但注意它不解决根本问题，只是把死锁转为忙等或失败，仍需统一顺序 - 避免嵌套锁：一个函数内部不应在已持有一把锁的前提下，再去调用可能获取另一把锁的第三方函数（除非你完全掌控其锁策略）
递归锁不是万能解药
有人以为把普通锁换成递归锁（PTHREAD_MUTEX_RECURSIVE）就能绕过死锁，其实只是掩盖了设计缺陷。递归锁允许同一线程多次 lock，但依然会阻塞其他线程，且无法解决跨线程的锁顺序冲突。
立即学习“C语言免费学习笔记（深入）”；
- 递归锁开销更大，且某些平台（如部分旧版 musl libc）对其支持不完整
- 若函数 A 持锁调用函数 B，B 又试图获取同一把锁，说明本该拆成无锁接口或重构调用链 —— 用递归锁等于默认这种耦合是合理的
-
pthread_mutex_destroy前必须确保锁已解锁且无等待线程，递归锁还要求 unlock 次数等于 lock 次数，否则 destroy 行为未定义
真正难防的不是单个锁的误用，而是多个锁之间的依赖关系没有显式建模。哪怕只加两行注释说明“此处需同时持有 A 和 B，顺序为 A→B”，也能大幅降低后续维护引入死锁的概率。
