电脑cpu为100怎么回事-(电脑cpu总是100怎么办)

电脑cpu为100怎么回事 (电脑cpu总是100怎么办)

前言

在计算机操作系统中，CPU 是时分（time division）的，CPU 不会被同一个线程独占一直使用着，除非是那种非抢占式的。在操作系统中有很多线程，每个线程的运行时间由 CPU 决定，CPU 会分给每个线程一个时间片，时间片是一个极短的时间长度，如果在时间片内，线程一直占有，则认为是 CPU 100% 。CPU 运行速度很快，即主频非常高，除非密集型耗费 CPU 的运算，其它类型任务一般电脑都会在小于时间片的时间内结束。

Java 进程 CPU 100% 的排查步骤，大体上都是差不多的，可能会根据不同场景有些命令稍有区别。

首先找出消耗 CPU 最高的进程 PID。

然后再根据进程 PID 找出进程内消耗 CPU 最高的线程号 TID。

最后根据线程号 TID 找出对应的 Java 线程，进行排查处理。

正常情况下，我们一般将服务部署到 Linux 服务器上的，所以重点讲解在 Linux 服务器上的排查过程。不过考虑到，大多程序员是在 Windows 环境开发，或者有少数服务是部署到 Windows 服务器的，所以 Windows 和 Linux 两种环境都会讲解排查的过程。

测试样例

以下接口会不断循环创建 Person 对象，最终会产生内存溢出。

/**

* @author 陈皮

* @version 1.0

* @description

* @date 2022/4/19

*/

public class ChenPiController {

private final List<Person> persons = new ArrayList<>();

@GetMapping("test")

public void test() {

int i = 1;

while (true) {

persons.add(new Person("张三", i++));

System.out.println(persons.size());

}

}

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

电脑

16

17

18

19

20

Windows 环境排查

首先找出消耗 CPU 最高的进程 PID。有两种方式可以查出，一种是通过 Windows 任务管理器，配合 CPU 列和 PID 列找出，CPU 列数字越大，代表消耗 CPU 越高，然后找出镜像名称是 java.exe 的，最后得出 PID。

另外一种方式是使用微软的工具Process Explorer，此软件不仅可以查看进程的情况，还能查看线程的 CPU 占有率，而任务管理器只能看到进程的 CPU 占有率。下载来解压就直接可以使用了。

下载地址：https://docs.microsoft.com/zh-cn/sysinternals/downloads/process-explorer

打开软件后，首先找出 cpu 占用率最高的 Java 进程，如下，进程号 PID 是16356。

然后右击此行数据，选择 Properties 打开，如下：

切换到 Threads 列页面。既可以看到此进程内的线程信息，并且发现 CPU 占用率最高的线程的 TID 是18240，6480，11260，13888，16312 等等。

打开 cmd 命令行工具，通过命令jstack 16356 > d:/16356.stack，将进程的堆栈信息导出到本地 D 盘的 16356.stack 文件中。注意，导出的文件位置随意，文件名一般以进程号+stack后缀组成，当然也可以其他后缀。

上面我们排查到 CPU 占用率最高的线程的 TID 是18240，6480，11260，13888，16312，这些数字是十进制的，而导出的堆栈信息里面的线程 ID 是十六进制的，所以我们需先转换为16进制，即 0x4740，0x1950，0x2bfc，0x3640，0x3fb8。

然后我们打开堆栈文件 16356.stack，在里面查找这些数字，首先是 0x4740，发现定位到我们程序的代码30行，经检测程序，原来是死循环不断的产生 Person 对象，故找到原因所在。

而且通过其他4个线程 ID 0x1950，0x2bfc，0x3640，0x3fb8，在堆栈文件中，发现是 GC 线程的 ID，从而也证明 GC 线程一直忙碌，表示内存不够用了，要进行内存回收，可能是 Java 内存回收不了，所以导致一直 gc，使 CPU 占用率极高。

至此，问题找到原因，原来是在死循环中，不断生产 Person 实例，并且无法回收，不仅工作线程一直占用 cpu，而且导致 gc 线程忙碌进行回收内存，但是回收不了，最后导致内存不足java.lang.OutOfMemoryError。

Linux环境排查

首先使用top命令找出 CPU 占用最高的进程。进程 PID 为 29869 。

再使用ps -ef | grep java或jps命令查看 CPU 占用高的进程是否为 Java 进程。

使用top -H -p pid命令查询此进程的所有线程情况，发现主要有三电脑个线程（PID 为 29871，29872， 29873）CPU占用率高。-H 表示以线程的维度显示，默认以进程维度展示。

使用命令jstack pid > pid.tdump将此进程的线程栈导出到文件，并使用cat命令进行查看。文件后缀名随意，通常以tdump结尾即可。

jstack 29869 > 29869.tdump

cat 29869.tdump

1

2

3

将 前面查出的3个线程 PID 从10进制转为16进制，对应分别为 29871 -> 0x74af，29872 -> 0x74b0，29873 -> 0x74b1。

发现此3个线程中有2个为 gc 线程和1个工作线程。gc 线程忙碌表示内存不够用了，要进行内存回收，但是内存回收不了，导致一直 gc。

使用jstat -gcutil pid命令查看进程的堆情况，发现年轻代中 Eden 和老年代已使用的内存占当前容量百分比很高，并且 GC 频繁。

S0：年轻代中第一个 survivor（幸存区）已使用的占当前容量百分比

S1：年轻代中第二个 survivor（幸存区）已使用的占当前容量百分比

E：年轻代中 Eden 区已使用的占当前容量百分比

O：老年代已使用的占当前容量百分比

M：元数据区使用比例

CCS：压缩使用比例

YGC：从应用程序启动到采样时年轻代中 gc 次数

YGCT：从应用程序启动到采样时年轻代中 gc 所用时间（单位秒）

FGC：从应用程序启动到采样时老年代 full gc 次数

FGCT：从应用程序启动到采样时老年代 full gc 所用时间（单位秒）

GCT：从应用程序启动到采样时 gc 用的总时间（单位秒）

使用jmap -dump:live,format=b,file=pid.hprof 电脑pid命令导出堆文件，只导出 live 存活的对象。文件后缀名可以是任意的，因为它也是二进制的，不过通常以 hprof 结尾。

最后使用 JDK 自带的工具，JAVA_HOME/bin/jvisualvm.exe工具分析快照。

操作路径：文件 -> 装入 -> 文件类型选择堆，选中刚才导出的堆文件。

选择类列表，按照大小排序，找出占用内存最大的类别，发现是 Person 类。

至此，问题找到原因，原来是在死循环中，不断生产 Person 实例，并且无法回收，不仅工作线程一直占用 CPU，而且导致 gc 线程忙碌进行回收内存，但是回收不了，最后导致内存不足java.lang.OutOfMemoryError。

最后简单总结下，上诉的排查过程不一定适用全部场景，不同大体上的思路大同小异。根据自己情况，使用不同的命令和工具进行分析，而且，Java 的 bin 目录下有很多 JVM 性能调优监控工具，如 jps，jstack，jmap，jhat，jstat，hprof。

————————————————

版权声明：本文为CSDN博主「陈皮的JavaLib」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/chenlixiao007/article/details/105999034

电脑 电脑