在生产系统上详细分析 Tomcat 堆
使用 JMX 控制台分析了在 tomcat 中运行的轻负载 Web 应用程序后，发现“PS Old Gen”增长缓慢但持续。 它从 200MB 开始，然后以每小时 80MB 左右的速度增长。
CPU不是问题，它平均运行在0-1%，但在某个地方它会泄漏内存，所以部署后几天会变得不稳定。
我如何找出堆上分配了哪些对象？ 您知道有什么好的教程或工具吗？
Having analyzed a light-load web application running in tomcat, using JMX Console, it turns out the "PS Old Gen" is growing slowly but constant. It starts with 200MB and grows around 80MB/Hour.
CPU is not an issue, it runs at 0-1% on average, but somewhere it leaks memory, so it will become unstable some days after deployment.
How do i find out what objects are allocated on the heap? Are there any good tutorials or tools you know?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您可以尝试 jmap，其中之一JDK 开发工具。 您可以将 jhat 与输出一起使用使用网络浏览器遍历堆转储。
请参阅此答案简短说明解释。
这种情况经常出现，因此搜索这些工具应该会找到一些替代方案。
You could try jmap, one of the JDK Development Tools. You can use jhat with the output to walk heap dumps using your web browser.
See this answer for a short explanation.
This comes up quite often, so searching SO for those tools should turn up some alternatives.
我使用了 来自 IBM alphaWorks 的 HeapAnalyzer 工具，并取得了良好的成功。 它从 Java 的堆配置文件 hprof 中获取输出，并对其进行分析以显示最有可能的内存泄漏。
I've used the HeapAnalyzer tool from IBM's alphaWorks with good success. It takes output from Java's heap profile, hprof, and analyzes it to show you the most likely memory leaks.
您可以使用 NetBeans 分析器。 它有 2 种模式，直接从 ide（对于本地主机）启动配置文件的 tomcat，或者使用提供的 JAR 和服务器上的一些运行配置进行远程配置文件。
我在一个项目中使用它来解决内存泄漏，它很有用。
You can use NetBeans profiler. It has 2 modes, launching tomcat profiled directly from ide (for localhost) or using a remote profiling with a JAR provided and some run config on server.
I used it in a project for a memory leak and it was useful.
请参阅我的答案：
诊断 Java 内存问题的策略< /a>
这里还有一些提示：
我怎样才能弄清楚未释放的对象持有什么？
See my answer here:
Strategies for the diagnosis of Java memory issues
And there are also tips here:
How can I figure out what is holding on to unfreed objects?
你所看到的都是正常的，除非你能证明不是这样。
当旧空间发生GC时额外的“消耗空间”消失时，您不需要分析堆。
在某些时候，当使用的空间达到最大堆大小时，您将观察到由您使用的默认 GC 引起的暂停，之后使用的内存应该会下降很多。 只有当 GC 之后它没有停止时，您可能会对仍然保留这些对象的内容感兴趣。
What you are seeing is normal, unless you can prove otherwise.
You do not need to analyze the heap when the additional "consumed space" disappears when a GC in the old space happens.
At some point, when the used space reaches your maximum heap size you will observe a pause caused by the default GC you use and afterwards the used memory should go down a lot. Only if it does not go down after a GC you might be interested what is still holding onto those objects.
JRockit Mission Control 可以在连接到 JVM 时分析内存泄漏。 无需一直拍摄快照。 如果您的服务器有很大的堆，这会很有用。
只需将该工具连接到 JVM，它就会为您提供一个趋势表，您可以在其中查看增长最快的对象类型，然后您可以探索对这些对象的引用。 您还可以在 JVM 运行时获取分配跟踪，以便您可以查看对象在应用程序中的分配位置。
您可以在此处免费下载
JRockit Mission Control can analyze memory leaks while connected to JVM. No need to take snapshots all the time. This can be useful if you have a server with a large heap.
Just hook the tool up to the JVM and it will give you a trend table where you can see which type of objects that are growing the most, and then you can explore references to those objects. You can also get allocations traces, while the JVM is running, so you can see where in the application the objects are allocated.
You can download it here for free