“Java内存”；“泄漏”；使用ConcurrentLinkedQueue$节点

我遇到了一个有趣的两难境地，似乎是内存泄漏（或数据结构不断增长）。当我分析我的内存使用情况时，我得到了典型的“随时间线性上升”图。为了找出问题的原因，我进行了堆转储。我发现超过50%的内存被分配给

ConcurrentLinkedQueue节点

。内存的最大消耗者是，

com.singularity.ee.agent.util.ch

和

java.util.concurrent.ConcurrentLinkedQueue$Node

，如下图所示

我不知道什么是

util.ch

，但它似乎与节点有关，因为每个ch都有一个对节点的直接引用，所以不用担心会关注这个问题

现在，我尝试查找对$Node的最近GC的引用，得到以下结果：

奇怪的是，它没有ConcurrentLinkedQueue$节点，甚至没有ConcurrentLinkedQueue作为父节点。所有引用都是我不理解的奇怪类型，

kh、uc、z、g等。

有人知道这些类型是什么吗

我试图找出问题的确切原因，但我无法确定这些节点是如何创建/保存的

关键是：我在代码中的任何地方都不使用ConcurrentLinkedQueue。我确实使用ConcurrentHashMap，但HashMap$Node并不多，所以这不应该成为问题

有没有人知道这些节点是如何创建的，或者为什么我有这么多的节点实例

---

为了回答依赖性问题：我正在运行tomcat 6、java 6和java Spring。

根据您的评论，因为它是引用*.util.ch类的链表，所以您可以查找与*.util.ch类一起依赖于ConcurrentLinkedQueue的JAR

一旦确定了jar，那么根据包含的类是内部构建的还是第三方jar，您可以检查泄漏是否可以修复，或者修复是否可用

关于如何确定依赖关系，请查看这是否有助于-

除非使用反射，否则类（因此包含jar）应该很容易找到。如果可能使用反射，则提取JAR并尝试对所有*.class文件执行“包含”搜索

---

PS：如果已经找到解决方案，请务必注明

原来我有一些来自AppDynamics的专有代码导致了这个问题。我向他们开了一张罚单，他们在下一版本中解决了这个问题。谢谢你的帮助

类名听起来像是混淆了的代码，这使得分析代码变得更加困难。这可以在出售的框架上完成，也可以由攻击者完成。由于singularity.com看起来不像一个软件vondor，如果我处在你的位置，我会小心的。除了一个小的调试技巧外，我帮不了你多少忙：getClass（）.getProtectionDomain（）.getCodeSource（）可以帮助你找出类从何处加载。这可能有助于弄清楚它是什么以及如何摆脱它。祝你好运在更彻底的谷歌搜索中，com.singularity.ee.agent似乎与AppDynamics相关联（尽管我在这里找不到确切的类），我用它来监控内存。也许是AppDynamics本身造成了问题。@Humdinger您使用的是什么IDE？如果删除AppDynamics而改用MAT（在Eclipse中），会得到相同的结果吗？@durron597我使用的是IntelliJ。我无法准确地“删除AppDynamics”，因为它位于生产服务器上。不过，我已经在AppDynamics开了一张罚单，我会看看他们怎么说。我正在使用VisualVM分析服务器的堆转储，因为我无法在本地复制内存泄漏。哪些类包含对

.util.ch

的引用？你能一直跳到一个没有混淆的类吗？省去了我这么多麻烦！