假设您的 Java 程序占用了 100% 的 CPU。它有 50 个线程。你需要找出哪个线程是有罪的。我还没有找到可以提供帮助的工具。目前我使用以下非常耗时的例程：
jstack <pid>，其中 pid 是 Java 进程的进程 ID。找到它的简单方法是运行 JDK 中包含的另一个实用程序 - jps. 最好将 jstack 的输出重定向到文件。或者，您可以附加到 Eclipse 中的 Java 进程并尝试一个一个地挂起线程，直到遇到占用 CPU 的线程。在单 CPU 机器上，您可能需要首先降低 Java 进程的优先级才能移动。即使这样，Eclipse 也经常由于超时而无法附加到正在运行的进程。
我本来希望 Sun 的visualvm工具能够做到这一点。
有人知道更好的方法吗？
确定哪个 Java 线程在生产服务器中消耗最多的 CPU。
大多数（如果不是全部）生产系统做任何重要的事情都会使用超过 1 个 java 线程。当某些事情变得疯狂并且您的 cpu 使用率达到 100% 时，很难确定是哪个线程导致了这种情况。或者我是这么想的。直到比我聪明的人向我展示了如何做到这一点。在这里，我将向您展示如何做到这一点，您也可以用您的极客技能让您的家人和朋友惊叹不已。
测试应用程序
为了对此进行测试，我们需要一个测试应用程序。所以我给你一个。它由3个类组成：
HeavyThread执行 CPU 密集型操作（计算 MD5 哈希）的类LightThread做一些不那么密集的CPU（计数和睡眠）的类。StartThreads启动 1 个 cpu 密集型和几个轻线程的类。以下是这些类的代码：
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.UUID;
/**
* thread that does some heavy lifting
*
* @author srasul
*
*/
public class HeavyThread implements Runnable {
private long length;
public HeavyThread(long length) {
this.length = length;
new Thread(this).start();
}
@Override
public void run() {
while (true) {
String data = "";
// make some stuff up
for (int i = 0; i < length; i++) {
data += UUID.randomUUID().toString();
}
MessageDigest digest;
try {
digest = MessageDigest.getInstance("MD5");
} catch (NoSuchAlgorithmException e) {
throw new RuntimeException(e);
}
// hash the data
digest.update(data.getBytes());
}
}
}
import java.util.Random;
/**
* thread that does little work. just count & sleep
*
* @author srasul
*
*/
public class LightThread implements Runnable {
public LightThread() {
new Thread(this).start();
}
@Override
public void run() {
Long l = 0l;
while(true) {
l++;
try {
Thread.sleep(new Random().nextInt(10));
} catch (InterruptedException e) {
e.printStackTrace();
}
if(l == Long.MAX_VALUE) {
l = 0l;
}
}
}
}
/**
* start it all
*
* @author srasul
*
*/
public class StartThreads {
public static void main(String[] args) {
// lets start 1 heavy ...
new HeavyThread(1000);
// ... and 3 light threads
new LightThread();
new LightThread();
new LightThread();
}
}
假设您从未见过此代码，并且您拥有一个运行这些类并消耗 100% CPU 的失控 Java 进程的 PID。
首先让我们开始StartThreads上课。
$ ls
HeavyThread.java LightThread.java StartThreads.java
$ javac *
$ java StartThreads &
在这个阶段，一个正在运行的 Java 进程应该占用 100 个 cpu。在我的顶部，我看到：
在顶部按 Shift-H 打开线程。top 的手册页说：
-H : Threads toggle
Starts top with the last remembered 'H' state reversed. When
this toggle is On, all individual threads will be displayed.
Otherwise, top displays a summation of all threads in a
process.
现在在我的顶部，线程显示打开，我看到：
我有一个javaPID 进程28294。让我们使用以下方法获取此进程的堆栈转储jstack：
$ jstack 28924
2010-11-18 13:05:41
Full thread dump Java HotSpot(TM) 64-Bit Server VM (17.0-b16 mixed mode):
"Attach Listener" daemon prio=10 tid=0x0000000040ecb000 nid=0x7150 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"DestroyJavaVM" prio=10 tid=0x00007f9a98027800 nid=0x70fd waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Thread-3" prio=10 tid=0x00007f9a98025800 nid=0x710d waiting on condition [0x00007f9a9d543000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at LightThread.run(LightThread.java:21)
at java.lang.Thread.run(Thread.java:619)
"Thread-2" prio=10 tid=0x00007f9a98023800 nid=0x710c waiting on condition [0x00007f9a9d644000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at LightThread.run(LightThread.java:21)
at java.lang.Thread.run(Thread.java:619)
"Thread-1" prio=10 tid=0x00007f9a98021800 nid=0x710b waiting on condition [0x00007f9a9d745000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at LightThread.run(LightThread.java:21)
at java.lang.Thread.run(Thread.java:619)
"Thread-0" prio=10 tid=0x00007f9a98020000 nid=0x710a runnable [0x00007f9a9d846000]
java.lang.Thread.State: RUNNABLE
at sun.security.provider.DigestBase.engineReset(DigestBase.java:139)
at sun.security.provider.DigestBase.engineUpdate(DigestBase.java:104)
at java.security.MessageDigest$Delegate.engineUpdate(MessageDigest.java:538)
at java.security.MessageDigest.update(MessageDigest.java:293)
at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:197)
- locked <0x00007f9aa457e400> (a sun.security.provider.SecureRandom)
at sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:257)
- locked <0x00007f9aa457e708> (a java.lang.Object)
at sun.security.provider.NativePRNG$RandomIO.access$200(NativePRNG.java:108)
at sun.security.provider.NativePRNG.engineNextBytes(NativePRNG.java:97)
at java.security.SecureRandom.nextBytes(SecureRandom.java:433)
- locked <0x00007f9aa4582fc8> (a java.security.SecureRandom)
at java.util.UUID.randomUUID(UUID.java:162)
at HeavyThread.run(HeavyThread.java:27)
at java.lang.Thread.run(Thread.java:619)
"Low Memory Detector" daemon prio=10 tid=0x00007f9a98006800 nid=0x7108 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"CompilerThread1" daemon prio=10 tid=0x00007f9a98004000 nid=0x7107 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"CompilerThread0" daemon prio=10 tid=0x00007f9a98001000 nid=0x7106 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" daemon prio=10 tid=0x0000000040de4000 nid=0x7105 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" daemon prio=10 tid=0x0000000040dc4800 nid=0x7104 in Object.wait() [0x00007f9a97ffe000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00007f9aa45506b0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
- locked <0x00007f9aa45506b0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=10 tid=0x0000000040dbd000 nid=0x7103 in Object.wait() [0x00007f9a9de92000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00007f9aa4550318> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:485)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x00007f9aa4550318> (a java.lang.ref.Reference$Lock)
"VM Thread" prio=10 tid=0x0000000040db8800 nid=0x7102 runnable
"GC task thread#0 (ParallelGC)" prio=10 tid=0x0000000040d6e800 nid=0x70fe runnable
"GC task thread#1 (ParallelGC)" prio=10 tid=0x0000000040d70800 nid=0x70ff runnable
"GC task thread#2 (ParallelGC)" prio=10 tid=0x0000000040d72000 nid=0x7100 runnable
"GC task thread#3 (ParallelGC)" prio=10 tid=0x0000000040d74000 nid=0x7101 runnable
"VM Periodic Task Thread" prio=10 tid=0x00007f9a98011800 nid=0x7109 waiting on condition
JNI global references: 910
从我的顶部我看到顶部线程的 PID 是28938. 十六进制28938是. 0x710A请注意，在堆栈转储中，每个线程都有一个nid以十六进制显示的。恰好这0x710A就是线程的 id：
"Thread-0" prio=10 tid=0x00007f9a98020000 nid=0x710a runnable [0x00007f9a9d846000]
java.lang.Thread.State: RUNNABLE
at sun.security.provider.DigestBase.engineReset(DigestBase.java:139)
at sun.security.provider.DigestBase.engineUpdate(DigestBase.java:104)
at java.security.MessageDigest$Delegate.engineUpdate(MessageDigest.java:538)
at java.security.MessageDigest.update(MessageDigest.java:293)
at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:197)
- locked <0x00007f9aa457e400> (a sun.security.provider.SecureRandom)
at sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:257)
- locked <0x00007f9aa457e708> (a java.lang.Object)
at sun.security.provider.NativePRNG$RandomIO.access$200(NativePRNG.java:108)
at sun.security.provider.NativePRNG.engineNextBytes(NativePRNG.java:97)
at java.security.SecureRandom.nextBytes(SecureRandom.java:433)
- locked <0x00007f9aa4582fc8> (a java.security.SecureRandom)
at java.util.UUID.randomUUID(UUID.java:162)
at HeavyThread.run(HeavyThread.java:27)
at java.lang.Thread.run(Thread.java:619)
因此，您可以确认运行HeavyThread该类的线程正在消耗最多的 CPU。
在读取世界的情况下，可能是一堆线程消耗了一部分 CPU，这些线程放在一起将导致 Java 进程使用 100% 的 CPU。
概括
jvmtop可以向您显示消耗最多的线程：
TID NAME STATE CPU TOTALCPU
25 http-8080-Processor13 RUNNABLE 4.55% 1.60%
128022 RMI TCP Connection(18)-10.101. RUNNABLE 1.82% 0.02%
36578 http-8080-Processor164 RUNNABLE 0.91% 2.35%
128026 JMX server connection timeout TIMED_WAITING 0.00% 0.00%
尝试查看用于可视 VM 的 Hot Thread Detector 插件——它使用 ThreadMXBean API 获取多个 CPU 消耗样本以查找最活跃的线程。它基于Bruce Chapman 的命令行等价物， 它也可能有用。
只需运行 JVisualVM，连接到您的应用程序并使用线程视图。持续活跃的那个是你最有可能的罪魁祸首。
查看 JConsole 的Top Threads插件。
如果您在 Windows 下运行，请尝试Process Explorer。为您的进程打开属性对话框，然后选择线程选项卡。
进行线程转储。等待 10 秒。进行另一个线程转储。再重复一次。检查线程转储并查看哪些线程卡在同一个地方，或处理同一个请求。这是一种手动方式，但通常很有用。
我建议看看阿里巴巴开源的Arthas工具。
它包含一堆有用的命令，可以帮助您调试生产代码：
仪表板示例：
使用ps -eLor top -H -p <pid>，或者如果您需要实时查看和监控，请运行 top（然后 shift H），以获取与 java 进程关联的轻量级进程（LWP aka 线程）。
root@xxx:/# ps -eL
PID LWP TTY TIME CMD
1 1 ? 00:00:00 java
1 7 ? 00:00:01 java
1 8 ? 00:07:52 java
1 9 ? 00:07:52 java
1 10 ? 00:07:51 java
1 11 ? 00:07:52 java
1 12 ? 00:07:52 java
1 13 ? 00:07:51 java
1 14 ? 00:07:51 java
1 15 ? 00:07:53 java
…
1 164 ? 00:00:02 java
1 166 ? 00:00:02 java
1 169 ? 00:00:02 java
注意 LWP=轻量级进程；在 Linux 中，线程与进程相关联，以便在内核中对其进行管理；LWP 与父进程共享文件和其他资源。现在让我们看看最耗时的线程
1 8 ? 00:07:52 java
1 9 ? 00:07:52 java
1 10 ? 00:07:51 java
1 11 ? 00:07:52 java
1 12 ? 00:07:52 java
1 13 ? 00:07:51 java
1 14 ? 00:07:51 java
1 15 ? 00:07:53 java
Jstack是一个打印 Java Stack 的 JDK 实用程序；它打印表单的线程。
熟悉其他很酷的 JDK 工具（jcmd jstat jhat jmap jstack等 — https://docs.oracle.com/javase/8/docs/technotes/tools/unix/）
jstack -l <process id>
堆栈跟踪中的 nid，本机线程 id 是连接到 linux 中的 LWT 的那个（https://gist.github.com/rednaxelafx/843622）
“GC task thread#0 (ParallelGC)” os_prio=0 tid=0x00007fc21801f000 nid=0x8 runnable
nid 以十六进制形式给出；因此，我们在 DEC = 8,9,A, B,C,D,E,F 中将花费最多时间的线程 id 转换为 8,9,10,11,12,13,14,15 十六进制。
（请注意，这个特定的堆栈是从 Docker 容器中的 Java 中获取的，如果为 1 则使用方便的过程）让我们看看具有这个 id 的线程。
“GC task thread#0 (ParallelGC)” os_prio=0 tid=0x00007fc21801f000 nid=0x8 runnable
“GC task thread#1 (ParallelGC)” os_prio=0 tid=0x00007fc218020800 nid=0x9 runnable
“GC task thread#2 (ParallelGC)” os_prio=0 tid=0x00007fc218022800 nid=0xa runnable
“GC task thread#3 (ParallelGC)” os_prio=0 tid=0x00007fc218024000 nid=0xb runnable
“GC task thread#4 (ParallelGC)” os_prio=0 tid=0x00007fc218026000 nid=0xc runnable
“GC task thread#5 (ParallelGC)” os_prio=0 tid=0x00007fc218027800 nid=0xd runnable
“GC task thread#6 (ParallelGC)” os_prio=0 tid=0x00007fc218029800 nid=0xe runnable
“GC task thread#7 (ParallelGC)” os_prio=0 tid=0x00007fc21802b000 nid=0xf runnable
所有 GC 相关的线程；难怪它会占用大量 CPU 时间。但是GC在这里是一个问题。
使用 jstat（不是 jstack ！）实用程序来快速检查 GC。
jstat -gcutil <pid>
这是一种 hacky 方式，但似乎您可以在调试器中启动应用程序，然后暂停所有线程，并查看代码并找出哪个没有阻塞锁或 I/ O调用某种循环。或者这就像你已经尝试过的？
您可以考虑的一个选项是从应用程序中查询您的线程以获得答案。通过ThreadMXBean，您可以从 Java 应用程序中查询线程的 CPU 使用情况，并查询有问题的线程的堆栈跟踪。
ThreadMXBean 选项允许您将这种监控构建到您的实时应用程序中。它的影响可以忽略不计，并且具有明显的优势，您可以让它完全按照您的意愿行事。
如果您怀疑 VisualVM 是一个很好的工具，请尝试一下（因为它会这样做）找出线程只会帮助您了解为什么它会消耗如此多的 CPU。
但是，如果它很明显，我会直接使用分析器来找出你消耗这么多 CPU 的原因。