我们有一个 Java 应用程序一直显示 100% 的 CPU 使用率。当我注意到 top 命令的一些奇怪结果时，我正试图找出是否存在一些主导线程。
如果我运行 top，它会显示 一个 CPU 时间为 100% 的 java 进程。然后我输入 H 来显示线程，它开始显示 几个 Java 线程，每个线程都为 100%。然而，在下一次刷新时，它再次显示了一批 不同 的几个 Java 线程，每个线程都具有 100% 的 CPU。下一次刷新，另一批。这一直持续到几个刷新周期，经历了 100% CPU 的 100 个左右的线程。最后它稳定下来，有十几个 Java 线程，每个线程都有大约 10% 的 CPU 时间。这组“最终”线程与开始时显示 100% CPU 时间的线程相同，但现在它们每个都只有 10%。如果直接运行top -H，我直接就到了final set。
我的直觉是 Java 线程的 100% CPU 有点假。但我就是找不到解释。
我在 Debian Wheezy 机器上。
最佳答案
使用 perl 线程我已经超过 100%，所以我认为 top 绝对不是线程感知的。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19841 v807576 15 0 402m 13m 2184 S 498.7 0.1 9:14.71 mt_analyze_ets
事实并非如此。使用 -H 选项我得到这个:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+COMMAND
18118 v807576 18 0 653m 22m 2164 R 96.3 0.1 0:02.98 mt_analyze_et
18124 v807576 18 0 653m 22m 2164 R 96.3 0.1 0:02.98 mt_analyze_ets
18117 v807576 18 0 653m 22m 2164 R 95.3 0.1 0:02.95 mt_analyze_ets
18121 v807576 18 0 653m 22m 2164 R 94.7 0.1 0:02.93 mt_analyze_ets
18127 v807576 18 0 653m 22m 2164 R 94.3 0.1 0:02.92 mt_analyze_ets
18133 v807576 18 0 653m 22m 2164 R 94.3 0.1 0:02.92 mt_analyze_ets
18136 v807576 18 0 653m 22m 2164 R 94.3 0.1 0:02.92 mt_analyze_ets
18145 v807576 18 0 653m 22m 2164 R 94.0 0.1 0:02.91 mt_analyze_ets
18142 v807576 18 0 653m 22m 2164 R 93.1 0.1 0:02.88 mt_analyze_ets
18130 v807576 18 0 653m 22m 2164 R 92.1 0.1 0:02.85 mt_analyze_ets
18148 v807576 18 0 653m 22m 2164 R 90.8 0.1 0:02.81 mt_analyze_ets
18116 v807576 18 0 653m 22m 2164 S 5.2 0.1 0:00.16 mt_analyze_ets
关于java - 显示线程的 top 命令——这是某种延迟吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17073890/