在不重启的情况下将应用程序部署/重新部署到Tomcat的陷阱

Question

我读到过，使用Tomcat 5.5+可以在不重新启动的情况下将war部署到Tomcat服务器。这听起来很棒，但我想我对这个功能和可靠性太怀疑了。我之前的经验(对于Websphere)是重启服务器以避免内存问题等的最佳实践，所以我想得到关于Tomcat可能存在的陷阱的反馈。

(为了明确我的经验，我为一家大公司开发了5年的java web应用程序，该公司将应用程序开发人员与应用程序服务器工程师分开-我们使用Websphere -所以我自己在运行/配置任何应用程序服务器方面没有太多经验)

Answer 1

通常，有多种类型泄漏，它们适用于重新部署场景。对于生产系统，如果可能的话，最好执行重启，因为在当今的应用程序中使用了如此多的不同组件和库，以至于很难找到所有的组件和库，甚至更难修复它们。Esp。如果你不能访问所有的源代码。

• 内存泄漏
• 线程和ThreadLocal leaks
• ClassLoader泄漏
• 系统资源

泄漏

ClassLoader泄漏就是那些会影响重新部署的漏洞。

它们可以由任何东西引起。真的，我是说所有的事情：

• Timers:计时器具有线程，并且在运行时创建的线程继承当前上下文类加载器，这意味着Tomcat.
• ThreadLocals: ThreadLocals的WebappClassloader被绑定到线程。应用程序服务器使用线程池。当ThreadLocal绑定到线程并将线程返回给池时，如果没有人正确地删除它()，ThreadLocal就会留在那里。这种情况经常发生，而且很难找到(除了很少使用的ThreadLocals NamedThreadLocal之外，Spring没有名字)。如果驱动程序包含由驱动程序加载的类，则会得到一个类驱动程序，例如CacheManager
• Reflection: caches)
• JDBC ThreadLocal Introspector (例如，持有类或方法驱动程序：，它们无论如何都不应该出现在.war文件中。由于缓存通用日志的静态registry
• Static库(如Commons-Logging LogFactory

)造成的泄漏

具体到Tomcat，我的经验如下：

对于具有“干净”库的简单应用程序，它在Tomcat

• Tomcat中工作得很好，尝试非常努力地清理由WebappClassloader加载的类。例如，取消部署webapp时，类的所有静态字段都会设置为null。当代码在取消部署时运行时，这有时会导致NullPointerExceptions，例如，使用Logger

• Tomcat的后台作业有一个侦听器，它可以清理更多的东西。它名为org.apache.catalina.core.JreMemoryLeakPreventionListener，最近提交给了Tomcat6.x

我写了一篇关于my experience with leaks when doing redeployment stresstesting的博客文章--试图“修复”企业级Java Web应用程序的所有可能泄漏。

Answer 2

热部署非常好，因为它通常比启动和关闭服务器快得多。

mhaller写了很多关于避免泄漏的文章。另一个问题是，活动用户的会话在应用程序“重启”后仍然存在。有几件事必须注意，但所有这些都意味着它们的会话必须是可序列化的，然后才能正确地反序列化。如果你有有状态的数据库连接等，这可能会有点棘手，但如果你的代码对数据库hickup是健壮的，那应该不会太糟糕。

还要注意，一些IDE允许在保存修改的源文件时更新WAR中的代码(与应用程序的方式相同)，而不必重新部署。MyEclipse在这方面做得相当好。