快速排查死锁与CPU负载!

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等情况,例如下图所示。

533c430d43571ed3af86a37667b59956.png

CPU使用率与Linux中命令top -H -p中对应的线程%CPU类似,统计了当前JVM内各个线程的增量CPU时间与采样时间间隔的比例。

通过以上数据可以分析到哪些线程占用的CPU利用率较高,如果是GC线程占用CPU过多,则需要考虑相关的如何优化GC机制,例如:降低FullGC的频率和时长,以及对象内存的分配大小机制等,具体内容可以参考上一节分析FullGG的内容。如果存在相关的业务代码过多创建线程或者任务过多等原因,需要多考虑对线程池以及相关代码方面的优化。

如果针对具体代码的定位,则采用thread指令导出相关的线程dump文件进行分析,下面是thread的参数选项,借鉴了官方文档的内容,如下图所示。

6ac7566d71f02cd6aad1e4eaa925307f.png
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负载过高的线程堆栈,以及分析相关的代码问题以及原因。

注意:由于计算统计线程自身就会产生相应的开销,所以会看到的统计线程占了一定的比例,为减少对统计自身的开销所产生的影响,尽量将采样间隔延长一点。

本文章出自北京大学出版社《深入浅出Java虚拟机》一书中,经授权此公号。

199a7a58deb957169b306fd9c68d2453.png

赠书!先到先得!
本次将送出 5本 作为粉丝福利 ,不抽奖,社区积分直接兑换!
兑换地址:http://spring4all.com/4204.html
快来一起来参与社区内容的建设,一起学习一起成长吧!


点击阅读原文,查看更多社区福利!
### 回答1: autosar架构软件CPU load过高是常见的问题之一,它可能会导致设备性能受损,系统崩溃,甚至是安全性问题。快速排查原因可以通过以下步骤: 1. 确认CPU load过高的现象发生的时间和条件,包括何时,何地,何种环境。 2. 关注程序中的所有资源占用,包括主存,中间层,接口等,以及系统外部影响,如网络通信,时间表,CRC校验等等。 3. 检查CPU和核心电路等硬件是否存在故障或者无法正常工作的情况。 4. 采用基于时间的排查,通过记录事件的时间和相关的状态信息来追溯可能引起CPU load高的事件。 5. 使用调试软件进行排查,跟踪并分析对象和系统的运行,以定位可能的问题源并解决它们。同时,通过日志记录,分析产生CPU load高的原因和发生事件的位置。 总之,排查CPU load过高的问题需要有系统的思路和方法,通过分析硬件和软件的影响,以及使用高效的调试软件,来定位问题并解决它们,以确保设备的性能和安全性。 ### 回答2: 当autosar架构软件的CPU负载过高时,需要进行以下步骤来快速排查其原因。 首先,要使用性能分析工具来监控CPU使用率和系统负载。此类工具可突出显示CPU时间、热点和锁定问题,并提供CPU飙升或缺陷的警报。 其次,检查系统中的可用内存和使用的内存量。如有必要,可以通过增加内存或调整内存分配来减少CPU开销。 第三,检查系统中运行的进程和线程。通过检查这些进程和线程,可以确定是否存在紧急的CPU使用情况或死锁情况。 最后,如果以上方法都没有解决问题,可以使用追踪和调试工具进行进一步的调试。追踪工具可以捕捉CPU的使用情况,并记录系统中发生的事件和活动。调试工具可以确定哪些函数或线程在导致高CPU使用率。 总之,要快速排查autosar架构软件的CPU负载过高原因,需要使用性能分析、内存、进程/线程和调试工具来确定问题的根本原因。 ### 回答3: Autosar架构软件是一种高度复杂的软件,在使用中可能会出现CPU负载过高的问题。对于这种情况,我们可以从以下几个方面来进行快速排查。 1、通过软件调试工具查看代码是否存在死循环或者一些不必要的空循环等操作,这些都可能导致CPU过高。 2、可以通过系统监视器对CPU的利用率进行监控,这样可以了解CPU是否存在一个或多个线程的处理量过高导致的问题。 3、检查是否存在大量的IO操作,如读写文件或网络通信等,这些操作会占用CPU时间,导致CPU过高。 4、检查是否存在内存泄漏或者内存过大的情况,如果存在这样的情况,会导致CPU负载过高。 5、查看是否有高频中断的情况,这种情况一般是因为外设设备在短时间内向CPU发送了大量的中断请求,需要检查外设设备是否正常。 总之,对于Autosar架构软件的CPU负载过高问题,我们可以从多个角度去查找原因,只要找到了问题,就可以很快地进行解决。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值