Java Memory "Leak" with ConcurrentLinkedQueue$Node

Question

I am having an interesting dilemma where I appear to have a memory leak (or growing data structure). I get the typical "raising linearly over time" graph when I analyse my memory usage. Trying to figure out what the cause of the problem is, I did a heap-dump. What I found was that over 50% of memory was being allocated for a ConcurrentLinkedQueue node. The top consumers of memory are, com.singularity.ee.agent.util.ch and java.util.concurrent.ConcurrentLinkedQueue$Node as seen in the picture below.

I dont know what a util.ch is but it appears to be tied to the Node, as each ch has an immediate reference to a node, so no worries focusing on that.

Now trying to find references to the closest GC for a $Node, I get the following:

Whats strange about this is that it does not have a ConcurrentLinkedQueue$Node, or even a ConcurrentLinkedQueue as a parent at all. All references are strange types that I do not understand, kh, uc, z, g, etc. Does anyone know what these types are?

I am trying to find out what exactly is causing the problem, but I cant seam to find how these nodes are even being created/saved.

Here is the kicker: I do not use the ConcurrentLinkedQueue anywhere in my code. I do use a ConcurrentHashMap, but there are not very many HashMap$Node's so that shouldnt be the issue.

Does anyone have any ideas as to how these nodes are being created or why I have so many instances of them?

To answer dependency questions: I am running tomcat 6, java 6, Java Spring.

Answer 1

Turns out I had some proprietary code from AppDynamics causing this issue. I opened a ticket with them and they fixed the issue in their next release. Thank you for all the help though!

Answer 2

From your comments, since its the linked list that's referencing the *.util.ch class, you can look for jars that have a dependency on the ConcurrentLinkedQueue along with the *.util.ch class.

Once the jar is identified, then depending upon whether the containing class was built in-house or if a third party jar you can check if the leak can be fixed or if a fix is available.

Regarding how to determine dependency, see if this helps - Find all dependencies in a Java class

Unless reflection is used, the class (and therefore containing jar) should be easy to find. If there is a possibility of reflection being used, then extract the jars and try doing a 'contains' search on all the *.class files.

PS : If the solution has already been found, do indicate as such!