由于org.jboss.vfs.spi.JavaZipFileSystem的实例数量增加，导致内存泄漏 [英] Memory leak due to more number of instances of org.jboss.vfs.spi.JavaZipFileSystem

问题描述

我们正在使用JBoss eap 6.4.部署和访问应用程序时，我们遇到了堆问题(内存不足错误).创建了堆转储文件以进行更多调查.使用Eclipse MAT工具分析了堆转储文件.MAT工具在抱怨以下泄漏.

We are using JBoss eap 6.4. We are running into heap issues(out f memory error) when the application is deployed and accessed.Created a heap dump file to investigate more. Analyzed the heap dump file using Eclipse MAT tool. MAT tool is complaining abut the following leak.

问题嫌疑人1

"org.jboss.vfs.spi.JavaZipFileSystem"的183个实例，由"org.jboss.modules.ModuleClassLoader @ 0xe0884088"占据了24507432(14.20％)个字节.

183 instances of "org.jboss.vfs.spi.JavaZipFileSystem", loaded by "org.jboss.modules.ModuleClassLoader @ 0xe0884088" occupy 24,507,432 (14.20%) bytes.

最大实例:•org.jboss.vfs.spi.JavaZipFileSystem @ 0xe1c65988-2,367,616(1.37％)字节.•org.jboss.vfs.spi.JavaZipFileSystem @0xe1c64308-1,883,528(1.09％)字节.•org.jboss.vfs.spi.JavaZipFileSystem @ 0xe1c5c660-1,729,400(1.00％)个字节.这些实例是从的一个实例引用的"java.util.HashMap $ Node []"，由"

Biggest instances: •org.jboss.vfs.spi.JavaZipFileSystem @ 0xe1c65988 - 2,367,616 (1.37%) bytes. •org.jboss.vfs.spi.JavaZipFileSystem @ 0xe1c64308 - 1,883,528 (1.09%) bytes. •org.jboss.vfs.spi.JavaZipFileSystem @ 0xe1c5c660 - 1,729,400 (1.00%) bytes. These instances are referenced from one instance of "java.util.HashMap$Node[]", loaded by ""

关键字org.jboss.vfs.spi.JavaZipFileSystem java.util.HashMap $ Node []org.jboss.modules.ModuleClassLoader @ 0xe0884088

Keywords org.jboss.vfs.spi.JavaZipFileSystem java.util.HashMap$Node[] org.jboss.modules.ModuleClassLoader @ 0xe0884088

详细信息»

任何人都可以解释上述泄漏(为什么会发生并且可以做什么?)并提出解决内存泄漏的解决方案?

Can anyone explain the above leak(why it happens and what cane be done?)and propose a solution to fix the memory leak?

更新:以下是JBOSS尝试加载的类的列表:

UPDATE: The following is the list of classes that the JBOSS is trying to load:

更新:以下是使用Eclipse MAT的控制树视图:

UPDATE: The following is the dominator tree view using Eclipse MAT:

以下是org.springframework.beans.factory.support.DefaultListableBeanFactory的GC的路径(此类具有更多保留的堆):

The following is the path to GC of org.springframework.beans.factory.support.DefaultListableBeanFactory(This class has more retained heap):

推荐答案

它与

It Looks simular to known jboss EAP issue described in https://access.redhat.com/solutions/36954 The link is for EAP version 5 but looks like 6 has similar issue. The class name may be different.

一种解决方法是减少已部署的jar的数量:

A workaround is to reduce the number of deployed jars:

• Slim EAP 5 .

对于使用相同库版本的应用程序，请将部署之间的所有重复jar移至$ JBOSS_HOME/server/$ CONFIG/lib/.

For applications that use the same library version, move any duplicate jars amongst deployments to $JBOSS_HOME/server/$CONFIG/lib/.

使用未压缩的部署

使用下面的JVM选项对内存中的JAR处理进行重新排序，以减少潜在性能下降时的VFS缓存内存消耗:

use the below JVM option to re-order in-memory JAR handling to reduce VFS cache memory consumption at potential performance hit:

-Djboss.vfs.optimizeForMemory = true

-Djboss.vfs.optimizeForMemory=true

诊断步骤:

使用下面的OQL语句检查存在哪些JAR条目.这里的很多重复说明您是保留的源头.

Check what JAR entries there are using the OQL statement below. Lots of duplication here will show you were the retention is stemming from.

SELECT toString(s.rootURI.string) FROM org.jboss.virtual.plugins.context.zip.ZipEntryContext s

以您的情况

SELECT toString(s.rootURI.string) FROM org.jboss.vfs.spi.JavaZipFileSystem s

这篇关于由于org.jboss.vfs.spi.JavaZipFileSystem的实例数量增加，导致内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！