gdb无法感知std::mutex优先级，因其无优先级概念；需确认是否显式启用PTHREAD_PRIO_INHERIT属性，再通过thread apply all bt和info threads分析阻塞线程与持有者，结合-O0 -g编译定位死锁链。
gdb 本身不感知互斥锁的“优先级”——C++ 标准库的 std::mutex 没有优先级概念，Linux 的 pthread mutex 也不支持优先级继承（除非显式使用 PTHREAD_PRIO_INHERIT 属性并配合 pthread_mutexattr_setprotocol）。 所以你真正要查的，不是“锁的优先级”，而是：线程是否因锁阻塞、谁持有锁、是否形成死锁链、或是否误用了带优先级协议的锁。下面分场景说明怎么做。
确认程序是否用了可继承优先级的 mutex
标准 std::mutex 编译后底层调用的是普通 pthread mutex，不启用优先级继承。只有手动构造带属性的 pthread mutex 才可能涉及优先级。如果你看到死锁或奇怪的调度行为，先检查是否真的启用了 PTHREAD_PRIO_INHERIT：
- 代码中必须显式设置 mutex 属性：
pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_INHERIT) - gdb 中无法直接读取该属性值，但可通过
info proc mappings或thread apply all bt看线程是否卡在futex_wait或pthread_mutex_lock调用栈里 - 若没手动设属性，就别在 gdb 里找“优先级”——它根本不存在
查看哪个线程持有了某个 mutex
gdb 无法直接 dump std::mutex 的内部状态（比如 owner tid），因为它是 opaque 类型。但你可以间接推断：
- 用
thread apply all bt查所有线程调用栈，找出哪些线程停在std::mutex::lock()或pthread_mutex_lock—— 它们正在等待 - 再找唯一一个没卡在 lock、却在临界区里执行的线程：它大概率就是持有者（注意：需结合业务逻辑判断，比如它正访问共享变量
shared_data） - 如果用的是
std::recursive_mutex或自定义锁包装类，且你加了调试字段（如owner_tid），那可以用print lock.owner_tid直接看
定位死锁时的循环等待链
所谓“优先级问题”往往其实是死锁的表现。两个线程互相等对方释放锁，gdb 可帮你画出等待图：
立即学习“C++免费学习笔记（深入）”；
- 运行
thread apply all bt，记录每个线程的阻塞点，例如：Thread 2: #0 futex_wait ... at ... in pthread_mutex_lockThread 3: #0 futex_wait ... at ... in pthread_mutex_lock - 再用
info threads看哪个线程还在运行（无*futex调用栈），它很可能正持有 Thread 2 等的锁、同时又在等 Thread 3 的锁 - 关键线索藏在源码行号里：比如 Thread 2 卡在
mtx1.lock()，Thread 3 卡在mtx2.lock()，而它们各自上一个成功加锁的 mutex 正好是对方等待的那个——这就是循环等待
避免被优化干扰：必须用 -g -O0 编译
多线程调试最常踩的坑不是命令不会用，而是编译选项不对：
- 一定要加
-g，否则bt显示不了函数名和行号 - 务必禁用优化：
-O0。否则编译器可能把锁操作重排、内联、甚至删掉，导致 gdb 看到的执行流和源码完全对不上 - 链接时要带
-lpthread（g++ 下通常自动处理，但用 gcc 编译 C++ 时容易漏） - 验证方式：
readelf -S ./a.out | grep debug应有多个.debug_*段；nm ./a.out | grep mutex应能看到符号
真正难的不是命令怎么输，而是得意识到：gdb 是观察者，不是仲裁者。它看不到“优先级”，只能看到线程状态、调用栈、内存内容。如果你怀疑优先级倒置，得先确认系统是否启用了实时调度（sched_setscheduler）、mutex 是否配置了 PTHREAD_PRIO_INHERIT，再回过头看 gdb 输出——否则所有“为什么它不抢到锁”的疑问，答案都在编译配置和 POSIX 层，不在 gdb 命令里。
