vmstatr高cpu空闲高，futex争用分析

当vmstat显示运行队列（r）持续偏高但CPU空闲率（%idle）也居高不下时，这并非CPU计算资源不足的假象，而是系统正深陷futex或mutex等同步原语的激烈争用——大量进程在就绪队列中“排队等锁”，尚未获得CPU执行权却已因锁阻塞而频繁进入可中断睡眠（S状态），导致上下文切换激增、延迟毛刺频发、吞吐下降；借助perf record捕获sys_enter_futex事件、pidstat -w观察自愿切换、以及ps查看wchan字段，可精准定位到pthread_mutex_lock、__lll_lock_wait或Go的runtime.futex等锁等待栈，进而揭示全局锁滥用、临界区过长或并发map写等根因，此时优化关键不在扩容CPU，而在收缩锁粒度、分片化设计或引入无锁机制。

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），而不是加核或升频。

今天关于《vmstatr高cpu空闲高，futex争用分析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！