Java Memory Leak with ConcurrentLinkedQueue $ Node

Question

I have an interesting dilemma where I seem to have a memory leak (or a growing data structure). When analyzing memory usage, I get a typical graph of "increasing linearity in time." Trying to figure out what was causing the problem, I made a bunch of dumps. I found that more than 50% of the memory is allocated for the ConcurrentLinkedQueue node . The main consumers of memory are com.singularity.ee.agent.util.ch and java.util.concurrent.ConcurrentLinkedQueue$Node , as shown in the figure below.

I do not know what util.ch , but it looks like it is tied to Node, since each ch has a direct link to Node, so do not worry about it.

Now, trying to find links to the nearest GC for $ Node, I get the following:

What is strange is that it does not have ConcurrentLinkedQueue $ Node or even ConcurrentLinkedQueue as a parent at all. All links are weird types that I don't understand, kh, uc, z, g, etc. Does anyone know what these types are?

I am trying to figure out what exactly is causing the problem, but I cannot find how these nodes are created / saved.

Here is the kicker: I am not using ConcurrentLinkedQueue anywhere in my code. I use ConcurrentHashMap, but not much HashMap $ Node, so this should not be a problem.

Does anyone have any ideas on how these nodes are created or why I have so many of them?

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

Answer 1

Turns out I had some kind of proprietary code from AppDynamics causing this problem. I opened a ticket for them and they fixed the problem in the next release. Thank you for your help!

Answer 2

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

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

Regarding the definition of dependencies, see if this helps - Find all the dependencies in the Java class

If reflection is not used, the class (and therefore containing the jar) should be easy to find. If it is possible to use reflection, remove the jars and try to search for "contains" in all * .class files.

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