JVM——年轻一代和老一代的比例/分配
我正在为max分配8GB内存给Java编写的应用程序。它会内存溢出。我相信年轻一代总是比默认情况下的老一代小（堆的1/4）。而Eden/幸存者1,2在年轻一代内部。我相信在Eden空间中创建了新对象。
即使老一代还没有满，但年轻一代已经完全满了，java应用程序还是会耗尽内存吗？
如果短寿命的对象比长寿命的对象多，那么可以为年轻一代分配更多内存，或者至少将堆的50%分配给年轻一代吗？或者，由于jvm的维护，它应该始终是堆的1/4吗？
共有1个答案
首先，1/4似乎是另一回事。这就是将分配给堆的内存量，除非指定-Xmx（当您在容器中时，以及启用了哪些标志时，这有点不同）。
即使老一代还没有满，但年轻一代已经完全满了，java应用程序还是会耗尽内存吗？
否。当年轻的伊甸园已满时，来自的活动对象将移动到幸存者，当幸存者的对象“存活”足够的GC周期时，它们将移动到旧区域（用XX:MaxTenuringThreshold控制）。当老一代达到某个极限（IHOP在G1中），就会发生一个触及老一代的GC循环。这里有更多细节。
如果短寿命的对象比长寿命的对象多，那么可以为年轻一代分配更多内存，或者至少将堆的50%分配给年轻一代吗？
年轻区域越大，暂停时间越长。年轻GC周期总是停止世界事件，所以让它们太大是不好的。此外，这会影响您的-XX： MaxGCPauseMillis；也不要自己这样做：默认情况下，G1 GC会调整它认为最合适的区域。
-
我们使用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压缩并修复漏洞）？如果是这样，年
-
问题内容： 是否将“静态最终”直接分配给年轻一代或老一代或烫发一代？（我猜想在我认为的时间内，它很可能会降落到旧的gen中。）如果在perm gen中分配了它，那么当在Perm Gen中进行类卸载时，是否会收集垃圾？ 问题答案： 是否将“静态最终”直接分配给年轻一代或老一代或烫发一代？ 变量引用的对象将根据与其他任何对象相同的规则进行分配。它最有可能在年轻一代或老一代中分配（如果它很大，并且适用某
-
问题内容： 我对Heap，Young，Tenured和Perm一代感到困惑。 谁能解释一下？ 问题答案： Java垃圾收集器被称为分 代垃圾收集器 。应用程序中的对象生存的时间长短不一，具体取决于它们的创建位置和使用方式。此处的主要见解在于，针对短期和长期对象使用不同的垃圾回收策略，可以针对每种情况专门优化GC。 松散地说，当对象在新 世代中 “生存”重复的垃圾回收时，它们将迁移到 终身代 。该
-
据我所知，对于旧一代JVM中的空间，它可以用于两个目的， 用于从年轻一代升级到老一代的物品 用于特殊用例中的新对象分配(https://stackoverflow.com/questions/9053144/will-i-encounter-java-lang-outofmemoryerror-even-with-no-lack-of-memory) 我的问题是， 在老一代中，是否还有其他利用空间
-
我有这个程序： 我期望看到的是在年轻一代中创建整数对象，其中一些对象添加到转移到老一代的链表中。所以我希望年轻一代的GC能够始终如一地发生，对象被移动到生存空间，然后再从那里移动到老一代。但我发现的是，老一代的GC一直在发生，年轻一代的GC根本没有发生。这是JVM正在做的某种优化吗？在旧代中直接创建对象的地方？正如您在下图中看到的，年轻的gc只发生了两次，而老的gc发生了41次。仅旧代GC 接下来