性能优化之CPU占用率高（一）

╰+攻爆jí腚メ 2023-03-02 13:10 102阅读 0赞

[文章部分摘于，点击查看原文][Link 1]

### 当我们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自动机，它将在字符匹配期间执行回溯。我写了一篇文章“ [正则表达式中的隐藏陷阱][Link 2] ”来详细解释原因。
 *  线程上下文切换; 有许多已启动的线程，这些线程的状态在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`，如以下示例所示：

![java-cpu-usage-01.png][]

>  *  `us`：用户空间占用CPU的百分比。简单来说，高我们是由程序引起的。通过分析线程堆栈很容易找到有问题的线程。
>  *  `sy`：内核空间占用CPU的百分比。当sy为高时，如果它是由程序引起的，那么它基本上是由于线程上下文切换。

**由此我们得出结论CPU使用率飙升的两大原因：**

*  无限循环的while会导致CPU使用率飙升
 *  经常使用Young GC会导致CPU占用率飙

**4.为什么cpu飙升到100%但是程序还是可以访问？**

我们可以看到的当前服务器的cpu已经达到了接近400%，为什么会达到400%了，因为我们系统是四核的，每个cpu都飙升到100%，所以看到的是接近400%，但是我继续访问接口，发现还是可以访问，原因是什么呢？因为cpu通过时间片来循环执行任务的，多个任务之间是相关切换的，当切换到我们访问接口的任务时，我们就可以访问了。但是如果继续增加访问达到cpu不能承受的范围内，系统肯定会崩溃。

![20200730115857375.png][]

### 在linux系统下如何排查cpu使用率飙升的原因？ ###

1、使用top命令查看cpu利用率

如下图：

![20200729205846398.png][]

**2、如何查看当前系统的cpu的数量**

由于我们现在的系统都不是单核的，都是多核的，每个核中都由一个cpu，我们可以在使用**top命令后输入1**就可以看到我们当前系统下的cpu的数量。我们可以看到cpu0和cpu1说明系统是双核的。如下图：

![20200729210303748.png][]

我们也可以使用通过proc文件系统，直接获取cpu总数量，具体执行如下命令:**cat /proc/cpuinfo  | grep processor 。**我们可以到由两个processor，说明系统是双核的。如下图：

![20200729210856490.png][]

**3、top命令下各个参数的意思**

top命令的结果分为两个部分：

1.  统计信息：前五行是系统整体的统计信息；
2.  进程信息：统计信息下方类似表格区域显示的是各个进程的详细信息，默认5秒刷新一次。

![20200730102857457.png][]

**统计信息参数介绍**

![20200730104045883.png][]

**进程信息参数介绍**

![20200730104408325.png][]

在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的程序。**

![2020072918461668.png][]

**步骤二：找到最耗CPU的线程**

**输入命令top -Hp 38983，显示一个进程的线程运行信息列表，键入P (大写p)，线程按照CPU使用率排序，我么们可以看到占用cpu最高的线程是39060**

![20200730114747756.png][]

**步骤三：将线程PID转化为16进制**

**输入命令printf “%x” 39060，所以要转化为16进制，是因为堆栈里，线程id是用16进制表示的。**

![20200730114947637.png][]

**步骤四：查看堆栈，找到该线程分析**

**输入命令jstack 38983| grep ‘0x9894’ -C5 --color，打印进程堆栈，通过线程id，过滤得到线程堆栈**

![20200730115156756.png][]

**步骤五：根据提示，修改代码**

![20200730115249805.png][]

**这就证实了while的无限循环会导致CPU使用率飙升。我们在实际开发中要在本地充分的测试，然后再上线，如果线上出现了问题，也不能慌，一定要稳住，要赶紧版本回滚。然后在慢慢排查问题进行修改。**

## ##

[Link 1]: http://www.toutiao.com/i6455611937458749966/?ref=myread
[Link 2]: https://segmentfault.com/a/1190000019282043
[java-cpu-usage-01.png]: /images/20230208/e8058a7c4e93475198333f5d4c77e01c.png
[20200730115857375.png]: /images/20230208/22f47988487e465e96e16c3543d1c66c.png
[20200729205846398.png]: /images/20230208/51436c1619254aad8c92eaf7b52dced8.png
[20200729210303748.png]: /images/20230208/62cd2bed09ef4729b92ff9d2e6bbc4fb.png
[20200729210856490.png]: /images/20230208/52a79c0378cf42ba837543890255adff.png
[20200730102857457.png]: /images/20230208/645d0687e7844846b423b58ae7fec402.png
[20200730104045883.png]: /images/20230208/2f50bb2c365b492b84999afd605b3d4c.png
[20200730104408325.png]: /images/20230208/bca0d4f6d4e74054ad1cb24c7a402831.png
[2020072918461668.png]: /images/20230208/1a6669dacf754fa3a3e5e170fa01a453.png
[20200730114747756.png]: /images/20230208/fe0b6001c5584def83ae4bfa2d2e0663.png
[20200730114947637.png]: /images/20230208/1b68d7b5821544e6ae8ba302aedb9dcc.png
[20200730115156756.png]: /images/20230208/dfee1852cfa0433c953218f233e9c917.png
[20200730115249805.png]: /images/20230208/69a3bbff9a0240649ba0524d04381ff0.png