Minor GC 后 Survivor 区中存活对象是如何分布的
在 minor gc 执行完毕后，survivor 区的变化主要体现为对象从 eden 区和某个 survivor 区（from）复制到另一个 survivor 区（to），并清空 from 区。通过观察日志中的 psyounggen 或 g1 young generation 部分，可以清晰地看到内存使用量的跳变：eden 区的使用量会大幅下降，而 to 区的用量则会上升，这反映了存活对象被成功复制到了新的空间。
import java.util.ArrayList;
import java.util.List;
public class GcTest {
public static void main(String[] args) {
List<byte> list = new ArrayList();
// 分配大量数据填满 Eden
for (int i = 0; i <p>运行上述代码并开启 GC 日志（如 <code>-XX:+PrintGCDetails</code>），你会观察到 <code>PSYoungGen: total 3584K, used 2048K [0x000000076b900000, 0x000000076c000000, 0x000000076c000000)</code> 这样的行。重点关注方括号内的地址范围以及逗号后的数值，第一个数值是总容量，第二个是使用量。GC 前 Eden 占用高，GC 后 Eden 占用低，而 To 区（通常是第二个子区域）会有非零的使用量，这就是存活对象的去向。</p>
<h2>为什么 Survivor 区有时会出现“碎片化”或无法容纳大对象</h2>
<p>当 Survivor 区发生空间担保失败（Space Guarantee Failure）时，意味着 Eden 区中存活的对象体积超过了 To 区的剩余容量。此时 JVM 不会进行复制，而是直接将这些大对象晋升到老年代。查看日志时，如果发现 <code>survivor space</code> 的使用量没有显著增加，或者紧接着出现了 <code>Promotion Failed</code> 和老年代的 GC 记录，就说明发生了这种情况。</p>
<p><img src="https://img.php.cn/upload/article/001/242/473/179438456215365.png?x-oss-process=image/resize,p_40" alt="Java 垃圾回收 中 GC日志分析 中 Survivor区变化怎么看"></p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill12496" title="Java 开发专家"><img
src="https://img.php.cn/upload/skill/001/246/273/6adaf20d79f23518.jpg" alt="Java 开发专家" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill12496" title="Java 开发专家" class="overflowclass">Java 开发专家</a>
<p class="overflowclass">精通 Java 21+，掌握虚拟线程、模式匹配和 Spring Boot 3.x 等现代特性。是 Java 生态系统（包括 GraalVM、Project Lo</p>
</div>
<a rel="nofollow" href="/xiazai/skill12496" title="Java 开发专家" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<pre class="brush:php;toolbar:false;">import java.util.ArrayList;
import java.util.List;
public class LargeObjectTest {
public static void main(String[] args) {
List<byte> list = new ArrayList();
// 尝试分配一个较大的对象
list.add(new byte[1024 * 100]);
// 触发 GC
System.gc();
}
}</byte>
在日志中寻找 [Times: user=... sys=... real=...]` 之前的行。如果看到 Full GC (Ergonomics) 或者老年代使用量激增，说明 Survivor 区太小，无法容纳所有存活对象。可以通过调整 -XX:SurvivorRatio 来增大 Survivor 区，从而减少这种直接晋升的情况。
长期存活的对象在 Survivor 区中如何决定晋升年龄
Survivor 区中的对象每熬过一次 Minor GC，其年龄就会增加 1。当对象的年龄达到阈值（默认为 15，由 -XX:MaxTenuringThreshold 控制）时，它将在下一次 GC 时被移动到老年代。日志中通常不会直接打印每个对象的年龄，但可以通过连续多次 Minor GC 后 Survivor 区使用量的稳定增长模式，结合老年代的缓慢增长来推断晋升行为。
要验证这一点，可以编写一个程序，让对象在 Survivor 区中反复存活多次。例如，创建一个循环，在每次迭代中分配新对象并触发 GC，同时保留旧对象引用。观察日志中 PSYoungGen 的变化，你会发现随着迭代次数增加，Survivor 区的使用量会逐渐趋于稳定，而老年代的使用量会阶梯式上升，这表明对象正在按年龄阈值逐步晋升。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
