标记复制算法在新生代采用“隐式标记+顺序复制”一体化机制，适合“朝生夕死”特性；HotSpot用Eden:Survivor:Survivor=8:1:1三区结构，通过调整新生代大小、SurvivorRatio、MaxTenuringThreshold等参数优化效率。
标记复制算法在新生代中不是“先标记再复制”的两步操作，而是一种边扫描、边复制、边清理的一体化机制——它不维护显式标记位，而是从 GC Roots 出发，顺着引用链直接把存活对象搬进目标区域，同时完成对象搬迁和源区清空。
为什么新生代特别适合这个算法
因为新生代对象绝大多数“朝生夕死”：统计表明约 90%–98% 的对象在第一次 Minor GC 时就已不可达。这意味着每次回收只需处理极少量存活对象（通常不到 2%），复制开销极小。
- 只遍历存活对象，跳过大量垃圾，避免无效扫描
- 复制后目标区天然紧凑，新对象分配只需移动指针（bump-the-pointer），速度快且无碎片
- 源区清空是批量归零，没有逐个释放的开销
HotSpot 中的真实结构：不是均分两块，而是 8:1:1
传统复制算法需两块等大空间，但 HotSpot 采用 Appel 式三区设计：Eden : Survivor0 : Survivor1 = 8 : 1 : 1。这既保留了复制优势，又把空间浪费压到约 10%。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 新对象全部分配在 Eden 区
- Minor GC 时扫描 Eden + 当前 From Survivor 中的存活对象
- 存活对象按年龄判断去向：未达晋升阈值 → 复制到 To Survivor；已达阈值或 To 区放不下 → 直接晋升老年代
- GC 结束后，Eden 和 From Survivor 整体清空，To Survivor 成为新的 From
关键参数怎么影响实际效果
算法本身高效，但能否真正快且稳，取决于几个配置是否匹配业务对象生命周期：
立即学习“Java免费学习笔记（深入）”；
- -XX:SurvivorRatio=8（默认）表示 Eden:Survivor=8:1；若对象平均活 2–3 轮才晋升，可调小为 6，增大 Survivor 容量，减少因溢出导致的提前晋升
- -XX:MaxTenuringThreshold 默认 15，但多数短命对象无需熬满；设为 4–6 更贴合真实场景，避免反复复制
- 新生代总大小建议为堆内存的 1/4～1/3；过大则扫描耗时上升，过小则 GC 频繁、总停顿增加
- 务必禁用 System.gc()，它会触发 Full GC，STW 时间远超 Minor GC
怎么验证它是不是真在高效工作
不能只看“用了复制算法”，要看日志里是否真的轻快：
- 开启详细 GC 日志：-Xlog:gc*,gc+phases=debug -XX:+PrintGCDetails，重点关注 “Root scanning” 和 “Object copy” 阶段耗时占比
- 检查晋升行为：若大量对象未满龄就因 Survivor 溢出而进入老年代，说明 Survivor 空间不足或晋升阈值不合理
- 观察安全点停顿：长计算逻辑阻塞线程进入 Safepoint，会导致 GC 启动延迟，拉长整体 STW
