java - 垃圾收集器无法释放 JBoss 7.1.1 上的内存，导致 Full GC

Question

我正在 JBoss 7.1.1 最终服务器上运行应用程序，部署在 Linux RedHat 5 上

当我启动服务器时，每次启动GC后，使用的内存都会增加2.5M，导致1或2小时内出现完整GC错误。

即使不使用该应用程序，也会发生这种情况。无论 gcInterval 参数如何，GC 每 10 秒运行一次。

部署在具有相同 JVM 和 JVM 参数的 Windows 开发 PC 上的相同应用程序运行良好。如果不使用应用程序，GC 不会启动。 GC 工作后，已用内存不会增加。

JDK:1.7.0_55 x64 JVM 参数:-Xms256m -Xmx1024m -XX:MaxPermSize=512m -verbose:gc -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000

[... Starting JBoss, application is not in use]
[GC 487573K->211517K(585216K), 0,0631790 secs]
[GC 490557K->213509K(585216K), 0,0636420 secs]
[... 10 minutes later]
[GC 585797K->298581K(590848K), 0,0633730 secs]
[GC 587861K->300629K(590848K), 0,0826110 secs]
[Full GC 300629K->255804K(742912K), 1,8318540 secs]
[GC 545084K->258220K(733696K), 0,0096510 secs]
[GC 538284K->260140K(708096K), 0,0139590 secs]
[... 10 minutes later]
[GC 921600K->636408K(967680K), 0,0704860 secs]
[GC 923640K->638440K(967680K), 0,1334640 secs]
[GC 925672K->640472K(967680K), 0,0706450 secs]

我分析了内存转储并使用 MAT 打开了它，大的消耗对象来自 JBoss 而不是来自应用程序:

(http://img4.hostingpics.net/pics/459885MAT.jpg)

为了进行比较，这里是 Windows 下开发 PC 上相同应用程序、相同 JVM 和 JVM 参数的 Visual VM 屏幕截图。左侧:应用程序未使用，右侧应用程序正在使用。 GC 运行正常，在必要时运行，并且使用的内存量稳定:

(http://img4.hostingpics.net/pics/246156VisualVM.jpg)

感谢您的帮助!

编辑:这里是详细的GC日志:

294,409: [GC [PSYoungGen: 131584K->10012K(236544K)] 282316K->160745K(525312K), 0,0257640 secs] [Times: user=0,05 sys=0,00, real=0,03 secs]
300,698: [GC [PSYoungGen: 145692K->13937K(240640K)] 296425K->164670K(529408K), 0,0314710 secs] [Times: user=0,06 sys=0,00, real=0,03 secs]
320,822: [GC [PSYoungGen: 149617K->26904K(234496K)] 300350K->177637K(523264K), 0,0596520 secs] [Times: user=0,11 sys=0,00, real=0,06 secs]
349,830: [GC [PSYoungGen: 167704K->36648K(240128K)] 318437K->187381K(528896K), 0,0856060 secs] [Times: user=0,14 sys=0,00, real=0,09 secs]
400,827: [GC [PSYoungGen: 177448K->50600K(237056K)] 328181K->201333K(525824K), 0,1015110 secs] [Times: user=0,20 sys=0,00, real=0,10 secs]
453,335: [GC [PSYoungGen: 197544K->65128K(239616K)] 348277K->215861K(528384K), 0,1270900 secs] [Times: user=0,24 sys=0,00, real=0,13 secs]
507,227: [GC [PSYoungGen: 212072K->79720K(235520K)] 362805K->230453K(524288K), 0,1589030 secs] [Times: user=0,31 sys=0,00, real=0,16 secs]
557,260: [GC [PSYoungGen: 218472K->93288K(232448K)] 369205K->244021K(521216K), 0,1785030 secs] [Times: user=0,35 sys=0,00, real=0,18 secs]
608,082: [GC [PSYoungGen: 232040K->106920K(233472K)] 382773K->257653K(522240K), 0,2963930 secs] [Times: user=0,40 sys=0,00, real=0,29 secs]
650,849: [GC [PSYoungGen: 224168K->110152K(233472K)] 374901K->268963K(522240K), 0,2341450 secs] [Times: user=0,45 sys=0,00, real=0,23 secs]
693,327: [GC [PSYoungGen: 227400K->103792K(233472K)] 386211K->280538K(522240K), 0,2343350 secs] [Times: user=0,46 sys=0,01, real=0,23 secs]
736,396: [GC [PSYoungGen: 221040K->91616K(233472K)] 397786K->292164K(522240K), 0,2261210 secs] [Times: user=0,43 sys=0,02, real=0,23 secs]
778,381: [GC [PSYoungGen: 208864K->74208K(233472K)] 409412K->303868K(522240K), 0,2123170 secs] [Times: user=0,39 sys=0,03, real=0,21 secs]
821,401: [GC [PSYoungGen: 191456K->58592K(233472K)] 421116K->315572K(522240K), 0,1734580 secs] [Times: user=0,32 sys=0,02, real=0,18 secs]
821,575: [Full GC [PSYoungGen: 58592K->18031K(233472K)] [ParOldGen: 256980K->288398K(480768K)] 315572K->306430K(714240K) [PSPermGen: 79966K->79787K(139776K)], 2,7505260 secs] [Times: user=5,14 sys=0,01, real=2,75 secs]
863,389: [GC [PSYoungGen: 135279K->23424K(233472K)] 423678K->318334K(714240K), 0,2504760 secs] [Times: user=0,49 sys=0,00, real=0,25 secs]
906,570: [GC [PSYoungGen: 140672K->24256K(233472K)] 435582K->330022K(714240K), 0,0820190 secs] [Times: user=0,15 sys=0,01, real=0,08 secs]
948,403: [GC [PSYoungGen: 141504K->24192K(233472K)] 447270K->341774K(714240K), 0,0817190 secs] [Times: user=0,15 sys=0,01, real=0,08 secs]
991,577: [GC [PSYoungGen: 141440K->12576K(233472K)] 459022K->353598K(714240K), 0,0888270 secs] [Times: user=0,16 sys=0,01, real=0,09 secs]
1032,722: [GC [PSYoungGen: 129824K->12192K(233472K)] 470846K->365022K(714240K), 0,0605500 secs] [Times: user=0,10 sys=0,01, real=0,06 secs]
Heap
 PSYoungGen      total 233472K, used 46338K [0x00000000eaa80000, 0x0000000100000000, 0x0000000100000000)
  eden space 117248K, 29% used [0x00000000eaa80000,0x00000000ecbd8be8,0x00000000f1d00000)
  from space 116224K, 10% used [0x00000000f8e80000,0x00000000f9a68000,0x0000000100000000)
  to   space 116224K, 0% used [0x00000000f1d00000,0x00000000f1d00000,0x00000000f8e80000)
 ParOldGen       total 480768K, used 352830K [0x00000000c0000000, 0x00000000dd580000, 0x00000000eaa80000)
  object space 480768K, 73% used [0x00000000c0000000,0x00000000d588fad8,0x00000000dd580000)
 PSPermGen       total 139776K, used 80224K [0x00000000a0000000, 0x00000000a8880000, 0x00000000c0000000)
  object space 139776K, 57% used [0x00000000a0000000,0x00000000a4e58260,0x00000000a8880000)

Edit2:内存转储揭示了内存泄漏的根源:

由“org.jboss.modules.ModuleClassLoader @ 0x78122a170”加载的“com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple”的3 616个实例占用153 506 944 (64,98%)字节。这些实例是从“java.util.HashMap$Entry[]”的一个实例引用的，由“”加载

Answer 1

找出解决方案...这是由 JBoss AS 版本 7.1.1 Final 中的 Ironjacamar 模块中的错误引起的...

要更正，您可以使用以下模块修补模块:ironjacamar-core-impl.jar

或将 JBoss 更新到 AS 版本 7.2.0 +(您必须自行构建，因为它不再分发)

如果您能获得许可，另一个选择是切换到 JBoss EAP 6.3。

希望这有帮助:)