垃圾收集器无法释放 JBoss 7.1.1 上的内存导致 Full GC答案

【问题标题】：Garbage collector can't free memory on JBoss 7.1.1 causing Full GC垃圾收集器无法释放 JBoss 7.1.1 上的内存导致 Full GC
【发布时间】：2014-09-02 21:51:40
【问题描述】：

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

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

即使在不使用应用程序时也会发生这种情况。 GC 每 10 秒运行一次，与 gcInterval 参数无关。

在具有相同 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[]”的一个实例，由“”加载

【问题讨论】：

标签： java memory-leaks jboss garbage-collection jvm

【解决方案1】：

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

要更正，您可以用这个修补模块：ironjacamar-core-impl.jar

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

如果你能负担得起许可证，另一个选择是切换到 JBoss EAP 6.3。

希望这会有所帮助:)

【讨论】：

所以它生成了额外的 java 对象？

【解决方案2】：

啊，我看到你有一个臭名昭著的 JRE 堆查询。你不只是喜欢这些类型的问题吗？！？！ ^_^

在没有更多信息的情况下回答您的问题很棘手，就像 Arunkumar 所问的那样。但是，我的回答可以笼统。通常在设置 JRE 堆配置时，应该在 Wrapper.conf 文件中完成。在这里您应该指定您的 GC 方法、限制、页面大小等。仅用于演示目的，请参见下面的示例；

wrapper.java.additional.4=-XX:SurvivorRatio=6
wrapper.java.additional.5=-XX:MaxPermSize=320m
wrapper.java.additional.6=-Xss256k
wrapper.java.additional.7=-XX:+UseConcMarkSweepGC
wrapper.java.additional.8=-XX:+UseParNewGC
wrapper.java.additional.9=-XX:TargetSurvivorRatio=90
wrapper.java.additional.10=-XX:MaxTenuringThreshold=31
wrapper.java.additional.11=-XX:LargePageSizeInBytes=4m
#wrapper.java.additional.12=-XX:+UseLargePages
#Make sure that the RMI garbage collection is done every hour, not every minute
wrapper.java.additional.12=-Dsun.rmi.dgc.client.gcInterval=3600000 
wrapper.java.additional.13=-Dsun.rmi.dgc.server.gcInterval=3600000
wrapper.java.additional.14=-XX:NewSize=836m
wrapper.java.additional.15=-XX:MaxNewSize=836m

Oracle 网站上有很多关于 Java 调优的文档，这个链接可能会有所帮助。

http://docs.oracle.com/cd/E15523_01/web.1111/e13814/jvm_tuning.htm

我希望这对您的查询有所帮助。

问候，向量0r

【讨论】：

感谢您的回答。实际上，问题是数据库事务中的内存泄漏，如内存转储所示：3 616 个“com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple”实例，由“org.jboss.modules.ModuleClassLoader”加载@ 0x78122a170" 占用 153 506 944 (64,98%) 个字节。这些实例引用自“” 加载的“java.util.HashMap$Entry[]”的一个实例