中午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的使用。