前言
在最近的一次项目更新后，系统会在不确定的场景下出现超级卡顿的情况，打开服务器会发现CPU已经卡爆，重启数次之后依旧会出现卡顿的现象，再不找原因很有可能就要提桶跑路了。
这个项目是一个比较成熟的产品了，现在基本就是根据客户需求进行小打小闹的修改，所以就让两个刚毕业不久的同学负责，卡顿的情况出现好几次，服务器反复重启n次之后他们和我说了这个问题，经过我的一通小操作，成功拿下这两个小迷弟，有没有需要的，打包送走。
接下来就通过下面这个小示例给大家演示一下这个定位的过程。
测试代码
首先新建一个demo，用于演示这种CPU爆满的情况，代码也非常简单，就是一个while死循环，无限打印一段日志。
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
/**
* @author ：huage
* @date ：Created in 2021/10/25
* @description： 测试范例
*/
@Slf4j
@RestController
public class DemoController2 {
@RequestMapping("test")
public void testHashMap(){
while (true){
log.info("花哥你最棒");
}
}
}
打包部署
用idea打包也是非常方便，直接点击package就能搞定，这里花哥使用的是jar包方式打包。
打包阶段，花哥分享两个常用脚本（启动/停止脚本），想动手部署的小伙伴肯定可以用到。
- 启动脚本
export NAME=jar名称.jar
export CLASSPATH=.:jar包路径/:${NAME}
export JAVA_OPS="-server -DappName=程序名称（对应停止脚本中名称）"
echo ${CLASSPATH}
nohup java ${JAVA_OPS} -cp ${CLASSPATH} org.springframework.boot.loader.JarLauncher >/dev/null 2>&1 &
停止脚本
ps -ef | grep -v grep | grep java | grep 启动脚本中DappName名称 | awk '{print "kill -9 "$2}' | sh
- 启动项目
上述步骤全部完成后，使用./run.sh就可以完成项目的启动，在logs中能够看到启动日志。
确定进程
成功启动后，使用命令top -c查看系统资源的使用情况，不断使用大写P可以进行排序，找到占据CPU最大的进程。从下图中能够看到，当前项目只占据0.7%的cpu，
- 调用test接口
如果调用完死循环test接口呢，调用完测试接口后，项目直接占据了cpu的107.3%，简直卡到爆炸，命令都快不听使唤了，当然也可能是花哥的服务器太辣鸡了。
打开日志，我们可以看到日志在不断刷【花哥你最棒】，因为方便测试，这里使用循环打印日志的方式，在现实项目中，有很多很多隐晦的问题并不会体现在日志中，只能通过其他的手段来确定问题的来源。
查找线程
通过top -c命令可以确定出现问题的进程，接下来就要找到这个进程中是哪个线程出现问题，这个确定也是比较简单的，只需要输入命令：top -Hp PID。比如在本例中输入top -Hp 9828。
9877这个线程暂用87.5%的CPU资源，那就可以确定该线程是有问题的，到目前为止，我们完成了问题线程的定位，接下来是就是要确定该线程在代码中哪个位置了。
定位代码
在jvm中进程快照中线程是以16进制显示，所以我们需要将【9877】这个PID转换成16进制，使用浏览器中在线转换工具，或者命令【printf "%x\n" 9877】都可以转换。
printf "%x\n" PID
本例中转换后的16进制为【2698】，接下来使用jstack命令便可以定位到具体的问题代码，如下图中，最终定位到DemoController的testHashMap方法。
jstack 进程PID | grep 线程16进制 -c 显示行数
总结
定位线上环境问题在工作中非常有用，比如有用户反馈一个问题，你老大丢了一些服务器配置给你，让你定位一下，如果你都不知道该看啥，又不好意思问，是不是也会很尴尬....当然除了工作中的需要，这类问题在面试中也经常会被问到，流利的回答可以让面试官觉得你这小伙不是背面试题的，而是真正的用过，工资也能多拿两百块钱吧。
网友评论