年轻一代的垃圾收集问题[已关闭]
当伊甸园空间充满年轻一代时，小GC将被触发。在次要GC过程中，伊甸园和一个源幸存者空间中的非自由对象将被复制到另一个目标幸存者空间。
我的问题是，如果目标幸存者空间已满，minor GC如何处理？
共有2个答案
年轻一代有三个部分：伊甸园空间、Survivor1和Survivor2。这些只是年轻一代的逻辑划分。所以物体从伊甸园空间复制到Survivor1，然后复制到Survivor2。
所以一般来说，小收藏意味着收藏发生在年轻一代。若年轻一代已经满了，那个么这个对象就会被复制到老一代。
再次强调，收藏是次要还是主要取决于多个因素，其中之一是年轻一代的空间可用性。所以，如果年轻一代有足够的空间分配对象，那么它将是次要的收集。但如果YG中没有足够的可用空间，那么同一个系列可能会变成主要的。
JVM规范也没有提到垃圾收集。因此，JVM实现者有自己的策略。
如果不可能执行/完成次要集合，则执行主要/完整集合。这通常使用标记-扫描-紧凑算法而不是复制算法来完成...这是完整集合昂贵的原因之一。
但最终（如果你继续填充堆），一个完整的集合将无法回收足够的空间继续，并且会抛出一个OOME。（或者，如果您使用的是-XX:usegcoveredlimit，当在GC中花费的时间百分比超过指定阈值时，将抛出OOME。）
-
问题内容： 当伊甸园空间年轻时已满，将触发次要GC。在次要GC过程中，伊甸园和一个源Survivor空间中的非自由对象将被复制到另一个目标Survivor空间。 我的问题是，如果目标“幸存者”空间已满，次要GC如何处理？ 问题答案： 如果不可能执行/完成次要收集，则将执行主要/完整收集。通常使用标记扫描紧凑算法而不是复制算法来完成此操作……这是完整收集昂贵的原因之一。 但是最终（如果您继续填充堆）
-
如果我错了，请随时指正。在JVM堆中，有老一代和年轻一代两代。在做全GC时，在老一代中，有像紧凑空间和修复漏洞这样的繁重操作，这会使JVM挂起。而我发现在年轻一代中，应用了一个轻量级的GC，从我的搜索结果中还有一个叫做Eden的区域涉及年轻一代。但是，在搜索了很多文档后，我对年轻一代中的GC仍然有两个困惑， 在年轻一代中，GC似乎不像老一代GC那样工作（即老一代GC压缩并修复漏洞）？如果是这样，年
-
我在尝试理解垃圾收集机制，我在研究代际算法，我有一个关于年轻人和老年人的代沟的问题。我读到，在年轻一代开始收集物品，GC是从GC根开始标记它们，以找到活的，通常它会将它们复制到幸存者空间，清除年轻一代区域，然后瞧。 我不明白，如果我们从GC根开始，我们开始遍历活动对象，我们不是也在旧一代中找到了对象吗？这是否意味着，当我们击中旧空间中的一个物体时，我们会在那个点上停止跟踪参照物？
-
在收集年轻一代内存时，JVM收集器只扫描那些属于年轻一代的根对象（堆中的OBEJCT可从根集中直接访问），还使用写屏障支持的卡表/记忆集来确定旧一代的区域，这些区域可能包含对年轻一代中对象的引用的对象。 我的问题是，如果年轻的收集器确定年轻一代中的某个特定对象只有来自老一代中某个对象的一个外部引用，它如何知道老一代对象本身是否是垃圾，从而使年轻一代对象“活动”且不符合收集条件？例如，在老一代中，可
-
我在读关于Java的垃圾收集和finalize（）方法的书，有一些疑问引起了我的注意。抱歉，如果你认为这些怀疑真的很愚蠢。 > 垃圾收集器如何知道它需要执行？例如，我有一个部署在服务器上的应用程序，那么垃圾收集器什么时候执行？它是否定期执行，或者当一些（比如1MB）垃圾被收集并执行触发器时，或者它只是随机的，没有办法确定它什么时候执行？ 由于垃圾回收机制没有发生，它如何降低应用程序的性能？ 假设我
-
Kubernetes 垃圾收集器的角色是删除指定的对象，这些对象曾经有但以后不再拥有 Owner 了。 注意：垃圾收集是 beta 特性，在 Kubernetes 1.4 及以上版本默认启用。 Owner 和 Dependent 一些 Kubernetes 对象是其它一些的 Owner。例如，一个 ReplicaSet 是一组 Pod 的 Owner。具有 Owner 的对象被称为是 Owner