前期准备

先准备一个程序来拉高cpu，这里我们准备了一个springboot项目，在主线程中循环打印日志,代码如下。

public class BeyondStarterApplication extends SpringBootServletInitializer {public static void main(String[] args) {SpringApplication.run(BeyondStarterApplication.class, args);//System.out.println("beyond-cpu-high-test_start_success");while (1>0) {System.out.println("无限执行打印，cpu你怕不怕");}}
}

将上述程序部署到linux服务器上后并启动，之后开始分析。

问题分析

一：使用linux自带命令分析问题

第一步：定位具体哪个进程导致cpu飙升。
使用top命令查看进程占用cpu时间比，这里我们发现pid为30832号进程占用比例非常高，达到了88.9。

第二步：定位该进程下具体哪个线程占用cpu高。
使用top -H -p 30832 #进程号命令查看
将线程pid转换为线程ID
使用命令printf "%x\n" 30850进行转换，得到线程ID

根据进程pid和线程ID获取cpu占用高的线程的具体信息，执行jstack 30832 |grep 7882 -A 20

这里我们可以看到at com.ai.toptea.sysm.BeyondStarterApplication.main(BeyondStarterApplication.java:19)是问题的根源。和我们预期一样，就是我们加入无限打印的地方。

二：使用async-profiler工具分析问题

async-profiler工具下载地址https://github.com/jvm-profiling-tools/async-profiler/releases
下载完成后进入目录执行./profiler.sh -d 30 30832 > profile-java.log命令生成cpu占用情况分析文件，30832为进程pid。
下图为日志，可以看出cpu占用最多的几个都和com.ai.toptea.sysm.BeyondStarterApplication.main类下的print方法相关。

--- Execution profile ---
Total samples       : 2986--- 1788607978 ns (5.99%), 178 samples[ 0] __write[ 1] writeBytes[ 2] Java_java_io_FileOutputStream_writeBytes[ 3] java.io.FileOutputStream.writeBytes[ 4] java.io.FileOutputStream.write[ 5] java.io.BufferedOutputStream.flushBuffer[ 6] java.io.BufferedOutputStream.flush[ 7] java.io.PrintStream.write[ 8] sun.nio.cs.StreamEncoder.writeBytes[ 9] sun.nio.cs.StreamEncoder.implFlushBuffer[10] sun.nio.cs.StreamEncoder.flushBuffer[11] java.io.OutputStreamWriter.flushBuffer[12] java.io.PrintStream.newLine[13] java.io.PrintStream.println[14] com.ai.toptea.sysm.BeyondStarterApplication.main[15] sun.reflect.NativeMethodAccessorImpl.invoke0[16] sun.reflect.NativeMethodAccessorImpl.invoke[17] sun.reflect.DelegatingMethodAccessorImpl.invoke[18] java.lang.reflect.Method.invoke[19] org.springframework.boot.devtools.restart.RestartLauncher.run--- 1703023200 ns (5.70%), 170 samples[ 0] __write[ 1] writeBytes[ 2] Java_java_io_FileOutputStream_writeBytes[ 3] java.io.FileOutputStream.writeBytes[ 4] java.io.FileOutputStream.write[ 5] java.io.BufferedOutputStream.flushBuffer[ 6] java.io.BufferedOutputStream.flush[ 7] java.io.PrintStream.write[ 8] sun.nio.cs.StreamEncoder.writeBytes[ 9] sun.nio.cs.StreamEncoder.implFlushBuffer[10] sun.nio.cs.StreamEncoder.flushBuffer[11] java.io.OutputStreamWriter.flushBuffer[12] java.io.PrintStream.write[13] java.io.PrintStream.print[14] java.io.PrintStream.println[15] com.ai.toptea.sysm.BeyondStarterApplication.main[16] sun.reflect.NativeMethodAccessorImpl.invoke0[17] sun.reflect.NativeMethodAccessorImpl.invoke[18] sun.reflect.DelegatingMethodAccessorImpl.invoke[19] java.lang.reflect.Method.invoke[20] org.springframework.boot.devtools.restart.RestartLauncher.run--- 753612460 ns (2.52%), 76 samples[ 0] sun.nio.cs.StreamEncoder.flushBuffer[ 1] java.io.OutputStreamWriter.flushBuffer[ 2] java.io.PrintStream.write[ 3] java.io.PrintStream.print[ 4] java.io.PrintStream.println[ 5] com.ai.toptea.sysm.BeyondStarterApplication.main[ 6] sun.reflect.NativeMethodAccessorImpl.invoke0[ 7] sun.reflect.NativeMethodAccessorImpl.invoke[ 8] sun.reflect.DelegatingMethodAccessorImpl.invoke[ 9] java.lang.reflect.Method.invoke[10] org.springframework.boot.devtools.restart.RestartLauncher.run--- 748843545 ns (2.51%), 75 samples[ 0] sun.nio.cs.StreamEncoder.flushBuffer[ 1] java.io.OutputStreamWriter.flushBuffer[ 2] java.io.PrintStream.newLine[ 3] java.io.PrintStream.println[ 4] com.ai.toptea.sysm.BeyondStarterApplication.main[ 5] sun.reflect.NativeMethodAccessorImpl.invoke0[ 6] sun.reflect.NativeMethodAccessorImpl.invoke[ 7] sun.reflect.DelegatingMethodAccessorImpl.invoke[ 8] java.lang.reflect.Method.invoke[ 9] org.springframework.boot.devtools.restart.RestartLauncher.run--- 746264901 ns (2.50%), 75 samples[ 0] sun.nio.cs.UTF_8$Encoder.encodeLoop[ 1] java.nio.charset.CharsetEncoder.encode[ 2] sun.nio.cs.StreamEncoder.implWrite[ 3] sun.nio.cs.StreamEncoder.write[ 4] java.io.OutputStreamWriter.write[ 5] java.io.BufferedWriter.flushBuffer[ 6] java.io.PrintStream.newLine[ 7] java.io.PrintStream.println[ 8] com.ai.toptea.sysm.BeyondStarterApplication.main[ 9] sun.reflect.NativeMethodAccessorImpl.invoke0[10] sun.reflect.NativeMethodAccessorImpl.invoke[11] sun.reflect.DelegatingMethodAccessorImpl.invoke[12] java.lang.reflect.Method.invoke[13] org.springframework.boot.devtools.restart.RestartLauncher.run

定位CPU飙升问题点相关推荐

线上频繁发生Full GC 如何调优？如何快速定位OOM、cpu飙升、线程死锁等问题
文章目录 1. jvm调优命令.工具介绍 ①:jps ②:jmap 查看应用中各实例生成情况快速定位内存突然飙升导致的OOM异常查看堆内存使用情况 ③:Jstack 检测线程死锁快速定位导致cp ...
cpu飙升死循环_记一次CPU飙升BUG
一．前言上线后,CPU飙升到100%,怎么办?马上重启?大错特错,马上重启只会让这个雷石沉大海,治标不不治本,等待你的下次的历史重演! 二．现象监控告警,某机器的CPU飙升到100% 三．分析第 ...
记一次CPU飙升的问题分析解决思路(转)
一．前言上线后,CPU飙升到100%,怎么办?马上重启?大错特错,马上重启只会让这个雷石沉大海,治标不不治本,等待你的下次的历史重演! 二．现象监控告警,某机器的CPU飙升到100% 三．分析第 ...
下载丨8月数据库技术通讯：不合理业务设计导致CPU飙升
为了及时共享行业案例,通知共性问题,达成共享和提前预防,我们整理和编辑了<云和恩墨技术通讯>,通过对过去一段时间的知识回顾,故障归纳,以期提供有价值的信息供大家参考.同时,我们也希望能够将 ...
线上服务导致cpu飙升问题排查
一.故障说明昨晚突然收到线上服务器cpu报警,登录监控平台看了下发现cpu瞬间飙升到60%.第一反应就是使用top命令去查看,发现是一个java进程.于是立刻使用jps -l命令定位到该java进程 ...
MySQL数据库CPU飙升到100%解决方案
1.定位cpu问题所在当cpu飙升到100%时,先用操作系统命令top命令观察是不是mysqld占用导致的,如果不是,找出占用高的进程,并进行相关处理. 2.查看慢查询日志进入mysql命令行 m ...
运维告诉我CPU飙升300%,为什么我的程序上线就奔溃了
线上服务CPU飙升的一次经历前言功能开发完成仅仅是项目周期中的第一步,一个完美的项目是在运行期体现的今天我们就来看看笔者之前遇到的一个问题CPU飙升的问题. 代码层面从功能上看没有任何问题但是投 ...
云服务器被植入挖矿木马，CPU飙升200%处理方案
云服务器被植入挖矿木马,CPU飙升200%处理方案 1,通过执行top命令,即可在返回结果中看到当时系统的CPU占用率. top -c 2.检查防火墙iptables规则中是否存在可疑端口 iptab ...
jvm优化—监控工具：诊断内存泄露、cpu飙升、线程死锁、响应变慢
目录一.jvm常见监控工具&指令 JVM常见参数为什么要将永久代 (PermGen) 替换为元空间 (MetaSpace) 呢? 1. jps:jvm进程状况工具 2.jstat: jvm ...
如何定位cpu占用率高的java线程
如何定位cpu占用率高的java线程工具: 1 jstack:jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息,如果是在64位机器上,需要指定选项&q ...

定位CPU飙升问题点