Java ConnectionQueueStatsProvider内存不足错误

上周，我们的生产环境出现内存不足错误。此内存不足错误可能每周发生一次，当前的解决方法是重新启动应用程序服务器。我们正在使用glassfish 3.0.1。生成的堆转储大约为5gb

请帮助分析下面的堆转储。下面是使用EclipseMat生成的泄漏嫌疑犯报告。我们如何分析下面的报告

One instance of 
"com.sun.enterprise.v3.services.impl.monitor.stats.ConnectionQueueStatsProvider" loaded by 
"org.apache.felix.framework.ModuleImpl$ModuleClassLoader @ 0x602650970" occupies 
2,104,143,312 (87.97%) bytes. The instance is referenced by 
org.glassfish.flashlight.impl.client.ReflectiveClientInvoker @ 0x600a63768 , loaded by 
"org.apache.felix.framework.ModuleImpl$ModuleClassLoader @ 0x60265dd38". The memory is 
accumulated in one instance of "java.util.concurrent.ConcurrentHashMap$Segment[]" loaded 
by "<system class loader>".

Keywords
org.apache.felix.framework.ModuleImpl$ModuleClassLoader @ 0x602650970
org.apache.felix.framework.ModuleImpl$ModuleClassLoader @ 0x60265dd38
java.util.concurrent.ConcurrentHashMap$Segment[]
com.sun.enterprise.v3.services.impl.monitor.stats.ConnectionQueueStatsProvider

的一个实例
加载的“com.sun.enterprise.v3.services.impl.monitor.stats.ConnectionQueueStatsProvider”
“org.apache.felix.framework.ModuleImpl$ModuleClassLoader@0x602650970”占据
2104143312（87.97%）字节。实例由引用
org.glassfish.flashlight.impl.client.ReflectiveClientInvoker@0x600a63768，由加载
“org.apache.felix.framework.ModuleImpl$ModuleClassLoader@0x60265dd38”。记忆是
在加载的“java.util.concurrent.ConcurrentHashMap$Segment[]的一个实例中累积
以“方式”。
关键词
org.apache.felix.framework.ModuleImpl$ModuleClassLoader@0x602650970
org.apache.felix.framework.ModuleImpl$ModuleClassLoader@0x60265dd38
java.util.concurrent.ConcurrentHashMap$段[]
com.sun.enterprise.v3.services.impl.monitor.stats.ConnectionQueueStatsProvider

---

请检查您的函数调用流，因为您没有关闭曾经打开的数据库连接，从而导致内存泄漏

---

查看此对话以了解更多信息

仅凭这些信息很难分析原因

根据报告，可能是数据库连接问题

尝试：

• 确认ConnectionQueueStatsProvider持有的内容（可能是java.util.concurrent.ConcurrentHashMap$Segment[]）

• 打开源代码，找出ConnectionQueueStatsProvider的ConcurrentHashMap中的内容

---

如果java.util.concurrent.ConcurrentHashMap$Segment[]标记大部分空间，则应用程序可能存在数据库连接问题

Java.util.concurrent.ConcurrentHashMap是ConnectionQueueStatsProvider中唯一的一种用法： 私有最终openConnectionsCount=new（）

---

尝试检查您的代码并关闭数据库连接。

嗯，MAT在这里非常明显。您有一个ConnectionQueueStatsProvider实例，它有一个巨大的openConnectionsCount映射。看起来你一直在填这张地图，但从来没有从中删除任何东西。内存泄漏（如果我曾经看到过：）

---

将来，您可能会对它感兴趣，它的创建是为了用更少的努力来发现此类问题。

我们认为我们找到了答案。我们在玻璃鱼jira中看到了类似的错误报告：。这似乎是glassfish 3.0.1的一个bug

当glassfish监视线程池和http服务时，他们出现了内存不足错误，这正是我们的设置

我们关闭了glassfish监控，现在我们可以稳定运行1周，没有任何内存不足

---

谢谢大家的帮助

嗨！您在哪里看到db连接是问题的原因？可能不是数据库连接，数据库连接也会产生相同的问题，并且连接信息存储在Hashmaps中，因此这里也有一些连接被打开，但没有通过将其保留为垃圾收集器来正确关闭。所以，从这个角度来看 66 private final Map<Integer, Long> openConnectionsCount = new ConcurrentHashMap<Integer, Long>();