scavenge gc是否由from空间填满引发需结合gc日志中eden使用率判断：若回收前eden使用量稳定趋近上限（如15359k/15360k）则为真填满；若波动大且常低于95%但gc频繁，则是自适应策略主动收缩所致。
Scavenge GC 触发时如何确认是否真由内存分配填满 From 空间引起
很多高内存占用场景下，Scavenge 频繁触发，但实际并不是因为 From 空间被“填满”，而是因为 -XX:MaxGCPauseMillis 或 -XX:GCTimeRatio 等吞吐量策略主动降级了新生代大小，导致空间提前耗尽。JVM 在启用 -XX:+UseAdaptiveSizePolicy（默认开启）时会动态收缩 Eden 区，哪怕堆还没压满，也会频繁触发 Scavenge。
验证方式是加 JVM 参数：-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，观察日志中每次 Scavenge 前的 Eden 使用率。如果反复出现类似 Eden: 15360K->0K(15360K) 但回收前只用了 14200K，说明是策略性收缩而非真实爆满。
- 真正填满触发：日志中 Eden 使用量稳定趋近于容量上限（如
15359K/15360K） - 策略性触发：Eden 使用量波动大，且常低于 95%，但 GC 频率异常高
- 注意
Survivor区过小也会间接抬高 From 空间压力——因为对象无法顺利晋升或复制，被迫在 From/To 间反复 bounce
拷贝开销不等于对象数量 × 对象大小，关键看活跃对象图深度
Scavenge 的实际拷贝成本取决于活跃对象构成的引用图规模，而不是简单统计“多少 MB 被复制”。Cheney 算法采用 breadth-first 拷贝 + forwarding pointer，一旦某个对象被复制，其所有可达子对象都会被递归发现并拷贝；但若一个大对象只被根直接引用，它不会拖累整个子图——只有从根出发能遍历到的对象才参与拷贝。
典型高开销场景是：单个长生命周期对象（比如缓存容器）持有数百个短命子对象，且这些子对象之间还有交叉引用。这时即使总内存占用不大，Scavenge 仍需 traverse 整个网状结构，产生大量 cache miss 和指针更新。
- 用
-XX:+PrintAdaptiveSizePolicy查看每次 GC 后 Survivor 区的占用变化，突增说明有大量对象“卡”在新生代未晋升 - 用
jmap -histo:live <pid></pid>对比两次Scavenge间隔间的对象增长，重点看java.util.HashMap$Node、char[]、byte[]这类易膨胀类型 - 避免在新生代内构造深层嵌套结构（如树形缓存、递归 builder），这类结构会让 Cheney 扫描路径指数级延长
From/To 空间交换本身几乎零开销，但对象重定位会影响 CPU cache 局部性
空间交换只是交换两个指针（from_space_start ↔ to_space_start），不涉及内存搬移，所以不耗时。真正影响性能的是对象被复制后，在 To 空间中按顺序紧凑排列，导致原本局部性良好的访问模式被打散。尤其当业务代码习惯按创建时间顺序遍历对象（如日志 buffer、滑动窗口），而 Scavenge 后对象物理地址完全重排，就会引发大量 cache line miss。
这个问题在低延迟场景（如金融行情处理）中尤为明显，表现为 GC 后单次请求延迟毛刺升高，但 GC 日志里 pause time 并不高。
- 可通过
-XX:+PrintGCApplicationStoppedTime确认 STW 时间是否真短；若 STW 很低但应用延迟抖动大，大概率是 cache 影响 - 不要依赖
-XX:SurvivorRatio盲调比例——过大的 Survivor 区反而延长对象在新生代停留时间，放大重排影响 - 对延迟敏感服务，可尝试禁用自适应策略：
-XX:-UseAdaptiveSizePolicy，固定 Eden/Survivor 大小，让内存布局更可预测
V8 与 JVM 的 Scavenge 行为差异容易被误判为同一机制
虽然都叫 Scavenge，但 V8（用于 Node.js）和 JVM 的实现差异极大。V8 新生代默认仅 16MB（-max-new-space-size），且 To 空间在 GC 启动时就预留好；而 JVM 的 Parallel Scavenge 默认 Eden 可达数百 MB，且 Survivor 区大小受 -XX:SurvivorRatio 控制，To 空间本质是 Survivor 的一半。
这意味着：同一份 Node.js 应用迁移到 Java 时，若简单照搬 V8 的“避免大对象进入新生代”经验，可能过度限制 JVM 的 Eden 区，反而导致更频繁 GC 和更高拷贝开销。
- V8 中
Scavenge拷贝失败会直接 promotion 到老生代；JVM 中对象必须满足年龄阈值（-XX:MaxTenuringThreshold）或 Survivor 溢出才晋升 - JVM 的
Parallel Scavenge会主动压缩存活对象（compact），V8 不压缩，只 copy + bump pointer - 分析工具不能混用：V8 用
--trace-gc，JVM 用-XX:+PrintGCDetails；日志字段含义完全不同，比如 V8 的scavenge时间包含 write barrier 开销，JVM 不计入
Eden 占用率调参，却忽略了对象图的形状和访问模式才是隐藏的瓶颈。
