jstat：幸存者和伊甸园空间容量在一段时间内减少
在JVM重启之前，java（8）内存容量是否会减少？
我正在使用jstat-gc转储内存信息，下面是两天的快照。与第一个快照相比，第二个快照对SC1和EC的资本金更少。
有人能帮助/解释为什么我看到这种行为吗？这是预期的吗？
Java version : java-1.8.0-openjdk-1.8.0.191.b12
sc1: survivor space 1 capacity
EC: eden space capacity
S0C, S1C, S0U, S1U,EC,EU,OC,OU,MC,MU,CCSC,CCSU,YGC,YGCT,FGC,FGCT,GCT
4096.0,7168.0,3968.3,0.0,123904.0,54705.9,101888.0,24165.6,62464.0,60100.6,7168.0,6618.4,30,1.314,3,0.298,1.612
5632.0,4096.0,0.0,4000.2,113152.0,56035.3,101888.0,24165.6,62720.0,60145.3,7168.0,6620.0,33,1.345,3,0.298,1.643
共有1个答案
有一个标志控制：-XX:UseAptiveSizePolicy，默认情况下启用。这个标志的作用是，根据你的目标暂停时间（你使用的是G1我猜），根据它收集的启发增加或减少某些区域。了解它的确切功能的最佳方法是查看G1本身的源代码。
-
你能回答我一个关于JVM垃圾收集过程的问题吗？ 为什么堆被分为伊甸园、幸存者空间和老一代？ 当一个年轻的疏散被处理时，通过从根开始的引用访问对象，以找出无法到达的对象。可到达的对象标记为“活动”，不可到达的对象不标记，将被删除。 因此，所有对象都会被考虑，包括旧一代中分配的对象也会被访问并标记是否可以访问。 据我所知，同时回收年轻一代和老一代是非常困难的，因为这两代人位于内存中不同的连续部分。 但
-
SurvivorRatio参数控制两个幸存者空间的大小。例如，-XX:SurvivorRatio=6将每个幸存者空间和eden之间的比率设置为1:6，每个幸存者空间将是年轻一代的八分之一。 为什么幸存者和伊甸园的空间容量与SurvivorRatio不匹配，如下所示？由制作。
-
这是来自太空的100%新的伊甸园--一个问题吗？ 我的JAVA选项是:-xms10240m-xmx14336m-xx:permsize=192m-xx:maxpermsize=256m-xx:newsize=8192m-xx:maxnewsize=8192m-xx:-disableexplicitgc-xx:+useconcmarksweepgc-xx:cmsinitiatingoccupancy
-
尝试查找这个，但是我遇到的所有问题/答案都谈到了拥有2个幸存者空间的目的。我想了解拥有幸存者空间的一般目的。将物体从伊甸园移动到幸存者有什么好处？
-
我需要帮助理解从和获得的与GC相关的数字如何与传递给Java的设置相关。我在内存为16GB的服务器上使用以下设置启动应用程序（solr）： 的输出开始: 为什么、、和都这么小，而却很大？不应该吗？并且总的堆大小不应该接近吗？当设置为4时，为什么正好是的一半？ 下面是输出的其余部分。它与上面的内容相匹配，并且包括一个部分，我也不知道如何解释。 此外，GC日志表明“期望的幸存者大小”是6.2MB，这也
-
出于某种原因，G1决定增加提交的旧一代内存（尽管使用的内存没有增加），并减少Eden一代提交的内存（从而减少可用空间）。这似乎导致GC年轻一代的运行激增，并使应用程序在一段时间内没有响应。 我们还可以看到CPU使用率和机器中提交的虚拟内存总量（比物理内存总量还要大）出现峰值。也可能会看到磁盘使用率和swapout/swapin的激增。 我的问题是： G1决定减少Eden的大小并大幅增加老一代的pr