【发布时间】：2012-05-17 13:14:57
【问题描述】：
假设我有一个部署在 Tomcat 上的大型 Java 应用程序。在几周的过程中，服务器将耗尽内存，应用程序性能下降，服务器需要重新启动。
显然应用程序存在一些内存泄漏需要修复。
我的问题是.. 如果应用程序部署到不同的服务器上，内存利用率会有什么变化吗？
【问题讨论】：
标签： java tomcat memory-leaks jvm
【发布时间】：2012-05-17 13:14:57
【问题描述】：
在内存使用方面可能会有轻微的差异，但只是在 servlet 容器之间的占用空间不同的情况下。您也有轻微机会遇到容器内存泄漏 - 但这是值得怀疑的。
最有可能的问题是您的应用程序存在内存泄漏 - 无论如何，原因比快速修复更重要 - 如果“新”容器恰好持续了一周等，您会怎么做？移动问题很少能解决它...
您需要开始分析应用程序的堆内存，以定位问题的根源。如果您的应用程序因 OOME 而崩溃，您可以将其添加到 JVM 参数中。
-XX:-HeapDumpOnOutOfMemoryError
如果在您手动重新启动容器之前性能只是下降，您应该进入触发定期堆转储的例程。转储时间线通常最有帮助，因为您可以看到哪些对象存储随着时间的推移而增长。
为此，您需要一个堆分析工具：
JHat 或 IBM Heap Analyser 或任何你喜欢的 :)
另请参阅此问题：
Recommendations for a heap analysis tool for Java?
更新：
这可能会有所帮助（原因很明显）：
【讨论】：
-
我以前见过这个 java 选项。堆转储是否存储在文件中，然后在其中一种分析工具中打开？
-
是的，通常带有 .hprof 文件扩展名。不过，学习解释结果是一种艺术形式。
当然，应用服务器提供的服务在内存利用率方面可能会有所不同，并且如果服务器包含自己独特的 VM（即，如果您在一台服务器上使用 J9 或 JRockit，而在另一台服务器上使用 Oracle 的 JVM），那么必然会有差异。一个重要的相关领域是类加载：一些应用服务器在管理方面比其他应用服务器具有更好的行为。在配置更改后热启动应用程序可能会由于某些服务器/VM 组合上的类加载问题而导致严重的内存泄漏。
但是这些都不能真正帮助您处理泄漏的应用程序。是程序在使用内存，而不是服务器，因此更改服务器不会对任何事情产生太大影响。
【讨论】：
-
+1 表示最后一段。更改为不同的 Web 容器不太可能修复 Web 应用的存储泄漏。
-
没错，但至少 Tomcat 7 有更好的内存泄漏检测。 :)
-
"是程序使用内存而不是服务器。"我完全同意，这是完全有道理的。但是.. 应用服务器是否会钩入 JVM 并影响 GC 行为？
-
通常应用服务器提供启动 JVM 的启动脚本，所以是的，这些脚本绝对可以将 GC 配置选项传递给 JVM；另外，正如我所说，一些服务器有自己的 JVM 实现，它们会有不同的整体行为。