我有一个似乎是死锁的进程。
# strace -p 5075
Process 5075 attached - interrupt to quit
futex(0x419cf9d0, FUTEX_WAIT, 5095, NULL
它坐在 "futex "系统调用上 似乎在无限期地等待锁。 当运行 "top "时，该进程消耗了大量的CPU。
# top -b -n 1
top - 23:13:18 up 113 days, 4:19, 1 user, load average: 1.69, 1.74, 1.72
Tasks: 269 total, 1 running, 268 sleeping, 0 stopped, 0 zombie
Cpu(s): 8.1%us, 0.1%sy, 0.0%ni, 91.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 12165696k total, 3810476k used, 8355220k free, 29440k buffers
Swap: 8388600k total, 43312k used, 8345288k free, 879988k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5075 omdb 18 0 2373m 1.7g 26m S 199.7 14.9 102804:11 java
进程也被显示在 "S"--睡眠状态，如果它在等待某些资源，这是有道理的。 但是，我不明白，如果进程处于睡眠状态，为什么CPU利用率会接近200%？ 为什么top会报告一个睡眠进程的CPU利用率这么高？ 它的CPU利用率不是应该为零吗？
CPU的使用量与报告的CPU使用量之间没有关联性。top 和处理状态。的 人页 说(重音 我的）。)
%CPU -- CPU使用情况
任务占CPU消耗时间的比例。自上次屏幕更新后，以占总CPU时间的百分比表示。
所以，自从上次屏幕更新后，你的进程确实使用了大量的处理器时间。是的，它在睡觉，但那是因为当前运行的进程是 top 本身（这是有道理的，因为它目前正在更新屏幕）。
您的应用程序是否会分叉子进程？strace输出可能表明主进程只是在等待子进程完成工作。如果是这样，您可以尝试运行
strace -f -p 5075
来跟踪子进程。
该 top 的输出是完全正常的。
负载平均计算包括正在等待的进程（mutexesfutexes，IO等）以及实际使用CPU的进程。 测试一下，比如，运行类似:
dd if=/dev/sda of=/dev/null
然后观察顶部输出，看看会发生什么 它会使负载平均增加1。
如果你看这一行。
Cpu(s): 8.1%us, 0.1%sy, 0.0%ni, 91.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
"91. 8%id "中的 "id "表示 "空闲" 所以CPU其实根本没做什么。
让我补充一下我的两点意见。
顶部显示的是进程在某一特定时刻的状态。
但它并不意味着这个进程在之前的所有时间都处于这个状态。
这个建议是完全错误的。
这个过程可以在R和S状态之间切换一百万次，从以前的top时间到现在的top时刻。
所以如果进程在R和S状态之间快速切换，你可以很容易地在S状态下抓住它。
但是，它在切换之间使用了cpu时间，所以请感受一下cpu_usage这个东西（它描述的是一段时间）和state这个东西（它描述的是一个特定的时间段）的区别。
所以，请感受一下cpu_usage的事情（它描述的是一段时间）和state的事情（它描述的是一个特定的时刻）之间的区别。
让我举一个清楚的例子。
有人在过去的10分钟内从你的口袋里偷了3个苹果。
但是现在它并没有从你的口袋里偷苹果。
被偷的苹果 = cpu_usage,这个人现在没有偷苹果的事实 = 进程状态。
所以其完全错误的得到一个特征并试图预测另一个特征。
希望对你有帮助