Tomcat Reload,不得不说的故事
Tomcat Reload,不得不说的故事
作者： kert - Java研究组织
2003-01-15 12:25:55
我们知道在使用Tomcat时，如果设置了reload后，Tomcat会自动侦测WEB-INF目录下修改过的资源。如果发现有变化（通常是依据文件的lastModified值），便会自动重新载入所有的资源。表面上看，似乎是个很好的主意：不用重新启动Tomcat便可以更新我们的Web应。尤其是在调试阶段，只需简单的更新我们的代码，就可以重新测试了。然而美丽的表面总是隐藏着不可测的秘密。
最近在使用Tomcat时，就遇到了一个有趣的问题，简单当时困扰了我很久（也许是因为我比较笨）。到这里和大家分享一下。
我在WebApp应用中有一个daemon 线程，用来定时监视某个状态的改变。如果没有改变就sleep一段时间，否则进行某些相应的处理。类似如下的代码：
public class TestReload{
private static final Logger LOG = Logger.getLogger(CommonReload.class.getName());
private TestReload(){
LOG.info("constructing "+ getClass() + " : " + getClass().hashCode());
new Thread(){
public void run(){
while(true){
work();//相应的处理工作
try{
sleep(10000);
}catch(Throwable t){
};
}
}
}.start();
}
private final static TestReload instance = new TestReload();
}
在Constructor中构造这个线程，每隔10秒钟工作一次
这个类作为某个WebApp中的一个组件，因此最初的入口还是一个Servlet。当我为了debug，而重新编译代码并重新发布我的WebApp后，发现原先生成的线程仍旧在工作，而同时Tomcat也将新编译的代码载入内存，因此这时JVM中有了两个监视的线程在工作，因此会有不可预料的问题。但是这不仅仅是两个独立的工作线程的问题，虽然表面上如此。我修改了一下代码，添加了一个测试用的work方法，如下：
public class TestReload{
......
private void work(){
LOG.info("TestReload "+
TestReload.class.hashCode());
final ClassLoader cl = getClass().getClassLoader();
LOG.info("The class Loader is "
+ cl.getClass().getName()+ " : " + cl.hashCode());
}
}
这里有三行输出信息，用来跟踪一些JVM内部的信息。
LOG.info("TestReload "+TestReload.class.hashCode());
用来输出TestReload的Class的hashCode值。
LOG.info("The class Loader is "_
+ cl.getClass().getName()+ " : " + cl.hashCode())
用来输出加载这个TestClass的Class的ClassLoader的名字和hashCode。
然后用一个简单的Servlet作为程序的入口：
protected void doGet(HttpServletRequest httpServletRequest,
HttpServletResponse httpServletResponse)
throws ServletException, IOException {
Class reload = TestReload.class;
Writer w = httpServletResponse.getWriter();
w.write("working...
");
w.write(reload.getName() +
": " + reload.hashCode());
w.flush();
}
这个Servlet只是简单的要求ClassLoader载入TestClass的Class并且进行Class的初始化和相应的静态初始化。
我们来看一下试验的输出
当WebApp第一次运行时，屏幕输出入下：
......
2002-9-15 16:00:01 kert.reload.TestReload <init>
信息: constructing class kert.reload.TestReload : 2737550
2002-9-15 16:00:01 kert.reload.TestReload work
信息: TestReload 2737550
2002-9-15 16:00:01 kert.reload.TestReload work
信息: The class Loader is org.apache.catalina.loader.WebappClassLoader : 23414511
2002-9-15 16:00:11 kert.reload.TestReload work
信息: TestReload 2737550
2002-9-15 16:00:11 kert.reload.TestReload work
信息: The class Loader is org.apache.catalina.loader.WebappClassLoader
......
2002-9-15 16:01:59 kert.reload.TestReload <init>
信息: constructing class kert.reload.TestReload : 9104244
2002-9-15 16:01:59 kert.reload.TestReload work
信息: TestReload 9104244
2002-9-15 16:01:59 kert.reload.TestReload work
信息: The class Loader is org.apache.catalina.loader.WebappClassLoader : 13754931
2002-9-15 16:02:01 kert.reload.TestReload work
信息: TestReload 2737550
2002-9-15 16:02:01 kert.reload.TestReload work
信息: The class Loader is org.apache.catalina.loader.WebappClassLoader : 23414511
2002-9-15 16:02:09 kert.reload.TestReload work
信息: TestReload 9104244
2002-9-15 16:02:09 kert.reload.TestReload work
信息: The class Loader is org.apache.catalina.loader.WebappClassLoader : 13754931
2002-9-15 16:02:11 kert.reload.TestReload work
信息: TestReload 2737550
2002-9-15 16:02:11 kert.reload.TestReload work
信息: The class Loader is org.apache.catalina.loader.WebappClassLoader : 23414511
......
可以很明显的看到，在Tomcat Reload后JVM中同时存在了两个工作线程。并且不仅仅如此，两个线程输出有着明显的不同。
[*]两个TestReload的Class的hashCode不同，说明JVM内存中存在着两个不同的TestReload的Class的实例。
[*]每个TestReload的Class的对应的ClassLoader也不相同。
照理说，Tomcat Reload在Reload一个WebApp时，应该清除原先的所有载入的数据。包括已生成的对象和相应的Class对象，然后交个GC来处理（回收所有的对象，包括Class对象和ClassLoader）。
但是由于有一个无法终止的线程，Tomcat Reload无法让线程停止，因此也无法回收相应的Class。这样，在先前生成的所有Class都会仍旧保存在内存中。并且与Reload后的Class同名，虽然由于加载的ClassLoader不同，这两组Class是无法互相访问的，因为他们属于不同的Runtime Package。
但是这种状况仍旧会导致很多问题。
[*]重复工作：有多个线程在做同样的工作。
[*]访问限制：由于Runtime Package的限制，原来在编译期互相可见的变量或是方法，在运行期可能无法互相访问。
[*]ClassNotFound：显而易见。
显然，Tomcat Reload并不能像我们想象的那样很够很好的完成我们的工作。虽然这不是Tomcat的错，我猜想在其他的Container中也会有这样的现象发生，如JBoss。Container并不能够终止我们的精灵线程，而我们也无法介入到Container的reload机制中去，如何Reload（remove）我们先前的代码。如果Tomcat在reload之前，在remove旧的代码的时候可以定义一个回调函数，或是有一个Event机制通知我们的应用，那么我们可以采取某些措施。
现在为止，我还没有想到一个比较好的方式来处理这种情况（还是比较笨的缘故）。暂时还是重启Tomcat。或是把这个后台线程做成一个MBean，使用JMX来管理它。如果各位有好解决方法或是相应的Pattern，欢迎回贴。
页:
[1]