Tomcat Reload,不得不说的故事

最新推荐文章于 2024-02-25 19:54:33 发布

cqwf95925

最新推荐文章于 2024-02-25 19:54:33 发布

阅读量303

点赞数

文章标签： java runtime 设计模式

我们知道在使用Tomcat时，如果设置了reload后，Tomcat会自动侦测WEB-INF目录下修改过的资源。如果发现有变化（通常是依据文件的lastModified值），便会自动重新载入所有的资源。表面上看，似乎是个很好的主意：不用重新启动Tomcat便可以更新我们的Web应。尤其是在调试阶段，只需简单的更新我们的代码，就可以重新测试了。然而美丽的表面总是隐藏着不可测的秘密。[/i]
----------------
最近在使用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();}

[i]在Constructor中构造这个线程，每隔10秒钟工作一次[/i]
这个类作为某个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 信息: constructing class kert.reload.TestReload : 27375502002-9-15 16:00:01 kert.reload.TestReload work信息: TestReload 27375502002-9-15 16:00:01 kert.reload.TestReload work信息: The class Loader is org.apache.catalina.loader.WebappClassLoader : 234145112002-9-15 16:00:11 kert.reload.TestReload work信息: TestReload 27375502002-9-15 16:00:11 kert.reload.TestReload work信息: The class Loader is org.apache.catalina.loader.WebappClassLoader : 23414511

我重新编译代码并发布后,Tomcat reload相应的代码后并在此运行这个WebApp：

......2002-9-15 16:01:59 kert.reload.TestReload 信息: constructing class kert.reload.TestReload : 91042442002-9-15 16:01:59 kert.reload.TestReload work信息: TestReload 91042442002-9-15 16:01:59 kert.reload.TestReload work信息: The class Loader is org.apache.catalina.loader.WebappClassLoader : 137549312002-9-15 16:02:01 kert.reload.TestReload work信息: TestReload 27375502002-9-15 16:02:01 kert.reload.TestReload work信息: The class Loader is org.apache.catalina.loader.WebappClassLoader : 234145112002-9-15 16:02:09 kert.reload.TestReload work信息: TestReload 91042442002-9-15 16:02:09 kert.reload.TestReload work信息: The class Loader is org.apache.catalina.loader.WebappClassLoader : 137549312002-9-15 16:02:11 kert.reload.TestReload work信息: TestReload 27375502002-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。

但是这种状况仍旧会导致很多问题。

1.重复工作：有多个线程在做同样的工作。

2.访问限制：由于Runtime Package的限制，原来在编译期互相可见的变量或是方法，在运行期可能无法互相访问。

3.ClassNotFound：显而易见。

......

显然，Tomcat Reload并不能像我们想象的那样很够很好的完成我们的工作。虽然这不是Tomcat的错，我猜想在其他的Container中也会有这样的现象发生，如JBoss。Container并不能够终止我们的精灵线程，而我们也无法介入到Container的reload机制中去，如何Reload（remove)我们先前的代码。如果Tomcat在reload之前，在remove旧的代码的时候可以定义一个回调函数，或是有一个Event机制通知我们的应用，那么我们可以采取某些措施。

现在为止，我还没有想到一个比较好的方式来处理这种情况（还是比较笨的缘故）。暂时还是重启Tomcat。或是把这个后台线程做成一个MBean，使用JMX来管理它。
如果各位有好解决方法或是相应的Pattern，欢迎回贴。
如果各位发现某些错误，更是欢迎“砖头”。
版权声明给作者写信本篇文章对您是否有帮助？投票：是否投票结果： 4 0

评论人：cherami 参与分: 61826 专家分: 970 发表时间: 2002-9-15 下午7:05
呵呵，又多知道了一点东西。谢谢！^_^

评论人：crazycode 参与分: 3 专家分: 0 发表时间: 2003-1-14 下午2:42
你可以用Single设计模式来保证只创建一个实例，再在启动线程时做一下判断，如果已经有线程在运行，中止它，再启动新的线程。

评论人：kert 参与分: 8020 专家分: 180 发表时间: 2003-1-14 下午4:08
呵呵，由于代码是由Tomcat的内置Classloader加载，它们根本不再同一个runtime package中，
因此无法判断。

评论人：quake_wang 参与分: 105 专家分: 30 发表时间: 2003-1-15 上午9:12
你可以把这个daemon线程的类放在Tomcat的classpath下,而不是放在webapp下,这样应该就可以了.

评论人：banq 参与分: 30 专家分: 0 发表时间: 2003-1-15 上午9:51
我不理解的问题是：

servlet一般情况下本质是线程的，你为什么还在其内部直接编制启动一个线程？
我觉得如果你可以在servlet容器外编制一个线程不停的访问servlet
这样可以实现你的目的

评论人：banq 参与分: 30 专家分: 0 发表时间: 2003-1-15 上午10:09
如果一定要在servlet容器内部做，可以借鉴Jive使用java.util.TimerTask

评论人：wuyu 参与分: 12 专家分: 10 发表时间: 2003-2-14 下午4:49
精灵线程start的时候将其hashcode或时间戳记录在一个handle文件中，定期检查这个文件内容是否相符，如果不符则中止线程？

评论人：panwen 参与分: 24 专家分: 0 发表时间: 2003-2-15 下午1:23
我觉得任何线程都应该有一个退出机制，例如:
public void run()
{
while(flag)
{
try
{
work();
Thread.sleep(6000);
}catch(Exception e){}
}
}

在servlet的destroy方法里
设置flag=false就可以让线程退出。

评论人：fridaychen 参与分: 6 专家分: 0 发表时间: 2003-2-18 下午2:09
在tomcat中可以注册ServletContextListener，这是一个标准的机制。

public void contextInitialized(ServletContextEvent sce)；
public void contextDestroyed(ServletContextEvent sce)；

允许程序在系统启动和关闭的时候作一些工作。我把线程的启动和关闭都放在这里了，这样系统在reload的时候，也会调用ServletContextListener的方法。

评论人：wuyu 参与分: 12 专家分: 10 发表时间: 2003-2-18 下午4:20
非常感谢楼上的所有朋友们，特别是fridaychen。

为了测试fridaychen所说的ServletContextListener，我特意做了一个小测试，然后在tomcat4.1.18的/manager/html/list里面stop/start/reload /market这个web app，结果，在tomcat load webApp的时，contextInitialized中的代码被执行，系统开始定时执行继续了java.util.TimerTask的守护线程程序，stop时，contextDestroyed中的代码被执行，所有正在执行的守护线程程序均正常中止。

Tomcat控制台的输出信息
startup init
start
d:wwwwebmarket_version
TimerTask run...
TimerTask run...
TimerTask run...
TimerTask run...
TimerTask run...
TimerTask run...
TimerTask run...
TimerTask run...
TimerTask run...
TimerTask run...
TimerTask run...
TimerTask run...
destory

market.marketListener源代码
package market;

/**
* 侦听器程序测试
*/
public class marketListener implements javax.servlet.ServletContextListener {
private java.util.Timer timer;

public marketListener() {
System.out.println( "startup init" );
timer = new java.util.Timer( true );
}

public void contextDestroyed( javax.servlet.ServletContextEvent event ) {
System.out.println( "destory" );
timer.cancel();
}

public void contextInitialized( javax.servlet.ServletContextEvent event ) {
System.out.println( "start" );
System.out.println( event.getServletContext().getRealPath( "/" ) );
timer.schedule( new java.util.TimerTask() {
public void run() {
System.out.println( "TimerTask run..." );
}
} , 0 , 1000 );
}

}
对web.xml的配置

market.marketListener

评论人：kert 参与分: 8020 专家分: 180 发表时间: 2003-2-18 下午4:27
great solution!
ServletContextListener new feature from Servlet 2.3[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9650775/viewspace-921991/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/9650775/viewspace-921991/