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!
Java Memory "Leak" with ConcurrentLinkedQueue$Node
-
09-07-2023 - |
Pregunta
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.
Solución
Otros consejos
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!