vmstatr高cpu空闲高问题分析

偷偷努力，悄无声息地变强，然后惊艳所有人！哈哈，小伙伴们又来学习啦~今天我将给大家介绍《vmstat r高cpu空闲高，futex/mutex争用分析》，这篇文章主要会讲到等等知识点，不知道大家对其都有多少了解，下面我们就一起来看一吧！当然，非常希望大家能多多评论，给出合理的建议，我们一起学习，一起进步！

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

终于介绍完啦！小伙伴们，这篇关于《vmstatr高cpu空闲高问题分析》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！