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

Question

我已经读过Tomcat 5.5+可以在没有重启的情况下将战争部署到Tomcat服务器。这听起来很棒，但我想我对这个功能太过持怀疑态度，而且它的可靠性。我以前的经验（使用Websphere）是重启服务器以避免内存问题等最佳实践。所以我想得到关于Tomcat可能存在哪些陷阱的反馈。

（为了清楚我的经验，我为一家大型公司开发了java网络应用程序5年，该公司将应用程序开发人员与应用程序服务器工程师分开 - 我们使用了Websphere - 所以我没有很多运行经验/自己配置任何应用服务器）

Answer 1

通常，存在多种类型的泄漏，它们适用于重新部署方案。对于生产系统，如果可能的话，执行重启确实是最好的，因为在今天的应用程序中使用了很多不同的组件和库，很难找到它们，甚至更难修复它们。 ESP。如果您无法访问所有源代码。

• 内存泄漏
• Thread and ThreadLocal泄漏
• ClassLoader泄漏
• 系统资源泄漏
• 连接泄漏

ClassLoader泄漏是重新部署时的漏洞。

它们可能是由一切引起的。真的，我的意思是一切：

• 计时器：计时器具有在运行时创建的线程和线程继承当前的上下文类加载器，这意味着Tomcat的WebappClassloader。
• ThreadLocals： ThreadLocals绑定到线程。应用服务器使用线程池。当ThreadLocal绑定到一个Thread并且Thread被返回给池时，如果没有人正确地删除（）它，ThreadLocal将保留在那里。经常发生并且很难找到（ThreadLocals没有名称，除了很少使用的Spring NamedThreadLocal）。如果ThreadLocal包含WebappClassloader加载的类，则会出现ClassLoader泄漏。
• 缓存，例如EhCache CacheManager
• 反思： JavaBeans Introspector（例如持有Class或Method缓存）
• JDBC驱动程序：无论如何它们不应该在.war文件中。静态注册表导致泄漏
• 缓存ClassLoaders的静态库，例如Commons-Logging LogFactory

特定于Tomcat，我的经验如下：

• 对于带有“干净”库的简单应用程序，它在Tomcat中运行良好
• Tomcat非常努力地清理WebappClassloader加载的类。例如，在取消部署webapp时，所有类的静态字段都设置为null。当在取消部署时运行代码时，这有时会导致NullPointerExceptions，例如，使用Logger的后台工作
• Tomcat有一个监听器可以清理更多东西。它名为org.apache.catalina.core.JreMemoryLeakPreventionListener，最近已提交给Tomcat 6.x

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

Answer 2

热部署非常好，因为它通常比上下移动服务器快得多。

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

另请注意，某些IDE允许在保存修改后的源文件时更新WAR内部的代码（与应用程序相同），而不必重新部署。 MyEclipse相当不错。