垃圾收集年轻一代扫描
我在尝试理解垃圾收集机制，我在研究代际算法，我有一个关于年轻人和老年人的代沟的问题。我读到，在年轻一代开始收集物品，GC是从GC根开始标记它们，以找到活的，通常它会将它们复制到幸存者空间，清除年轻一代区域，然后瞧。
我不明白，如果我们从GC根开始，我们开始遍历活动对象，我们不是也在旧一代中找到了对象吗？这是否意味着，当我们击中旧空间中的一个物体时，我们会在那个点上停止跟踪参照物？
共有2个答案
当GC在年轻一代中运行时，它被称为小集合。旧一代的对象与这种类型的集合无关。
是的，可以从根直接访问的对象被标记为活动对象，但它们可以位于堆的其他位置，因此它们可以是旧一代的对象。
即使可以访问Old Gen对象，次要收集也不会回收Old Gen中的垃圾。
引用热点文件：
当年轻一代填满时，它会导致只有年轻一代被收集的小收集；其他代的垃圾不被回收
对我来说，这意味着GC将通过对象图，可能会在OldGen中找到垃圾，但不会回收它。
我发现了这篇IBM文章，它很好地解释了代际引用跟踪在HotSpot GC中的工作原理。
虽然我没有直接检查过这一点，但根据常识，每次遇到旧一代的对象时，对象图遍历都会被缩减。注意，这种检查非常便宜：对指针值进行简单的范围检查就足以确定对象在堆区域中的位置。
然而，还有另一个关键点需要考虑：如果一个年轻的对象只能通过一个旧的对象来访问，该怎么办？显然，必须以某种方式考虑老一代。
进入卡片表：这是每个堆区域前面的一个备份结构，其中保存着该区域的压缩“位图”视图，这样每个位对应于256字节的堆。每次更新引用类型的变量时，卡片表中相应的位都被提升为1，表示“脏”。
卡片表就位后，每个YG集合都会发生以下情况：扫描所有标记为“脏”的堆块，寻找指向年轻一代中对象的指针。通过这种方式找到的每个对象都被认为是可到达的。
上面的一个例子：通过一个旧对象可以访问的年轻对象，而这个旧对象同时变成了垃圾，将被认为是可以访问的，并且会污染堆，直到一个主要的GC发生。
-
如果我错了，请随时指正。在JVM堆中，有老一代和年轻一代两代。在做全GC时，在老一代中，有像紧凑空间和修复漏洞这样的繁重操作，这会使JVM挂起。而我发现在年轻一代中，应用了一个轻量级的GC，从我的搜索结果中还有一个叫做Eden的区域涉及年轻一代。但是，在搜索了很多文档后，我对年轻一代中的GC仍然有两个困惑， 在年轻一代中，GC似乎不像老一代GC那样工作（即老一代GC压缩并修复漏洞）？如果是这样，年
-
问题内容： 当伊甸园空间年轻时已满，将触发次要GC。在次要GC过程中，伊甸园和一个源Survivor空间中的非自由对象将被复制到另一个目标Survivor空间。 我的问题是，如果目标“幸存者”空间已满，次要GC如何处理？ 问题答案： 如果不可能执行/完成次要收集，则将执行主要/完整收集。通常使用标记扫描紧凑算法而不是复制算法来完成此操作……这是完整收集昂贵的原因之一。 但是最终（如果您继续填充堆）
-
当伊甸园空间充满年轻一代时，小GC将被触发。在次要GC过程中，伊甸园和一个源幸存者空间中的非自由对象将被复制到另一个目标幸存者空间。 我的问题是，如果目标幸存者空间已满，minor GC如何处理？
-
在收集年轻一代内存时，JVM收集器只扫描那些属于年轻一代的根对象（堆中的OBEJCT可从根集中直接访问），还使用写屏障支持的卡表/记忆集来确定旧一代的区域，这些区域可能包含对年轻一代中对象的引用的对象。 我的问题是，如果年轻的收集器确定年轻一代中的某个特定对象只有来自老一代中某个对象的一个外部引用，它如何知道老一代对象本身是否是垃圾，从而使年轻一代对象“活动”且不符合收集条件？例如，在老一代中，可
-
Kubernetes 垃圾收集器的角色是删除指定的对象，这些对象曾经有但以后不再拥有 Owner 了。 注意：垃圾收集是 beta 特性，在 Kubernetes 1.4 及以上版本默认启用。 Owner 和 Dependent 一些 Kubernetes 对象是其它一些的 Owner。例如，一个 ReplicaSet 是一组 Pod 的 Owner。具有 Owner 的对象被称为是 Owner
-
本文向大家介绍Java垃圾收集，包括了Java垃圾收集的使用技巧和注意事项，需要的朋友参考一下 示例 C ++方法-新增和删除 在像C ++这样的语言中，应用程序负责管理动态分配的内存所使用的内存。当使用new运算符在C ++堆中创建对象时，需要相应地使用delete运算符来处置该对象： 如果程序忘记了delete一个对象而只是“忘记”了该对象，则关联的内存将丢失给应用程序。这种情况的术语是内存泄