线上java项目cpu突然飙升100%怎么排查？

1、使用top命令 查找到java占用cpu的进程。 2、使用 top -Hp PID 命令查看当前进程中的线程cpu占用情况 top -Hp 32725 找到线程 的PID 33753 3、使用 printf ‘%x’ PID 转化成16进制 得到转化后的值83d9 4、使用jstack 命令 dump线程情况 此时jstack +PID 的PID是java进程的PID 非线程PID jstack 32725 &...

告警正在开会，突然钉钉告警声响个不停，同时市场人员反馈客户在投诉系统登不进了，报504错误。查看钉钉上的告警信息，几台业务服务器节点全部报CPU超过告警阈值，达100%。赶紧从会上下来，SSH登陆服务器，使用 top 命令查看，几个Java进程CPU占用达到180%，190%，这几个Java进程对应同一个业务服务的几个Pod(或容器)。定位使用 docker stats 命令查看本节点容器资源使用...

来源：cnblogs.com/dennyzhangdd/p/11585971.html一、引子对于互联网公司，线上CPU飙升的问题很常见（例如某个活动开始，流量突然飙升时），按照本文的步...

1使用top命令 发现进程pid为2862的java进程cpu占用率很高 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2862 ro

排查CPU高占用： 序号 命令 作用 1 top 根据cpu占用量排序. 2 top -Hp pid; 根据[1]中pid, 查询此进程下各个线程的CPU使用情况. 3 jstack pid; 查看此进程[1]中的pid, 的堆栈状况. 4 printf “%x\n” pid; 把pid[2中cpu最高的pid]转换成为16进制数字. 5. ...

第二步：ps H -eo pid,tid,%cpu |grep 5970 查看进程对应的线程。这里的cn.waycube.property实现类对应433行就是代码出问题的地方。2: ps H -eo pid,tid,%cpu |grep 进程id。第三步：printf ‘0x%x\n’ 20507 获取十六进制线程。参考 https://v.douyin.com/iL4gS6Xm/4:jstack 进程id|grep 16进制线程id -A 20。3：printf ‘0x%x\n’ 线程id。

cpu飙升时的排查方式、生产问题排查方式、面试问题

相比于一大堆复杂的调优过程，本文介绍的排查步骤还是挺简单的，可以帮助各位小伙伴排查一些简单问题，面试官问起来也好过啥也不会（这个 CPU 打满如何排查我被问过好多次......）。

1.  jps（或者使用top命令得到pid） jps(Java Virtual Machine Process Status Tool)是JDK 1.5提供的一个显示当前所有java进程pid的命令。 由此命令可以得到应用的pid为8409 2. top top命令是Linux下常用的性能分析工具，能够实时显示系统中各个进程的资源占用状况，类似于Windows的任务管理器。 t...

1. Full GC次数过多 现象 相对来说，这种情况是最容易出现的，尤其是新功能上线时。对于Full GC较多的情况，其主要有如下两个特征： 线上多个线程的CPU都超过了100%，通过jstack命令可以看到这些线程主要是垃圾回收线程 通过jstat命令监控GC情况，可以看到Full GC次数非常多，并且次数在不断增加 原因 年轻代空间不足 老年代空间不足。 永生代或者元数据空间不足。 Syst...

想起我以前的总结，线上的服务频繁full GC，大概率是短时间频繁并发大流量访问，打满了新生代，新生代打满之后，就分配到老年代，老年代打满了就会进行full GC.。其中full GC的优先级最高，当一次FULL GC完成，再来检查老年代，发现继续打满，又重新进行full GC,垃圾回收线程不断一直抢占CPU，导致CPU使用率达到100%，full GC不断回收，但是效果有限，每次只能回收一部分，又马上打满，导致cpu持续达到100%，以及线程han住，导致大量线程请求无法进行处理，CPU持续100%。

常用命令：jstat、jmap、jstack这些命令可以追加生成到文件中。（所谓的dump文件）jps：查看Java 进程jstat:查看JVM状态信息-GC信息jmap:查看堆信息jstack：查看栈信息jinfo：查看jvm参数和动态修改部分jvm参数top：查看CPU和内存消耗情况，以及进程的运行情况统计。

执行 jstack 进程号 | grep 线程ID 查找某进程下 ,线程ID（jstack堆栈信息中的nid）=0xa的线程状态。也可以使用jmap -heap 进程ID查看一下进程的堆内从是不是要溢出了，特别是老年代内从使用情况一般是达到阈值(具体看垃圾回收器和启动时配置的阈值)就会进程Full GC。例如，printf “%x\n” 线程ID ，打印：16b1，那么在jstack中线程号就是16b1。后续查看线程堆栈信息展示的都是十六进制，为了找到咱们的线程堆栈信息，咱们需要把线程号转成16进制。

以Linux系统为例： ps -ef | grep java 获取进程ID linux下切换到jdk1.8.0_181/bin/，执行以下命令：./jmap -dump:format=b,file=heap.hprof xxx (进程ID) 执行，获取heap.hprof文件，然后下载到桌面。 在Eclipse help -> Eclipse Mar...

1. 查看内存情况 top top pid=18426 占用内存比例很高 2. 导出dump日志 jmap -dump:format=b,file=heap.hprof 18426 当前目录： 3. 下载到本地，使用MAT打开进行分析 设置MAT内存大小： 几种图表现形式： 内存泄露检测： 这里一个名称叫做 king-thread 的线程，持有了超过 99% 的对象，数据被一个 HashMap 所持有。 这个就是内存泄漏的点，因为我代码中对线程进行了标识，所以像阿里等公司的编码规范中

遇到一个有意思的业务。 有两个单列文件，一个500M一个700M，共1.2G，2E个数据，要将这两个单列文件中的数据提取出来去重。 最简单的思路，理论大小为1.2G的数据塞进Set里直接去重，发现程序跑着跑着就跑不动了，用jstat查看，发现原来没有赋予初始化参数，默认的初始化堆内存太小，导致程序跑不动。 [b]于是在启动的时候加上了-Xms3000m -Xmx3000m[/b] ...

最近负责的一个项目上线，运行一段时间后发现对应的进程竟然占用了700%的CPU，导致公司的物理服务器都不堪重负，频繁宕机。那么,针对这类java进程CPU飙升的问题，我们一般要怎么去定位解决呢？