Tomcat Reload,不得不说的故事

wsxxz

　　
　　
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，欢迎回贴。