cpu 真的飙到270%，一次很好的排查体验

场景： 来自一次真的排查过程，运营经理在dashborad下载一家门店图片，下载了10多分钟（平时基本1分钟搞定的），了解情况后，自己上正式环境看看，首选看的就是cpu，发现该项目所占的cpu已经达到了270%（4核），而且没有下降的趋势，于是看了一下该项目的运行日志，发现打印的确实是图片下载这一环节的信息，自己又开始回想，之前在预发布环境测试过下载100多家门店也没有这么慢，想想发现最近有个紧急需求（就是给下载的图片加水印的步骤，感觉顿时一阵凉凉），好吧，问题已经找出来啦，现在我们也在demo中模拟该情况下怎么定位到问题出在哪里。

1.使用top 查看 进程，确定 PID（哪个项目进程）

2.使用 ps -ef |grep 12524 或者 jps |grep 12524 确定是不是我们的项目

3. 使用 ps -mp 12524 -o THREAD,tid,time (查找tid)

4.确定了tid 为 22971 的线程 ，cpu占用率达到 98.5， 接下来 使用 ：printf "%x\n" tid(将 tid转换成十六进制)

5.jstack pid |grep -A 10  tid(用16进制 转换，-A 表示 打印后10数据)

6.通过上面已经知道是哪个类，哪个方法出了问题，这是我们直接去项目工程中定位到这个方法

（idea  可以使用快捷键  ctr+shift+alt+n）查看方法内容

7.确定有可能是这个循环创建对象的程序有问题，这时可以查到程序的日志，通过

grep  “rows”  日志.log.  既然可以看到 column的值这么大，这时你应该想到是怎么回事啦，赶紧改代码吧。

总结： 就这次的排查过程，让我清楚到了怎么去定位问题。希望大家也能够学会。

无敌TG ， 给小编一个赞吧