Tomcat Reload,不得不说的故事

作者：
Wednesday, January 15 2003 12:44 PM

 

我们知道在使用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内部的信息

这里有三行输出信息，用来跟踪一些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...\r\n");
        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 : 23414511

WebApp
我重新编译代码并发布后,Tomcat reload相应的代码后并在此运行这个WebApp：
......
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，欢迎回贴。

下一页【跟踪一些JVM内部的信息】>>