r高但%idle高说明CPU不忙，瓶颈在futex/mutex等同步原语争用；可用perf record -e 'syscalls:sys_enter_futex'和pidstat -w验证，重点看用户进程调用栈是否含pthread_mutex_lock或__lll_lock_wait。
vmstat 显示 r 高但 %idle 也高，说明什么？
这通常不是 CPU 真的忙，而是大量进程在就绪队列里“排队等锁”，还没轮到真正执行。r 是 run queue 长度（可运行但没拿到 CPU 的进程数），%idle 高说明 CPU 空闲时间多——矛盾点恰恰暴露了瓶颈不在 CPU 计算，而在同步原语上，比如 futex_wait 或 mutex 争用。
怎么确认是 futex_wait / mutex 导致的阻塞？
用 perf record -e 'syscalls:sys_enter_futex' -a sleep 10 抓系统级 futex 调用热点；再结合 perf report --no-children 看哪些函数频繁陷入 sys_futex。如果看到大量调用栈含 pthread_mutex_lock、__lll_lock_wait 或 do_futex，基本锁定是用户态 mutex/futex 争用。
- 注意区分：内核线程的
futex_wait（如kthreadd）一般无关，重点看用户进程的调用栈 -
pidstat -w 1可辅助观察cswch/s（自愿上下文切换）是否异常高——futex 等待会触发自愿切换 - 若应用用的是 Go，
runtime.futex或sync.Mutex.lockSlow出现在 perf 栈里，也属同类问题
常见诱因和快速验证点
不是所有 mutex 争用都显性报错，但以下场景极易引发高 r + 高 idle：
- 多个线程反复抢同一把全局
pthread_mutex_t（尤其未设PTHREAD_MUTEX_ADAPTIVE_NP时） - Go 程序中对共享 map 无保护读写，触发
fatal error: concurrent map writes前的隐性锁等待 - C++ 应用用了
std::mutex但临界区过长（比如含网络 I/O 或磁盘操作） - Java 应用中
synchronized方法/块被高频调用，且锁对象是静态或单例
验证方法：临时改用 perf record -e 'sched:sched_switch' -a sleep 5，再 perf script | awk '$4=="R" && $9=="S"' | head -20 查看哪些进程常从 Running 变成 Sleeping —— 若频繁停在 futex_wait_queue_me 或 mutex_lock_common，就是它了。
为什么 top/htop 看不到这些线程的 CPU 占用？
因为它们大部分时间处于 S（interruptible sleep）状态，在内核的 futex 等待队列里挂起，不消耗 CPU 时间片，所以 %CPU 列很低，但 STAT 列会显示 D（uninterruptible）或更常见的 S + +（表示在等待某事件）。ps -eo pid,comm,wchan:20,state,pcpu | grep -E '(futex|mutex)' 能直接看到 wchan 列是否为 futex_wait_queue_me 或 mutex_lock。
这类问题难在表象“不忙”，但实际吞吐掉队、延迟毛刺频发。真正要调的不是 CPU，而是锁粒度、争用路径和唤醒机制——比如把一把大锁拆成 per-bucket 锁，或改用无锁结构（如 ring buffer、RCU），而不是加核或升频。
