Arthas的大名想必大家都听过，它是一款线上监控诊断产品，通过全局视角实时查看应用 load、内存、gc、线程的状态信息，并能在不修改应用代码的情况下，对业务问题进行诊断，包括查看方法调用的出入参、异常，监测方法执行耗时，类加载信息等。今天我来重点介绍一下如何使用Arthas分析线程方面问题
死锁问题
死锁问题是经常会遇到的问题，比如说有时候我们发现应用卡住了，很可能是由于某个线程拿住了某个锁，并且其他线程都在等待这把锁造成的。为了排查这类问题，arthas提供了相关功能命令，协助我们快速定位。
对此我们直接使用“thread”命令，输出线程统计信息。其中：BLOCKED表示目前阻塞的线程数，使我们重点观察的保护对象，执行“thread -b”命令相当等同于 " jstack–l| grep -i–E 'BLOCKED | deadlock' ”，找出当前阻塞其他线程的线程，造成死锁的罪魁祸首。
当执行“thread -b”命令后，结果大致会是以下效果：
"Thread-34" Id=93 BLOCKED on java.lang.Object@1820d623 owned by "Thread-36" Id=92
at cn.lhy.test.controller.TestController.lambda$hb$1(TestController.java:65)
- blocked on java.lang.Object@1820d623
- locked java.lang.Object@29064ce5 <---- but blocks 3 other threads!
at cn.lhy.test.controller.TestController$Lambda$1407/395258860.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748)
注：从上面直接输出了造成死锁的线程ID和具体的代码位置以及当前线程一共阻塞的线程数量：“<----but blocks 3 other threads!”，非常的清晰和便利。
CPU负载过高
我们日常的开发过程中，在生产环境或者正式环境中，可能经常会发现CPU过载占用过高的情况，遇到这种问题，一般来讲我们会考虑是线程所引起的，固然采用的是thread命令查看当前线程信息以及线程的堆栈。
CPU使用率是衡量系统繁忙程度的重要指标，一般情况下单纯的CPU高并没有问题，它代表系统正在不断地处理我们的任务，但是如果CPU过高，导致任务处理不过来，从而引起 load 高，这个是非常危险需要关注的。CPU使用率的安全值没有一个标准值，取决于你的系统是计算密集型还是IO密集型，一般计算密集型应用CPU使用率偏高load偏低，IO密集型相反。
CPU负载使用率过高是直接反映你的操作系统忙碌工作程度的关键一个指标，通常情况下单纯的发现CPU使用率过高并不是什么问题，因为这通常代表你的操作系统正在不断地操作处理你的所有任务，不过一旦发现CPU负载过高，这使得你的任务就很可能处理不过来，进而可能导致你的CPU负载过高，这一点是十分危险且必须特别注意的。CPU利用率的安全值并非是一个的固定标准值，而是完全取决于你的系统应用是属于计算密集型还是IO密集型，通常来说计算密集型的系统应用会引起CPU使用率偏高且load值偏低，而IO密集型的系统应用反之。
如果需要定位CPU负载过高的问题，那么首先我们需要定位CPU过高负载是由哪些线程所引起的，比如GC线程、或者应用程序线程等，这时最简单的方法就是通过dashboard看板查询到整个进程中所有线程、内存、GC等情况，例如下图所示。
CPU使用率与Linux中命令top -H -p中对应的线程%CPU类似，统计了当前JVM内各个线程的增量CPU时间与采样时间间隔的比例。
通过以上数据可以分析到哪些线程占用的CPU利用率较高，如果是GC线程占用CPU过多，则需要考虑相关的如何优化GC机制，例如：降低FullGC的频率和时长，以及对象内存的分配大小机制等，具体内容可以参考上一节分析FullGG的内容。如果存在相关的业务代码过多创建线程或者任务过多等原因，需要多考虑对线程池以及相关代码方面的优化。
如果针对具体代码的定位，则采用thread指令导出相关的线程dump文件进行分析，下面是thread的参数选项，借鉴了官方文档的内容，如下图所示。
thread指令参数选项
再次第二次采样，获取所有线程的CPU时间，对比两次采样数据，计算出每个线程的增量CPU时间。
线程负载的CPU使用率 = 线程增量CPU的运行时间/采样线程间隔时间 * 100%
[arthas@35]$ thread -n 3
"arthas-command-execute" Id=24 cpuUsage=70.32% deltaTime=0ms time=36ms RUNNABLE
at java.management@15-ea/sun.management.ThreadImpl.dumpThreads0(Native Method)
at java.management@15-ea/sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:485)
at com.taobao.arthas.core.command.monitor200.ThreadCommand.processTopBusyThreads(
ThreadCommand.java:206)
at com.taobao.arthas.core.command.monitor200.ThreadCommand.process(ThreadCommand.
java:122)
at com.taobao.arthas.core.shell.command.impl.AnnotatedCommandImpl.process(
AnnotatedCommandImpl.java:82)
at com.taobao.arthas.core.shell.command.impl.AnnotatedCommandImpl.access$100
(AnnotatedCommandImpl.java:18)
at com.taobao.arthas.core.shell.command.impl.AnnotatedCommandImpl$
ProcessHandler.handle(AnnotatedCommandImpl.java:111)
at com.taobao.arthas.core.shell.command.impl.AnnotatedCommandImpl$ProcessHandler.
handle(AnnotatedCommandImpl.java:108)
at com.taobao.arthas.core.shell.system.impl.ProcessImpl$CommandProcessTask.
run(ProcessImpl.java:385)
at java.base@15-ea/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask
.run(ScheduledThreadPoolExecutor.java:304)
at java.base@15-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
java:1130)
at java.base@15-ea/java.lang.Thread.run(Thread.java:832)
"C1 CompilerThread0" [Internal] cpuUsage=0.28% deltaTime=0ms time=1032ms
"VM Periodic Task Thread" [Internal] cpuUsage=0.07% deltaTime=0ms time=982ms
"C2 CompilerThread0" [Internal] cpuUsage=0.01% deltaTime=0ms time=1021ms
"Reference Handler" Id=2 cpuUsage=0.0% deltaTime=0ms time=2ms RUNNABLE
at java.base@15-ea/java.lang.ref.Reference.waitForReferencePendingList(Native Method)
at java.base@15-ea/java.lang.ref.Reference.processPendingReferences(Reference.java:241)
at java.base@15-ea/java.lang.ref.Reference$ReferenceHandler.run(Reference.java:213)
从而可以分析出相关的那些CPU负载过高的线程堆栈，以及分析相关的代码问题以及原因。
注意：由于计算统计线程自身就会产生相应的开销，所以会看到的统计线程占了一定的比例，为减少对统计自身的开销所产生的影响，尽量将采样间隔延长一点。