我们有一个 Java 应用程序一直显示 100% 的 CPU 使用率。当我注意到命令的一些奇怪结果时，我试图找出是否有一些主导线程top。
如果我运行top，它会显示一个具有 100% CPU 时间的 java 进程。然后我输入H显示线程，它开始显示几个Java 线程，每个线程 100%。然而，下一次刷新，它再次显示了不同批次的几个 Java 线程，每个线程都具有 100% 的 CPU。下一次刷新，又一批。这种情况一直持续下去，几个刷新周期会经过 100 个左右的 100% CPU 线程。最后，它使用了十几个 Java 线程，每个线程都有大约 10% 的 CPU 时间。这组“最终”线程与在开始时显示 100% CPU 时间但现在每个只有 10% 的线程相同。如果top -H直接跑，我直接进入决赛。
我的直觉是，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