线上某服务器,阿里云CPU报警飙升到100%,因为业务量并不是很大,平常CPU也都很平稳，
根据直接，第一反应就是某位小哥哥的代码写法出现了问题导致了死循环一直占用CPU。
项目运行环境是Tomcat8,服务直接打成war包丢进去运行的。
话不说说，进入正题，
1、登录进入服务器
ssh …
2、查看进程占用资源
输入命令 top 查看进程占用资源，此处可以看到占用最高的进程，一般CPU这一列都会显示占用超过 100% ，反正盯着占用最高的那个，拿到它的PID
3、查看进程下的线程，进程我们找到了，那么我们要进去看他里面哪个线程在吃着资源
top -H -p 17123 (PID)
4 、找到资源占用最高的 将线程id改成16进制
printf “%x\n” 15568
5、使用jstack查看线程代码运行的位置
jstack 16466(PID) | grep 47f8(线程ID16进制) -A 100
6、定位到死循环那一行的代码,进行代码review查看死循环为什么出现,当然此刻我们找到了问题，第一时间应该先将服务停掉避免不停的吃资源，保证线上业务快速恢复正常运行，然后线下快速解决掉引起一场的问题，测试后，重新上一版服务。
因为当时是生产事故，所以上面的截图是笔者私下模拟的，当时是因为项目有一个算法，需要根据一个具体的数字取出一组符合规则的数字出来，
当时一位同事就写了一个方法，并且while循环去调用，直到拿到满意的结果就跳出循环，
风险就是这个数字是用户输入的，你永远不知道用户会输入什么样的数字，导致这个数字可能永远无法出现合适的结果出来，所以一直在while循环，
后来笔者临时修复了这个bug，就是加了一个计数器，这个计数器初始数字是10万,循环一次减去一个1，也就是如果循环了十万次还没拿到合适的数字就直接跳出，返回友好信息提示用户此次操作失败。
本文章主要内容是排查这种CPU飙升的异常排查方案，不去探讨是否有更好的算法可以解决当时的业务场景~ 谢谢阅读
下面是你在执行以上命令时可能会碰到的问题
1、 Unable to open socket file: target process not responding or HotSpot VM not loaded
网上有人说是tmp的问题
实际此处解决方案 ： jstack后面的进程不是当前用户root，而是tomcat，需要切换到tomcat，执行 su tomcat。
2、This account is currently not available
切换到tomcat用户时，可能会出现这个错误，此刻执行下面命令
cat /etc/passwd | grep tomcat
会发现它这里的shell脚本是 /sbin /nologin
所以 vi /etc/passwd 将 /sbin /nologin 改成 /bin/bash ， 保存退出重新切换到tomcat，就好啦。
