java应用服务占用cpu过高,如何优化
转载链接:
https://blog.csdn.net/weixin_38007185/article/details/107662386?utm_medium=distribute.pc_relevant_bbs_down.none-task-blog-baidujs-2.nonecase&depth_1-utm_source=distribute.pc_relevant_bbs_down.none-task-blog-baidujs-2.nonecase
当我们cpu使用率高的情况下会出现什么情况?
我们访问程序的速度比较慢,运行时间长。
系统崩溃,无法访问程序。
什么情况会导致Java应用程序的CPU使用率飙升?
解决这个问题之前我们先了解几个知识点:
1.如何计算CPU使用率?
CPU%= 1 - idleTime / sysTime * 100
idleTime:CPU空闲的时间
sysTime:CPU处于用户模式和内核模式的时间总和
2.与CPU使用率有关的是什么?
人们常说,计算密集型程序的CPU密集程度更高。
那么,JAVA应用程序中的哪些操作更加CPU密集?
以下列出了常见的CPU密集型操作:
频繁的GC; 如果访问量很高,可能会导致频繁的GC甚至FGC。当调用量很大时,内存分配将如此之快以至于GC线程将连续执行,这将导致CPU飙升。
序列化和反序列化。稍后将给出一个示例:当程序执行xml解析时,调用量会增加,从而导致CPU变满。
序列化和反序列化;
正则表达式。 我遇到了正则表达式使CPU充满的情况; 原因可能是Java正则表达式使用的引擎实现是NFA自动机,它将在字符匹配期间执行回溯。我写了一篇文章“ 正则表达式中的隐藏陷阱 ”来详细解释原因。
线程上下文切换; 有许多已启动的线程,这些线程的状态在Blocked(锁定等待,IO等待等)和Running之间发生变化。当锁争用激烈时,这种情况很容易发生。
有些线程正在执行非阻塞操作,例如while (true)语句。如果在程序中计算需要很长时间,则可以使线程休眠。
无限循环的while会导致CPU使用率飙升
经常使用Young GC会导致CPU占用率飙升
3. CPU是否与进程和线程相关?
现在,分时操作系统使用循环方式为进程调度分配时间片。如果进程正在等待或阻塞,那么它将不会使用CPU资源。线程称为轻量级进程,并共享进程资源。因此,线程调度在CPU中也是分时的。但在Java中,我们使用JVM进行线程调度。因此,通常,线程调度有两种模式:时间共享调度和抢占式调度。
情况1:while的无限循环会导致CPU使用率飙升吗?
是。
首先,无限循环将调用CPU寄存器进行计数,此操作将占用CPU资源。那么,如果线程始终处于无限循环状态,CPU是否会切换线程?
除非操作系统时间片到期,否则无限循环不会放弃占用的CPU资源,并且无限循环将继续向系统请求时间片,直到系统没有空闲时间来执行任何其他操作。
情况2:频繁的Young GC会导致CPU占用率飙升吗?
是。
Young GC本身就是JVM用于垃圾收集的操作,它需要计算内存和调用寄存器。因此,频繁的Young GC必须占用CPU资源。
让我们来看一个现实世界的案例。for循环从数据库中查询数据集合,然后再次封装新的数据集合。如果内存不足以存储,JVM将回收不再使用的数据。因此,如果所需的存储空间很大,您可能会收到CPU使用率警报。
情况3:具有大量线程的应用程序的CPU使用率是否较高?
不是。
如果通过jstack检查系统线程状态时线程总数很大,但处于Runnable和Running状态的线程数不多,则CPU使用率不一定很高。
我遇到过这样一种情况:系统线程的数量是1000+,其中超过900个线程处于BLOCKED和WAITING状态。该线程占用很少的CPU。
但是大多数情况下,如果线程数很大,那么常见的原因是大量线程处于BLOCKED和WAITING状态。
情况4:对于CPU占用率高的应用程序,线程数是否较大?
不是。
高CPU使用率的关键因素是计算密集型操作。如果一个线程中有大量计算,则CPU使用率也可能很高。这也是数据脚本任务需要在大规模集群上运行的原因。
情况5.处于BLOCKED状态的线程是否会导致CPU占用率飙升?
不会。
CPU使用率的飙升更多是由于上下文切换或过多的可运行状态线程。处于阻塞状态的线程不一定会导致CPU使用率上升。
情况6.如果分时操作系统中CPU的值us或sy值很高,这意味着什么?
您可以使用命令查找CPU的值us和sy值top,如以下示例所示:
us:用户空间占用CPU的百分比。简单来说,高我们是由程序引起的。通过分析线程堆栈很容易找到有问题的线程。
sy:内核空间占用CPU的百分比。当sy为高时,如果它是由程序引起的,那么它基本上是由于线程上下文切换。
由此我们得出结论CPU使用率飙升的两大原因:
无限循环的while会导致CPU使用率飙升
经常使用Young GC会导致CPU占用率飙
4.为什么cpu飙升到100%但是程序还是可以访问?
我们可以看到的当前服务器的cpu已经达到了接近400%,为什么会达到400%了,因为我们系统是四核的,每个cpu都飙升到100%,所以看到的是接近400%,但是我继续访问接口,发现还是可以访问,原因是什么呢?因为cpu通过时间片来循环执行任务的,多个任务之间是相关切换的,当切换到我们访问接口的任务时,我们就可以访问了。但是如果继续增加访问达到cpu不能承受的范围内,系统肯定会崩溃。
在linux系统下如何排查cpu使用率飙升的原因?
1、使用top命令查看cpu利用率
如下图:
2、如何查看当前系统的cpu的数量
由于我们现在的系统都不是单核的,都是多核的,每个核中都由一个cpu,我们可以在使用top命令后输入1就可以看到我们当前系统下的cpu的数量。我们可以看到cpu0和cpu1说明系统是双核的。如下图:
我们也可以使用通过proc文件系统,直接获取cpu总数量,具体执行如下命令:cat /proc/cpuinfo | grep processor 。我们可以到由两个processor,说明系统是双核的。如下图:
3、top命令下各个参数的意思
top命令的结果分为两个部分:
统计信息:前五行是系统整体的统计信息;
进程信息:统计信息下方类似表格区域显示的是各个进程的详细信息,默认5秒刷新一次。
统计信息参数介绍
进程信息参数介绍
在top命令中按f按可以查看显示的列信息,按对应字母来开启/关闭列,大写字母表示开启,小写字母表示关闭。带*号的是默认列。
A: PID = (Process Id) 进程Id;
E: USER = (User Name) 进程所有者的用户名;
H: PR = (Priority) 优先级
I: NI = (Nice value) nice值。负值表示高优先级,正值表示低优先级
O: VIRT = (Virtual Image (kb)) 进程使用的虚拟内存总量,单位kb。
VIRT=SWAP+RES
Q: RES = (Resident size (kb)) 进程使用的、未被换出的物理内存大小,单位kb。
RES=CODE+DATA
T: SHR = (Shared Mem size (kb)) 共享内存大小,单位kb
W: S = (Process Status) 进程状态。D=不可中断的睡眠状态,R=运行,S=睡眠,T=跟踪/停止,Z=僵尸进程
K: %CPU = (CPU usage) 上次更新到现在的时间CPU占用百分比
N: %MEM = (Memory usage (RES)) 进程使用的物理内存百分比
M: TIME+ = (CPU Time, hundredths) 进程使用的CPU时间总计,单位1/100秒
b: PPID = (Parent Process Pid) 父进程Id
c: RUSER = (Real user name)
d: UID = (User Id) 进程所有者的用户id
f: GROUP = (Group Name) 进程所有者的组名
g: TTY = (Controlling Tty) 启动进程的终端名。不是从终端启动的进程则显示为 ?
j: P = (Last used cpu (SMP)) 最后使用的CPU,仅在多CPU环境下有意义
p: SWAP = (Swapped size (kb)) 进程使用的虚拟内存中,被换出的大小,单位kb
l: TIME = (CPU Time) 进程使用的CPU时间总计,单位秒
r: CODE = (Code size (kb)) 可执行代码占用的物理内存大小,单位kb
s: DATA = (Data+Stack size (kb)) 可执行代码以外的部分(数据段+栈)占用的物理内存大小,单位kb
u: nFLT = (Page Fault count) 页面错误次数
v: nDRT = (Dirty Pages count) 最后一次写入到现在,被修改过的页面数
y: WCHAN = (Sleeping in Function) 若该进程在睡眠,则显示睡眠中的系统函数名
z: Flags = (Task Flags)任务标志,参考 sched.h
步骤一、找到最耗CPU的进程
执行top -c ,显示进程运行信息列表,键入P (大写p),进程按照CPU使用率排序,我们可以看到的当前服务器的cpu已经达到了接近400%,记录PID为38983的进程号,也可以看到是一个java的程序。
步骤二:找到最耗CPU的线程
输入命令top -Hp 38983,显示一个进程的线程运行信息列表,键入P (大写p),线程按照CPU使用率排序,我么们可以看到占用cpu最高的线程是39060
步骤三:将线程PID转化为16进制
输入命令printf “%x” 39060,所以要转化为16进制,是因为堆栈里,线程id是用16进制表示的。
步骤四:查看堆栈,找到该线程分析
输入命令jstack 38983| grep ‘0x9894’ -C5 --color,打印进程堆栈,通过线程id,过滤得到线程堆栈
步骤五:根据提示,修改代码
这就证实了while的无限循环会导致CPU使用率飙升。我们在实际开发中要在本地充分的测试,然后再上线,如果线上出现了问题,也不能慌,一定要稳住,要赶紧版本回滚。然后在慢慢排查问题进行修改。