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

Question

我读到，使用 Tomcat 5.5+ 可以在不重新启动的情况下将战争部署到 Tomcat 服务器。这听起来很棒，但我想我对这个功能及其可靠性太怀疑了。我以前（使用 Websphere）的经验是，最好的做法是重新启动服务器以避免内存问题等。因此，我想获得有关 Tomcat 可能存在哪些陷阱的反馈。

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

Answer 1

一般来说，存在多种类型的泄漏，它们适用于重新部署场景。对于生产系统，如果可能的话最好重新启动，因为当今的应用程序中使用了许多不同的组件和库，很难找到所有这些组件和库，甚至更难修复它们。特别是。如果您无法访问所有源代码。

• 内存泄漏
• 线程和 ThreadLocal 泄漏
• 类加载器泄漏
• 系统资源泄漏
• 连接泄漏

类加载器泄漏会影响重新部署。

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

• 定时器：定时器有线程，并且在运行时创建的线程继承当前上下文类加载器，这意味着Tomcat的WebappClassloader。
• ThreadLocals：ThreadLocals 绑定到线程。应用程序服务器使用线程池。当 ThreadLocal 绑定到线程并且该线程被返回到池中时，如果没有人正确删除（）它，ThreadLocal 将保留在那里。这种情况经常发生，而且很难找到（ThreadLocal 没有名称，除了很少使用的 Spring NamedThreadLocal）。如果 ThreadLocal 持有由 WebappClassloader 加载的类，则会出现 ClassLoader 泄漏。
• 缓存： 例如 EhCache CacheManager
• 反射： JavaBeans Introspector（例如保存类或方法缓存）
• JDBC 驱动程序： 它们不应该位于.war 文件。静态注册表造成的
• 泄漏 缓存 ClassLoaders 的静态库，例如 Commons-Logging LogFactory

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

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

我写了一篇关于 我在进行重新部署压力测试时遇到的泄漏问题 - 尝试“修复”企业级 Java Web 应用程序的所有可能的泄漏。

Answer 2

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

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

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