Java 进程 CPU 100% 问题排查

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

@[TOC]

前言

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

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

  1. 首先找出消耗 CPU 最高的进程 PID。
  2. 然后再根据进程 PID 找出进程内消耗 CPU 最高的线程号 TID。
  3. 最后根据线程号 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());
    }
  }

}

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 javajps命令查看 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

将 前面查出的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。


本次分享到此结束啦~~

我是陈皮,一个在互联网 Coding 的 ITer。如果觉得文章对你有帮助,点赞、收藏、关注、评论,您的支持就是我创作最大的动力!

相关文章
|
2月前
|
缓存 JavaScript Java
常见java OOM异常分析排查思路分析
Java虚拟机(JVM)遇到内存不足时会抛出OutOfMemoryError(OOM)异常。常见OOM情况包括:1) **Java堆空间不足**:大量对象未被及时回收或内存泄漏;2) **线程栈空间不足**:递归过深或大量线程创建;3) **方法区溢出**:类信息过多,如CGLib代理类生成过多;4) **本机内存不足**:JNI调用消耗大量内存;5) **GC造成的内存不足**:频繁GC但效果不佳。解决方法包括调整JVM参数(如-Xmx、-Xss)、优化代码及使用高效垃圾回收器。
138 15
常见java OOM异常分析排查思路分析
|
3月前
|
Java 程序员 调度
【JAVA 并发秘籍】进程、线程、协程:揭秘并发编程的终极武器!
【8月更文挑战第25天】本文以问答形式深入探讨了并发编程中的核心概念——进程、线程与协程,并详细介绍了它们在Java中的应用。文章不仅解释了每个概念的基本原理及其差异,还提供了实用的示例代码,帮助读者理解如何在Java环境中实现这些并发机制。无论你是希望提高编程技能的专业开发者,还是准备技术面试的求职者,都能从本文获得有价值的见解。
63 1
|
1月前
|
Java 关系型数据库 MySQL
java控制Windows进程,服务管理器项目
本文介绍了如何使用Java的`Runtime`和`Process`类来控制Windows进程,包括执行命令、读取进程输出和错误流以及等待进程完成,并提供了一个简单的服务管理器项目示例。
30 1
|
1月前
|
运维 监控 Java
使用jps命令查看Java进程
`jps`是Java开发者和系统管理员的得力助手,它简化了Java进程监控的过程,使得快速检查应用运行状态变得轻而易举。通过合理利用其提供的参数,可以高效地进行故障排查、性能监控及日常管理任务,确保Java应用稳定运行。
42 2
|
2月前
|
缓存 JavaScript Java
常见java OOM异常分析排查思路分析
Java虚拟机(JVM)遇到 OutOfMemoryError(OOM)表示内存资源不足。常见OOM情况包括:1) **Java堆空间不足**:内存被大量对象占用且未及时回收,或内存泄漏;解决方法包括调整JVM堆内存大小、优化代码及修复内存泄漏。2) **线程栈空间不足**:单线程栈帧过大或频繁创建线程;可通过优化代码或调整-Xss参数解决。3) **方法区溢出**:运行时生成大量类导致方法区满载;需调整元空间大小或优化类加载机制。4) **本机内存不足**:JNI调用或内存泄漏引起;需检查并优化本机代码。5) **GC造成的内存不足**:频繁GC但效果不佳;需优化JVM参数、代码及垃圾回收器
常见java OOM异常分析排查思路分析
|
3月前
|
小程序 JavaScript Java
【Java】服务CPU占用率100%,教你用jstack排查定位
本文详细讲解如何使用jstack排查定位CPU高占用问题。首先介绍jstack的基本概念:它是诊断Java应用程序线程问题的工具,能生成线程堆栈快照,帮助找出程序中的瓶颈。接着,文章通过具体步骤演示如何使用`top`命令找到高CPU占用的Java进程及线程,再结合`jstack`命令获取堆栈信息并进行分析,最终定位问题代码。
253 1
【Java】服务CPU占用率100%,教你用jstack排查定位
|
3月前
|
消息中间件 算法 Java
深入浅出操作系统:进程管理的艺术掌握Java中的异常处理机制
【8月更文挑战第30天】在数字世界的舞台上,操作系统扮演着导演的角色,精心安排着每一个进程的表演。本文将揭开进程管理的神秘面纱,从进程的诞生到终结,探究它们如何在操作系统的指挥下和谐共舞。通过生动的比喻和直观的代码示例,我们将一同走进操作系统的核心,理解进程调度、同步与通信的内在机制,以及它们对计算生态的重要性。让我们跟随代码的节奏,一起感受操作系统的魅力吧!
|
3月前
|
C# 开发者 数据处理
WPF开发者必备秘籍:深度解析数据网格最佳实践,轻松玩转数据展示与编辑大揭秘!
【8月更文挑战第31天】数据网格控件是WPF应用程序中展示和编辑数据的关键组件,提供排序、筛选等功能,显著提升用户体验。本文探讨WPF中数据网格的最佳实践,通过DevExpress DataGrid示例介绍其集成方法,包括添加引用、定义数据模型及XAML配置。通过遵循数据绑定、性能优化、自定义列等最佳实践,可大幅提升数据处理效率和用户体验。
60 0
|
3月前
|
消息中间件 Java 调度
一次线上服务CPU100%的排查过程
文章记录了一次线上服务CPU使用率达到100%的排查过程,通过使用top命令和jstack工具确定了导致高CPU使用的线程,并分析了Disruptor组件的不当配置是问题原因,通过修改组件的策略成功解决了问题。
53 0
|
8天前
|
安全 Java
java 中 i++ 到底是否线程安全?
本文通过实例探讨了 `i++` 在多线程环境下的线程安全性问题。首先,使用 100 个线程分别执行 10000 次 `i++` 操作,发现最终结果小于预期的 1000000,证明 `i++` 是线程不安全的。接着,介绍了两种解决方法:使用 `synchronized` 关键字加锁和使用 `AtomicInteger` 类。其中,`AtomicInteger` 通过 `CAS` 操作实现了高效的线程安全。最后,通过分析字节码和源码,解释了 `i++` 为何线程不安全以及 `AtomicInteger` 如何保证线程安全。
java 中 i++ 到底是否线程安全?