中午11点半收到短信报警，web服务器cpu利用率较高。是Java进程占用的，内部系统访问量很少（300不到）因此服务器出现高的cpu利用率很不正常，日志方面并没太多错误记录，杀掉重启过一会cpu利用率又飙升了，能达到500%
像是陷入某种死循环，有人提到在git上面看到最近新加的一段代码是个不严谨的循环语句，于是搜找那段语句，是个删除文件的语句，类似如：
if (file.exist())
while (file.delete())
xxx
xxx
fi
应该是它了，那么为何无法删除呢？
1. 文件不存在，但代码判断过了，
2. 权限问题，如果账号没权限的话，那就会陷入这个死循环中。
再联想——一周前调试的时候用root启动的tomcat，后来自动部署的时候脚本未能杀掉原有进程，只是再开了个新的，于是就出现了两个tomcat，其中一个以root身份运行过且调用过对应的文件，于是即使后来root的那个进程被杀掉，也产生了实质的影响——其身份运行的进程占用的文件目录权限产生变动。（变成了root），所以别的账号无法删除，进而陷入死循环。
解决：
1.更改代码
2.改回相关文件目录的原有属性
两个坑：
代码的死循环不够严谨
坚决不应该以root身份启动有固定用户的进程（属于误操作，应谨慎）
其他思路：
1.查日志，其实能看到很多删除失败的记录，这个应该留意，才能更好找到原因
2.利用jstat分析jvm状态 ， jstat -gcutil pid(vmid) 间隔（毫秒） 次数，如：
[root@service ~]# jstat -gcutil 14503 1000 4
S0 S1 E O P YGC YGCT FGC FGCT GCT
43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129
43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129
43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129
43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129
这个反映的是gc统计信息，详情参考jstat的使用。
