我是 Java 初学者,想知道如何在 NetBeans 中分析此内存配置文件会话以及如何监视它以获取搜索内存泄漏的帮助?
“实时字节”是什么意思?我可以看到,当我对所有活动字节求和时,我只会得到 Java 应用程序系统内存使用的一小部分。
为什么没有有关每个对象类型的分配字节的信息?
“分配对象”的值不断增长是否是内存泄漏的迹象?
这是具有大量并发线程和 http 连接的应用程序。
我检查了线程,它们工作正常 - 我的意思是同时运行的线程不超过 20 个。
我使用 JBOSS Netty 进行 http 连接,使用 jSoup 解析 HTML。
这个内存泄漏是由分配的 ParseError 对象过多引起的吗?或者我应该通过字节创建堆栈跟踪来搜索内存泄漏的原因?
其他资源:
编辑:
我已将 HTML Cleaner 添加到我的项目中。这导致我不再看到任何解析器错误。内存泄漏增长现在大约慢了 3-4 倍。内存使用量达到 800MB 后,应用程序崩溃,我可以在 NetBeans 中查看堆。结果:
注意:我没有在我的应用程序中创建任何 LinkedHashMap,因此它必须由其他库创建。 TagNode 是一个对象,用于保存“HTML Cleaner”清理后清理后的 html。我的应用程序中只有一个 TagNode 对象,它是 netty http 响应处理程序中的局部变量(由 messageReceived 调用)。
I'm begginner in Java and wondering how to analyse this memory profile session in NetBeans and how to watch on it to get assist in searching for memory leak ?
What means "Live bytes" ? I can see that when I sum all live bytes I will get only small part of used by java application system memory.
Why there is no information about allocated bytes of each object type ?
Is continuously growing value of "Allocated Objects" sign of memory leak ?
This is application with lot of concurrent threads and http connections.
I've checked threads and they are working ok - I mean there is no more than 20 threads simutaneously.
I've used JBOSS Netty for http connection and jSoup for parsing HTML.
Is this memory leak caused by too many allocated ParseError objects ? or I should serach for reason of memory leak with byte creation stack trace ?
Additional resources:
EDIT:
I've added to my project HTML Cleaner. This cause that i don't see any parser errors anymore. Memory leak growth now about 3-4 times slower. After reaching 800MB of memory usage, app crashed and I could watch heap in NetBeans. Results:
Note: I didn't created any LinkedHashMap in my app, so it must be created by other library. TagNode is a object that hold cleaned html after 'HTML Cleaner' cleaning. I've only one TagNode Object in my app and it is local variable in netty http response handler (called by messageReceived).
发布评论
评论(2)
与 Netbeans 的内置诊断工具相比,我一直更喜欢 Eclipse 的 MAT 工具。 MAT 还可以处理比 Netbeans 更大的堆转储。
最简单的方法是让 jvm 在 OOM 时吐出堆转储,将其输入 MAT 中,并根据泄漏可疑列表追溯到内存泄漏的可能原因。
是您需要的 JVM 选项。另一种方法是在应用程序 OOM 之前定期生成一些堆转储,并在 MAT 中比较这些堆转储 - 它具有比较转储的功能。请参阅此处了解如何生成转储。有时,有必要检查堆元素的内容以找出它们的来源。
这并不容易,并且需要一些时间来学习如何放大堆转储中的罪魁祸首,但这是一项非常有用的技能。
I've always preferred Eclipse's MAT tool to Netbeans' built-in diagnostic facilities. MAT can work with bigger heapdumps than Netbeans as well.
The easiest is to have the jvm spit out a heapdump on OOM, feed it into MAT and based on the leak suspect list trace back to the probable cause of the memory leak.
is the JVM option you'll need. Another approach is to generate some heapdumps at regular intervals before the applications OOMs, and compare those in MAT - it has a facility to compare dumps. See here to learn how to generate dumps. Sometimes inspecting the content of the heap elements is necessary to figure out where they come from.
It won't be easy, and it takes some time to learn how to zoom in on the culprit in a heap dump, but it's a very useful skill.
你似乎有很多 char[] 对象。我发现大部分内存泄漏都来自于错误构造的循环,其中循环的迭代次数超出了应有的次数。这会创建大量对象,导致内存泄漏。
活动字节只是活动对象占用的字节总数。
有大量
char[]
活动字节正在使用中。我对此表示怀疑,因为这可能是发生内存泄漏的原因。您最好创建断点并单步执行,以准确查看内存泄漏发生在哪一行。
在 NetBeans IDE 中分析 Java 应用程序简介应该能够帮助您了解如何在 NetBeans 中进行调试。
希望这有帮助。
You seem to have a lot of char[] objects. I have found most of my memory leaks come from wrongly constructed loops where they are iterating more times than they should be. Which creates a huge amount of objects, resulting in a memory leak.
Live bytes are just the total number of bytes the live objects take up.
There are a lot of
char[]
live bytes in use. I would be suspicious about this as its probably why the memory leak is occurring.You would be best to create breakpoints and step through the execution to see exactly at what line the memory leak occurs.
A good place to read would be Introduction to Profiling Java Applications in NetBeans IDE.Should be able to help you with how to debug in NetBeans.
Hope this helps.