一次由Tomcat重新加载引发的血案

曾经终败给现在 2022-08-13 05:58 191阅读 0赞

引言： Tomcat是目前开发中使用非常广泛的Web服务器，其提供了很多优秀和简便易用的功能。我们这里的血案就是由于在部署过程中，不慎而引发的....

1. 问题的出现

在我们的系统后台每日定义会触发一些任务操作，进行一些数据的处理和更新，从上线到现在已经正常运行了将近3个多月了。忽然某一天，发现其数据不对，大量的数据都是被执行了2次某个定时任务A造成的。 查询日志，的确是执行了2次。但是之前为什么是正常的呢？诡异诡异....

环境： Tomcat 6.0.x

2.  血案的发生

由于在生产系统中，数据出现了问题，这个是一个非常严重的事情。于是首先把这个定时任务A先停掉，清理数据。由于数据量比较大，所以就有了焦头烂额的几天修正系统数据的过程。

3.  问题分析

3.1  任务A本身有问题吗？

之前都是正常运行的， 只在最近几天才发生问题。而且基于日志分析，其数据操作是正确的，问题是操作了2遍。

3.2  任务A实现分析

首先怀疑其实现的代码上是否有问题？ 经过分析其是基于Quartz来实现定时任务的，Quartz是老牌的定时框架，不会出现问题。 是否是我们自己使用的方式问题，并只在特定情况下才会出现问题呢？ 经过代码的排查分析，没有问题。

3.3  代码变更记录分析

是否是某个同事无意之前做的什么修改造成的呢？ 经过针对代码变更记录和上线记录的分析，排除这个可能。

4.  系统日志分析

在排除了这个任务A自身问题之后，将目光转移到了环境本身。  部署环境是Tomcat6.  下载了Tomcat日志文件进行分析，逐渐找到了某些蛛丝马迹，从而剥丝抽茧般的发现了问题的原因。

在系统日志中，发现了若干在应用部署过程中的错误信息，这个引起了我的怀疑。是否是由于在部署中的错误造成的呢？

经过排查，确定是部署不慎造成的，而且是由于Tomcat本身的Reloadable特性造成的问题。

5.  问题场景的还原

1.  某位同事由于在修改某个问题，只修改了某几个Class文件，故其将编译后的class文件在服务器上直接进行了替换。

2.   由于Tomcat本身设置了Reloadable的属性，故Tomcat在检测到class文件发生变化之后，对WebApp的应用进行了重新加载：先卸载，再重新加载。

3.   在卸载的过程中，程序出错，卸载失败，原来的应用没有卸载成功，保留在Tomcat的缓存之中。

![SouthEast][]

4.   虽然卸载失败，Tomcat继续加载新的WebApp应用。这里请注意： 新加载的WebApp应用在项目名称之后加了一个2，比如原来的项目名称是AAA, 新的项目名称就是AAA2。 重新定义了一个项目名称哦，我当时就知道，这里就是问题所在。

![SouthEast 1][]

此时，二次加载的Web应用，也由于某些原因失败了。

![SouthEast 2][]

5.  运维的同事，注意到了这些错误信息，由于重新启动了Tomcat，这次Tomcat正常启动了

第一个Web应用正常启动了

![SouthEast 3][]

第二个Web应用也正常启动了，参看日志。

![SouthEast 4][]

6.  于是在我们的Tomcat中就出现了两个一模一样的Web应用，换句话说，就是出现了两个一模一样的定时任务。 这个就是为什么定时任务会被执行2次的原因。

7. 解决以及应对

7.1 不允许动态的在生产系统中，替换class文件

7.2  在系统部署和上线过程中，需要进行日志分析，日志可以告诉我们一切的技术细节和内容。

7.3  将Tomcat的Reloadable设置置为false

<Context path="/helloApp" docBase="helloApp" debug="0" reloadable="false"/>

8.  reloadable参数说明

Context>代表了运行在<Host>上的单个Web应用，一个<Host>可以有多个<Context>元素，每个Web应用必须有唯一的URL路径，这个URL路径在<Context>中的属性path中设定。

<Context>元素的属性:  
**path:**指定访问该Web应用的URL入口。  
**docBase:**指定Web应用的文件路径，可以给定绝对路径，也可以给定相对于<Host>的appBase属性的相对路径，如果Web应用采用开放目录结构，则指定Web应用的根目录，如果Web应用是个war文件，则指定war文件的路径。  
**reloadable:**如果这个属性设为true，tomcat服务器在运行状态下会监视在WEB-INF/classes和WEB-INF/lib目录下class文件的改动，如果监测到有class文件被更新的，服务器会自动重新加载Web应用。  
在开发阶段将reloadable属性设为true，有助于调试servlet和其它的class文件，但这样用加重服务器运行负荷，建议在Web应用的发存阶段将reloadable设为false。

9.  总结

由于一个微小的变化引发的问题，在这之前一直正常。由于动态替代class，引发自动部署；部署失败，导致出现了2个相同的部署包。再次重启，然后2个缓存包都正常启动。 其本质原因是Tomcat在卸载应用的过程中，如果出现异常，则无法继续删除缓存；在重新加载的时候，无法清空已有的缓存，这个才是问题的根源。

我们姑且把这个问题，作为Tomcat的一个bug吧，只在特定情况下才会出现的问题。

[SouthEast]: /images/20220810/3d60a82f0b4a4e7e9efc43bf6c4331a3.png
[SouthEast 1]: /images/20220810/d2a5adaded464bbda87aaae83d6cc564.png
[SouthEast 2]: /images/20220810/3ed6bb656322429b9c4fedd6f46df847.png
[SouthEast 3]: /images/20220810/5e51f91dc78a4b4b938db67590c00633.png
[SouthEast 4]: /images/20220810/7240fa5c034b4d6f86a94b29f6490dc9.png