Java 垃圾收集器罐'；t在JBoss 7.1.1上释放内存，导致完全GC

我正在JBoss7.1.1最终服务器上运行一个应用程序，该服务器部署在linux RedHat 5上

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

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

部署在windows Development PC上、具有相同JVM和JVM参数的同一应用程序工作正常。如果未使用应用程序，则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，而不是应用程序：

（）

为了进行比较，这里是一个在windows下开发PC上相同应用程序、相同JVM和JVM参数的可视化VM屏幕截图。左侧：未使用的应用程序，右侧为正在使用的应用程序。GC功能正常，在必要时运行，使用的内存量稳定：

（）

谢谢你的帮助

编辑：下面是详细的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”加载的3616个“com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple”实例占用153 506 944（64,98%）字节。这些实例引用自“java.util.HashMap$Entry[]”的一个实例，该实例由“

Ahh”加载，我发现您有一个臭名昭著的JRE堆查询。你难道不喜欢这类问题吗^_^

回答你的问题很难，没有更多的信息，就像阿伦库玛问的那样。不过，我可以笼统地回答。通常在设置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调优的文档，这个链接可能会很有帮助

我希望这有助于你的提问

问候,，

---

Vect0r

找出解决方案。。。这是由JBoss7.1.1最终版中ironjacamar模块中的一个错误引起的

要更正此问题，您可以使用以下方法修补模块：

或者将JBoss更新为7.2.0+（由于不再分发，您必须自己构建）

另一个选择是切换到JBoss EAP 6.3，如果您可以支持该许可证的话

---

希望这有帮助：）

谢谢你的回答。事实上，问题是数据库事务中的内存泄漏，如内存转储所示：由“org.jboss.modules.ModuleClassLoader@0x78122a170”加载的3616个“com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple”实例占用153506944（64,98%）字节。这些实例引用自“java.util.HashMap$Entry[]”的一个实例，该实例由“”加载，所以它生成了额外的java对象？