Java/Tomcat堆大小问题
我不是 Java 开发人员，但我桌上有一个应用程序。它是一个在 Tomcat 容器中运行的 Web 服务服务器端应用程序。用户通过客户端应用程序点击它。
用户不断抱怨它的速度有多慢，并且该应用程序必须每周重新启动两次，导致事情变得非常糟糕。
以前的开发人员告诉我，该应用程序只是耗尽了内存（因为它随着时间的推移加载了更多数据），并最终将所有时间都花在了垃圾收集上。同时，Tomcat 的堆大小设置为 6GB。盒子本身有 32GB RAM。
将堆大小增加到 16GB 有什么坏处吗？
似乎是解决该问题的简单方法，但我不是 Java 专家。
I am not a Java dev, but an app landed on my desk. It's a web-service server-side app that runs in a Tomcat container. The users hit it up from a client application.
The users constantly complain about how slow it is and the app has to be restarted about twice a week, cause things get really bad.
The previous developer told me that the app simply runs out of memory (as it loads more data over time) and eventually spends all its time doing garbage collection. Meanwhile, the Heap Size for Tomcat is set at 6GB. The box itself has 32GB of RAM.
Is there any harm in increasing the Heap Size to 16GB?
Seems like an easy way to fix the issue, but I am no Java expert.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您应该识别泄漏并修复它，而不是添加更多堆空间。那只是一个权宜之计。
您应该配置 tomcat 在错误时转储堆，然后在崩溃后使用任意数量的工具之一分析堆。您可以计算所有类的保留大小，这应该可以让您非常清楚地了解问题所在。
在我的个人资料中，我有一个关于此的博客文章的链接，因为我最近必须这样做。
You should identify the leak and fix it, not add more heap space. Thats just a stop gap.
You should configure tomcat to dump the heap on error, then analyze the heap in one of any number of tools after a crash. You can compute the retained sizes of all the clases, which should give you a very clear picture of what is wrong.
Im my profile I have a link to a blog post about this, since I had to do it recently.
不，将堆大小增加到 16GB 并没有什么坏处。
No, there is no harm in increasing the Heap Size to 16GB.
这看起来像是内存泄漏，是应用程序中的一个严重错误。如果将可用内存量从 6 GiB 增加到 16 GiB，您仍然需要重新启动应用程序，只是频率会降低。一些经验丰富的开发人员应该在运行时查看应用程序堆（查看hvgotcodes提示）并修复应用程序。
This looks like a memory leak, a serious bug in application. If you increase the amount of memory available from 6 to 16 GiB, you're still gonna have to restart the application, only less frequent. Some experienced developer should take a look at the application heap while running (look at hvgotcodes tips) and fix the application.
要解决这些问题，您需要进行性能测试。这包括 CPU 和内存分析。 JDK (6) 捆绑了一个名为 VisualVM 的工具，在我的 Mac OS X 计算机上，默认情况下该工具在路径上为“jvisualvm”。这是免费且捆绑的，因此这是一个起点。
接下来是 NetBeans Profiler (netbeans.org)。这会进行更多内存和 CPU 分析。它也是免费的，但有点复杂。
如果你能花得起钱，我强烈推荐YourKit (http://www.yourkit.com/)。它不是很贵，但它有很多内置诊断功能，可以更轻松地弄清楚发生了什么。
您不能做的一件事是假设仅添加更多内存就能解决问题。如果是泄漏，添加更多内存可能只会使其在重新启动之间的运行时间变得非常糟糕。
To resolve these issues you need to do performance testing. This includes both CPU and memory analysis. The JDK (6) bundles a tool called VisualVM, on my Mac OS X machine this is on the path by default as "jvisualvm". That's free and bundled, so it's a place to start.
Next up is the NetBeans Profiler (netbeans.org). That does more memory and CPU analysis. It's free as well, but a bit more complicated.
If you can spend the money, I highly recommend YourKit (http://www.yourkit.com/). It's not terribly expensive but it has a lot of built-in diagnostics that make it easier to figure out what's going on.
The one thing you can't do is assume that just adding more memory will fix the problem. If it's a leak, adding more memory may just make it run really badly a bit longer between restarts.
我建议您使用 JProfiler、VisualVM、jConsole、YourKit 等分析工具。您可以对应用程序进行堆转储并分析哪些对象正在占用内存。
I suggest you use a profiling tool like JProfiler, VisualVM, jConsole, YourKit etc. You can take a heap dump of your application and analyze which objects are eating up memory.