是否将“静态最终”直接分配给年轻一代或老一代或烫发一代?(我猜想在我认为的时间内,它很可能会降落到旧的gen中。)如果在perm
gen中分配了它,那么当在Perm Gen中进行类卸载时,是否会收集垃圾?
是否将“静态最终”直接分配给年轻一代或老一代或烫发一代?
static final
变量引用的对象将根据与其他任何对象相同的规则进行分配。它最有可能在年轻一代或老一代中分配(如果它很大,并且适用某些其他条件)。
将通过new
执行一些任意代码来分配对象。JVM无法知道该对象(最终)将被分配给static final
变量。
包含静态变量的框架空间可能在permGen中分配。当然,这不是常规的Java对象。
如果在perm gen中分配了它,那么在Perm Gen中进行类卸载时,是否将其垃圾回收?
这取决于permGen是否被垃圾收集。在现代JVM中,是这样,我希望由卸载的类静态变量引用的对象将在同一GC周期或下一个GC周期中被垃圾回收…假设它们是不可访问的。
无论哪种方式,都不应将应用程序编码为依赖于这些细节中的任何一个。它们是特定于JVM的。
请注意,从Java 8开始,由于permgen不再存在,因此该问题不存在。
我们使用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日志:
我正在为max分配8GB内存给Java编写的应用程序。它会内存溢出。我相信年轻一代总是比默认情况下的老一代小(堆的1/4)。而Eden/幸存者1,2在年轻一代内部。我相信在Eden空间中创建了新对象。 即使老一代还没有满,但年轻一代已经完全满了,java应用程序还是会耗尽内存吗? 如果短寿命的对象比长寿命的对象多,那么可以为年轻一代分配更多内存,或者至少将堆的50%分配给年轻一代吗?或者,由于jv
我有这个程序: 我期望看到的是在年轻一代中创建整数对象,其中一些对象添加到转移到老一代的链表中。所以我希望年轻一代的GC能够始终如一地发生,对象被移动到生存空间,然后再从那里移动到老一代。但我发现的是,老一代的GC一直在发生,年轻一代的GC根本没有发生。这是JVM正在做的某种优化吗?在旧代中直接创建对象的地方?正如您在下图中看到的,年轻的gc只发生了两次,而老的gc发生了41次。仅旧代GC 接下来
问题内容: 我对Heap,Young,Tenured和Perm一代感到困惑。 谁能解释一下? 问题答案: Java垃圾收集器被称为分 代垃圾收集器 。应用程序中的对象生存的时间长短不一,具体取决于它们的创建位置和使用方式。此处的主要见解在于,针对短期和长期对象使用不同的垃圾回收策略,可以针对每种情况专门优化GC。 松散地说,当对象在新 世代中 “生存”重复的垃圾回收时,它们将迁移到 终身代 。该
在某个时刻,我的应用程序开始创建许多临时阵列,这是预期的行为,我想给年轻一代提供大量空间,所以临时阵列不会被提升到终身一代。 JVM选项: 在某些时候,我的GC日志开始看起来像这样: 我非常困惑的事实,年轻一代的大小是629120K(=629M),而我预计它是约1/2(因为NewRatio=2)的终身一代大小这是158690816K(=158G)。终身大小生成对应于NewRatio和Xms的预期,
最近我一直在阅读Java不同世代的对象分配。大多数时候,新对象在伊甸园(年轻一代的一部分)中分配,然后如果满足以下任何标准,它们就会晋升为老一代。 (1) 当从伊甸园(或)另一个幸存者空间(从)复制对象时,对象的年龄已达到寿命阈值 (2)幸存者空间(到)已满 但是也有一种特殊情况,即对象直接在旧一代中分配,而不是从年轻一代中提升。当我们试图创建的对象很大(可能是几个MB的数量级)时,就会发生这种情