小GC是否也在幸存者空间和伊甸园空间一起进行？
我知道小GC是在年轻一代的伊甸园空间中进行的。在GC中幸存下来的对象，移动到幸存者空间(From)。一旦(From)空间不足，对象将移至幸存者空间(to)。小GC也在幸存者空间上执行吗？
共有2个答案
从内存分配的开始就发生以下动作：
让我们假设两个幸存者空间为 X，Y 以摆脱混乱
-
< li >当应用程序第一次启动时，创建的对象被移动到Eden空间，在此阶段X，Y为空。 < li >当Eden空间已满时，在Eden空间中会发生较小的GC，它会将活动对象发送到X survivor空间。在这个阶段，X有对象，但是Y是空的。 < li >当下一次较小的GC发生时，它发生在Eden以及X幸存者空间中，剩余的活对象被发送到Y救世主空间。在这个阶段，X是空的，但是Y有活的物体。
所以每次重复这些步骤，你都可以参考这个链接来更好地理解，从上面的解释来看，小规模的垃圾收集确实也发生在幸存者空间。
幸存者空间是年轻一代的一部分，因此将在幸存者空间上执行次要gc。如果一个对象在许多次要gc中幸存下来，那么它将被移动到旧一代。
有关详细信息：http://www.cubrid.org/blog/dev-platform/understanding-java-garbage-collection/
-
在JVM重启之前，java（8）内存容量是否会减少？ 我正在使用jstat-gc转储内存信息，下面是两天的快照。与第一个快照相比，第二个快照对SC1和EC的资本金更少。 有人能帮助/解释为什么我看到这种行为吗？这是预期的吗？
-
你能回答我一个关于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
-
我需要帮助理解从和获得的与GC相关的数字如何与传递给Java的设置相关。我在内存为16GB的服务器上使用以下设置启动应用程序（solr）： 的输出开始: 为什么、、和都这么小，而却很大？不应该吗？并且总的堆大小不应该接近吗？当设置为4时，为什么正好是的一半？ 下面是输出的其余部分。它与上面的内容相匹配，并且包括一个部分，我也不知道如何解释。 此外，GC日志表明“期望的幸存者大小”是6.2MB，这也
-
我们的服务器应用程序似乎在一段时间内表现正常，但过了一段时间后，生存空间将填满100%，从那时起，堆使用量增加，GC周期（次要和主要）变得越来越频繁，最终堆耗尽。 这是“jstat-gcutil”的一部分 我的问题是这种应用程序行为背后的主要原因是什么？是太小的年轻空间或堆，其他一些JVM参数，还是只是一个普通的旧内存泄漏？ 解决这个问题的最佳策略是什么，GC调优还是应用程序重构？ JDK 1.6
-
尝试查找这个，但是我遇到的所有问题/答案都谈到了拥有2个幸存者空间的目的。我想了解拥有幸存者空间的一般目的。将物体从伊甸园移动到幸存者有什么好处？
-
对于Java 8之后的JVM 当metaspace的大小