前言cpu飙高是很常见的线上问题,这都不会的话,属实有点拉跨 
兄弟萌不用慌,来我教你一套连招
开始先来个项目,整个api,到时候我们请求/cpu/{count}就能手动拉高cpu,机智鬼~ @GetMapping("/cpu/{count}") public long cpuTest(@PathVariable("count") long count) { long number = 0; for (int i = 0; i < count; i++) { number++; } return number; } 打包、上传、启动 
跑起来了,记住这个进程号 14849 我们先top看看正常情况下的cpu使用率 
很合理 模拟线上cpu飙高 我们请求/cpu/{100000000000}接口,把cpu拉起来,同时top观察cpu使用率 
直接干到98%,很nice ok入戏,我们现在线上出问题了,cpu一直很高,老大叫你找找原因,开始支棱起来 其实我们现在已经知道是谁把cpu拉高了,但还不够细,只知道哪个项目出的问题远远不够,我们应该找到罪魁祸首,到底是哪个方法的多少行导致的问题,这才能让老大直呼内行
步骤jps+top 定位应用进程 pidtop -Hp {pid}找到线程tid 将 tid 转换成十六进制 printf “%x/n” {tid} 打印堆栈信息 jstack 过滤出我们想要的
排查进程id已经确定是 14849,下一步我们要找到是哪个线程搞的鬼 
很明显是这个14908搞的鬼 转十六进制 
打印堆栈 
堆栈信息显示是TestController里面的第20行出的幺蛾子,我们进入代码验证 
问题不大 破案 撒花 下载地址: CentOS环境使用NFS远程目录挂载过程介绍 Linux下Hbase安装配置教程 |