在这种情况下,一个java垃圾收集的年轻一代长久？

发布时间：2020-12-14 16:28:19 所属栏目：Java 来源：网络整理

导读：昨天我们在一个JBoss应用服务器的服务器日志中有以下GC输出： 51628.286: [GC 51628.288: [ParNew: 1843200K-204800K(1843200K),21.3196040 secs]5177730K-3743415K(7987200K),21.3217870 secs][Times: user=1.38 sys=0.33,real=21.32 secs] 我理解这样的输

昨天我们在一个JBoss应用服务器的服务器日志中有以下GC输出：

51628.286: [GC 51628.288: [ParNew: 1843200K->204800K(1843200K),21.3196040 secs]
5177730K->3743415K(7987200K),21.3217870 secs]
[Times: user=1.38 sys=0.33,real=21.32 secs]

我理解这样的输出：年轻一代的大小是1843200K.前一代规模为1843200K,规模为204800K.集合持续21.3秒.

通常,我们的年轻一代收藏品持续1秒.在哪些情况下,yg收藏品持续了很久？

我们的JVM参数：

-server 
-verbose:gc
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails 
-XX:NewRatio=3
-XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC 
-XX:+UseCMSCompactAtFullCollection 
-XX:CMSInitiatingOccupancyFraction=60 
-XX:MaxPermSize=256m 
-Xss512k 
-Xms8000m 
-Xmx8000m

java版本：

java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02,mixed mode)

谢谢,
马塞尔

解决方法

我们有一个tomcat服务器,垃圾收集持续了约2分钟.最终,我们发现原因,我们通过-Xmx分配了更多的内存给JVM,而不是我们在系统上有物理内存.这是在垃圾回收过程中造成分页,从而杀死它.

此外,我们有多台VM在同一物理机上运行.确保您没有为所有虚拟机分配更多的内存,而不是在服务器上具有物理内存.

有关更多信息,请参阅Tuning the Memory Management System,section Setting the Heap Size(我的重点)：

Command line options: -Xms: -Xmx:

The heap size has an impact on allocation speed,garbage collection
frequency and garbage collection times. A small heap will become full
quickly and must be garbage collected more often. It is also prone to
more fragmentation,making object allocation slower. A large heap
introduces a slight overhead in garbage collection times. A heap that is larger than the available physical memory in the system must be paged out to disk,which leads to long access times or even application freezes,especially during garbage collection.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!