调整JVM堆大小后解释jstat输出

Question

在最近尝试增加堆空间和新旧世代大小的比率之后，我看到了来自jstat -gccapacity的令人困惑的结果，它显示出的容量比我预期的要小得多。

JVM (1.5.0_16)是用-server -Xms2048m -Xmx2048m -XX:NewRatio=2启动的。它正在Solaris 5.10 amd64主机上运行。有大约10 of的空闲内存。因此，根据我所读到的，JVM应该能够使用整个2GB的堆空间。

看着jstat -gcutil，我观察到几代人都填满了几次，导致垃圾收集。例如：

Timestamp         S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT
        66150.4   0.00  51.09  56.95  90.33  54.85   6291   58.922     7   22.826   81.748

我认为这会使JVM将所有代扩展到它们的全部大小。但是，jstat -gccapacity生成：

 NGCMN    NGCMX     NGC     S0C   S1C       EC      OGCMN      OGCMX       OGC         OC      PGCMN    PGCMX     PGC       PC     YGC    FGC
700416.0 700416.0  86016.0 1408.0 1408.0  39104.0  1398784.0  1398784.0  1398784.0  1398784.0  16384.0  65536.0  38912.0  38912.0   6338     7

后续运行显示NGC/S0C/S1C/EC值发生了变化：

 NGCMN    NGCMX     NGC     S0C   S1C       EC      OGCMN      OGCMX       OGC         OC      PGCMN    PGCMX     PGC       PC     YGC    FGC
700416.0 700416.0  86016.0 1472.0 1472.0  39104.0  1398784.0  1398784.0  1398784.0  1398784.0  16384.0  65536.0  38912.0  38912.0   6380     7
700416.0 700416.0 106496.0 1792.0 1856.0  97024.0  1398784.0  1398784.0  1398784.0  1398784.0  16384.0  65536.0  38912.0  38912.0   6433     7
700416.0 700416.0 106496.0 1792.0 1792.0  96064.0  1398784.0  1398784.0  1398784.0  1398784.0  16384.0  65536.0  38912.0  38912.0   6436     7

据我所知，容量数字是该代人的总人数，而使用数字则显示该代人的拨款情况。因此，上述结果告诉我，新的最大容量和最大容量都是(NGCMN/MGCMX) 684 me，旧的gen min和max为1,366 me (OGCMN/OGCMX)。让我困惑的是新一代的能力。所以我的问题是：

1. 为什么没有EC + S0C + S1C == NGC？(41,920 != 86016)
2. 为什么NGC明显小于NGCMN/MGCMX？
   • 是因为堆的最大大小正在被击中(这将使它从NGC+OGC+PGC中降至1,488 if )，如果是的话，会导致下限吗？我能找到的所有文档都说Solaris 64位JVM应该能够使用4GB.

。

​

如果达到了最大堆大小，为什么新一代的容量会发生变化(所有容量都在增加，或者全部减少)，而不让老一代更改为compensate).。

其他可能有用的jstat结果：

$ jstat -gcnew 20167
 S0C    S1C    S0U    S1U   TT MTT  DSS      EC       EU     YGC     YGCT
1536.0 1600.0 1300.3    0.0 13  15 1600.0  82880.0  30892.6   6482   60.540

$ jstat -gcnewcapacity 20167
  NGCMN      NGCMX       NGC      S0CMX     S0C     S1CMX     S1C       ECMX        EC      YGC   FGC
  700416.0   700416.0   106496.0   1472.0 233472.0 233472.0   1408.0   700288.0    81088.0  6489     7

$ jstat -gcold 20167
   PC       PU        OC          OU       YGC    FGC    FGCT     GCT
 38912.0  21426.5   1398784.0   1375651.6   6503     7   22.826   83.627

$ jstat -gcoldcapacity 20167
   OGCMN       OGCMX        OGC         OC       YGC   FGC    FGCT     GCT
  1398784.0   1398784.0   1398784.0   1398784.0  6517     7   22.826   83.779

$ jstat -gcpermcapacity 20167
  PGCMN      PGCMX       PGC         PC      YGC   FGC    FGCT     GCT
   16384.0    65536.0    38912.0    38912.0  6531     7   22.826   83.925

Answer 1

结果表明，这是吞吐量收集器的故意行为：

Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine > 5.2.2.2 Adjusting Generation Sizes

由收集器保存的统计信息(例如，平均暂停时间)在集合结束时被更新。然后进行测试，以确定这些目标是否已经实现，并对一代人的规模进行任何必要的调整。

当JVM处于峰值负载时，观察GC容量确实表明合并的年轻一代容量等于最小/最大容量值。