How to understand this NetBeans memory profile session in java (visible memory leak)?

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 m开发者_运维技巧y app and it is local variable in netty http response handler (called by messageReceived).

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.

-XX:+HeapDumpOnOutOfMemoryError

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.

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.