当前位置: 首页 > 知识库问答 >
问题:

缺失的记忆:年轻一代的规模只包括一个幸存者空间

吕宸
2023-03-14

在Java堆中,我预计年轻一代的规模将是伊甸园空间和两个幸存者空间(从空间到空间)的规模之和:

[young gen size] = [eden space size] + [from space size] + [to space size]

但是,GC 日志(使用 XX:PrintHeapAtGC)指出,年轻一代的大小是伊甸园空间的大小之和,只有一个幸存者空间:

[young gen size] = [eden space size] + [from space size]

为什么年轻一代的大小只包括一个幸存者空间的大小?

也许是因为任何时候只有一个幸存者空间可用?但是两个幸存者空间都存在,所以两个幸存者空间都应该为新一代的规模做出贡献吗?

气相色谱日志

{Heap before GC invocations=48 (full 17):
par new generation   total 943744K, used 891496K [0x000000073ae00000, 0x000000077ae00000, 0x000000077ae00000)
  eden space 838912K, 100% used [0x000000073ae00000, 0x000000076e140000, 0x000000076e140000)
  from space 104832K,  50% used [0x000000076e140000, 0x000000077149a040, 0x00000007747a0000)
  to   space 104832K,   0% used [0x00000007747a0000, 0x00000007747a0000, 0x000000077ae00000)

从中:

[young gen size] = [eden space size] + [from space size]
     943744K     =      838912K      +      104832K

共有1个答案

云远
2023-03-14

在任何时候,幸存者空间中的一个总是空的,因此不能认为它是可用的。

 类似资料:
  • 我们使用G1收集器<当一个年轻的GC发生时(不是混合GC),堆的变化:[Eden:3666.0M(3666.0M)- 堆的变化为4819.1M(5346.0-526.9) 伊甸园改变了3666.0(3666.0-0.0)和幸存者-34M(20-54);为什么堆的变化不等于伊甸园和幸存者的总和(4819.1不等于(3666.0-34))?年轻的GC清除对象在老一代? gc日志:

  • 如果我错了,请随时指正。在JVM堆中,有老一代和年轻一代两代。在做全GC时,在老一代中,有像紧凑空间和修复漏洞这样的繁重操作,这会使JVM挂起。而我发现在年轻一代中,应用了一个轻量级的GC,从我的搜索结果中还有一个叫做Eden的区域涉及年轻一代。但是,在搜索了很多文档后,我对年轻一代中的GC仍然有两个困惑, 在年轻一代中,GC似乎不像老一代GC那样工作(即老一代GC压缩并修复漏洞)?如果是这样,年

  • 我正在为max分配8GB内存给Java编写的应用程序。它会内存溢出。我相信年轻一代总是比默认情况下的老一代小(堆的1/4)。而Eden/幸存者1,2在年轻一代内部。我相信在Eden空间中创建了新对象。 即使老一代还没有满,但年轻一代已经完全满了,java应用程序还是会耗尽内存吗? 如果短寿命的对象比长寿命的对象多,那么可以为年轻一代分配更多内存,或者至少将堆的50%分配给年轻一代吗?或者,由于jv

  • 问题内容: 当伊甸园空间年轻时已满,将触发次要GC。在次要GC过程中,伊甸园和一个源Survivor空间中的非自由对象将被复制到另一个目标Survivor空间。 我的问题是,如果目标“幸存者”空间已满,次要GC如何处理? 问题答案: 如果不可能执行/完成次要收集,则将执行主要/完整收集。通常使用标记扫描紧凑算法而不是复制算法来完成此操作……这是完整收集昂贵的原因之一。 但是最终(如果您继续填充堆)

  • 你能回答我一个关于JVM垃圾收集过程的问题吗? 为什么堆被分为伊甸园、幸存者空间和老一代? 当一个年轻的疏散被处理时,通过从根开始的引用访问对象,以找出无法到达的对象。可到达的对象标记为“活动”,不可到达的对象不标记,将被删除。 因此,所有对象都会被考虑,包括旧一代中分配的对象也会被访问并标记是否可以访问。 据我所知,同时回收年轻一代和老一代是非常困难的,因为这两代人位于内存中不同的连续部分。 但

  • 我预先承认,这个问题非常类似于:大量cms标记/备注暂停,即使旧版还没有满一半,并且无明显原因开始使用终身收藏。我发帖是因为1。这些线已经有1年多的历史了,还有2年。我希望学习如何找到这种行为的根本原因。 我们有一个OAS/OC4J(这不是我们的错!)运行在RHEL5/Redhat 5.11、Java 6上的全天候Java应用服务器。这在内存方面已经稳定了很多年,直到最近,由于频繁的CMS终身空间