1.在一次周末收到部门的反馈，线上机器java进程的cpu会频繁100% 监控系统发了很多报警邮件，于是登录跳板机进行排查解决2.使用top命令查看进程情况

发现每隔个几秒cpu就达到100%左右，报警邮件确实是诚不欺我，java进程有问题

2.于是查看下到底是java进程下的哪个线程造成的cpu频繁100%

使用top -Hp 25567 查看进程下的线程信息

得到线程编号26250

3.查看该线程的栈信息

printf '%x\n' 26250 获取26250的16进制数为668a

jstack25567 |grep -A 30668a 得到该线程栈信息

ContainerBackgroundProcessor[StandardEngine[Catalina]] 这是什么任务，没见过啊，懵了

继续看下面的栈信息有apache.catalina之类的信息(上图没有截全)

我们的java服务是通过war包的形式发布到tomcat里的，想着是不是因为tomcat配置的问题

先网上查一下吧(吃了不了解tomcat底层的亏)

4.根据网上的资料，有一种说法说是因为tomcat的server.xml的reload属性设置为了true，那么reload属性有什么作用呢？

如果这个属性设为true，tomcat服务器在运行状态下会监视在WEB-INF/classes和WEB-INF/lib目录下class文件的改动，如果监测到有class文件被更新的，服务器会自动重新加载Web应用。在开发阶段将reloadable属性设为true，有助于调试，但这样用会加重服务器运行负荷，建议在Web应用的发存阶段将reloadable设为false。

看到这赶紧和其他节点的tomcat配置对比一下，发现其他节点的reload都配置为false，只有这一台有问题了的设置为了true。

什么也不说了修改reload为false进行重启，当然如果真的不是因为reload配置导致cpu频繁100%的话，设置reload为false对系统也是有好处的。

5.修改reload为false进行验证

修改配置重启后果然没有再频繁出现cpu 100%了，至于为什么运行这么久监控系统才发通知邮件呢，后来做监控的小伙伴说是因为他们那边信息采集出了问题，没有发现。

还有一个问题，为什么单单只有这一台reload为false了，真相只有一个，项目扩展节点时，小伙伴使用测试环境的server.xml配置文件，然后改改端口，war路径就给发上去了，这才引出这样的问题

问题总算解决了。。。。。。。。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。