转载链接：
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使用率飙升。我们在实际开发中要在本地充分的测试，然后再上线，如果线上出现了问题，也不能慌，一定要稳住，要赶紧版本回滚。然后在慢慢排查问题进行修改。