应使用 perf record -e sched:sched_stat_sleep,sched:sched_stat_wait 监测线程真实锁等待时间占比，而非统计 pthread_mutex_lock 调用次数，因其可能瞬时返回或阻塞数十毫秒；调度事件能准确反映锁争抢导致的排队（sched_stat_wait）与阻塞（sched_stat_sleep）耗时，二者之和超总运行时间15%即存在显著锁瓶颈。
直接看 perf record -e sched:sched_stat_sleep,sched:sched_stat_wait,sched:sched_stat_iowait，再配合 perf script 解析线程在锁上“卡住”的真实耗时占比。单纯看 pthread_mutex_lock 调用次数没意义——它可能瞬间返回，也可能阻塞几十毫秒。
为什么不能只统计 mutex_lock 调用次数
很多同学一上来就用 perf record -e syscalls:sys_enter_futex 或者 LD_PRELOAD hook pthread_mutex_lock，然后数调用频次。这会严重误导判断：
-
pthread_mutex_lock在未争抢时是纯用户态原子操作（比如__lll_lock_wait根本不进内核），根本不会触发 futex 系统调用 - 一次锁等待可能对应 100 次
pthread_mutex_lock调用（比如自旋+阻塞混合模式），但真正耗时的是那一次阻塞 - 锁竞争比例关心的是“时间占比”，不是“次数占比”——一个线程在锁上等了 50ms，比另外 100 个线程各调用 1 次锁但都立刻拿到，影响大得多
用 perf 看真实的调度等待时间
Linux 内核的调度事件能告诉你线程到底在哪类等待上花了时间。关键不是“有没有锁”，而是“它被调度器挂起时，原因是不是在等锁”：
-
sched:sched_stat_wait：线程已就绪、但在运行队列里排队等待 CPU 的时间 —— 这部分高，说明锁争抢激烈，大量线程挤在一把锁后面排队 -
sched:sched_stat_sleep：线程主动睡眠（比如pthread_cond_wait）或被阻塞（比如锁争抢失败后进入 futex_wait）的时间 —— 这部分高，说明锁等待本身耗时长 - 两者加起来占总运行时间 >15%，基本可判定存在显著锁瓶颈
实操命令：
perf record -g -e 'sched:sched_stat_sleep,sched:sched_stat_wait' -p $(pidof your_program) sleep 10
perf script | awk '/sched_stat/ {sum += $NF} END {print "lock-wait ratio ≈", sum/10000000, "%"}'
注意：$NF 是最后一列（纳秒级时间），除以 10⁷ 得到占 10 秒采样窗口的百分比。
结合 /proc//stack 看锁在哪一层卡住
当 perf 显示 wait/sleep 时间高，下一步要定位具体是哪把锁、哪个代码路径：
- 对每个线程 ID 执行
cat /proc/<tid>/stack</tid>，找带futex_wait_queue_me或__lll_lock_wait的栈帧 - 如果栈顶是
pthread_mutex_lock→ 锁在用户态竞争，可能是自旋锁或轻量级互斥量 - 如果栈顶是
futex_wait→ 已进入内核等待，说明锁已被持有时长超过自旋阈值（默认约 10 微秒） - 重点看锁变量名或附近代码行号：
mutex_lock(&g_task_queue_mutex)比pthread_mutex_lock(&mtx)更容易反向定位
别忽略 pthread_mutexattr_settype 的影响
同一把 pthread_mutex_t，不同类型会导致完全不同的竞争行为：
-
PTHREAD_MUTEX_NORMAL：不检测死锁，重复 lock 直接崩溃 —— 压测时容易触发 SIGSEGV，掩盖真实锁竞争 -
PTHREAD_MUTEX_ERRORCHECK：每次 lock 都检查，开销大，但能暴露重入问题 -
PTHREAD_MUTEX_ADAPTIVE_NP（Linux 特有）：先自旋再休眠，适合短临界区；但若临界区变长，自旋反而浪费 CPU - 默认类型是
PTHREAD_MUTEX_TIMED_NP，行为最“中性”，但调试时建议显式初始化并设为ERRORCHECK排查误用
检查方式：readelf -Ws your_binary | grep mutex 看是否链接了 libpthread，再确认代码里有没有 pthread_mutexattr_settype 调用。
锁竞争比例不是个静态数字，它随负载、线程数、临界区长度剧烈波动。最危险的情况是：低 QPS 下一切正常，一压测就 wait 时间飙升——那说明你的锁粒度或线程模型已经踩到扩展性天花板了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
