新生代默认占堆的1/3，由-xx:newratio=2决定（老年代:新生代=2:1）；newratio越大minor gc越频繁，越小则单次耗时越长；线上建议显式设-xmn而非依赖newratio。
新生代为什么默认占堆的 1/3？
不是硬编码，而是 HotSpot 默认参数 -XX:NewRatio=2 决定的：老年代 : 新生代 = 2 : 1，所以新生代占堆总大小的 1/3。改这个值会影响 GC 频率和单次停顿时间——NewRatio 越大，新生代越小，Minor GC 更频繁；越小则新生代越大，可能把本该进老年代的短期对象多留一阵，但会拉长每次 Minor GC 时间。
常见错误是只调 -Xmx 却忽略 -XX:NewRatio 或 -Xmn，结果堆变大了，新生代却没跟着扩，GC 压力反而集中到小空间里。
- 线上服务建议显式设置
-Xmn（比如-Xmn512m），比依赖NewRatio更可控 - 用
jstat -gc <pid></pid>观察S0C/S1C/EC总和是否接近预期新生代大小 - 注意 JDK 8u20 之后 G1 默认不认
NewRatio，它用的是自适应策略
对象直接分配到老年代的 3 种情况
不是所有对象都从 Eden 开始“熬资历”。以下情况会跳过新生代，直入老年代：
- 大对象（如超长数组）：JVM 判定其大小 >
-XX:PretenureSizeThreshold（默认 0，即禁用），就直接进老年代。避免在新生代中复制多次 - 长期存活对象：在 Survivor 区每熬过一次 Minor GC，年龄 +1；当年龄 ≥
-XX:MaxTenuringThreshold（默认 15），下次 GC 就晋升老年代 - Survivor 空间不足：一次 Minor GC 后，存活对象总和 > Survivor 容量，超出部分直接进老年代（也叫“担保失败”）
典型现象是 jstat 显示 OU（老年代已用）突增，但 YGCT 没明显变化——说明对象压根没走新生代。
为什么 CMS 和 G1 下“老年代空间不足”不一定触发 Full GC？
CMS 在并发标记阶段发现老年代碎片化或剩余空间不足时，会触发 Concurrent Mode Failure，此时退化为 Serial Old 回收，效果等价于 Full GC；而 G1 在 Evacuation 失败时会启动 Full GC，但 JDK 9+ 的 G1 已尽量避免——它会先尝试扩容堆（如果 -XX:MaxHeapFreeRatio 允许），再 fallback。
容易踩的坑是监控只看 OGCMN/OGCMX，却忽略 OGC（当前老年代容量）是否被动态调整过。G1 的 initiating occupancy percent 是按整个堆算的，不是老年代单独占比。
- 用
jinfo -flag +PrintGCDetails <pid></pid>打开日志后，留意 GC 日志里的concurrent mode failure或to-space overflow - CMS 下建议调低
-XX:CMSInitiatingOccupancyFraction（比如 70），别等老年代快满才启动并发收集 - G1 不推荐手动设
-XX:MaxTenuringThreshold，它的晋升逻辑由活跃度预测驱动
对象分配流程中那些“看不见”的检查
每次 new 一个对象，JVM 不只是往 Eden 里填内存。它还会做几件关键但常被忽略的事：
- TLS（Thread Local Allocation Buffer）检查：每个线程有独立 Eden 小块，避免加锁；若 TLS 耗尽，才触发全局 Eden 分配，可能引起竞争
- TLAB 大小动态调整：通过
-XX:+UseTLAB（默认开启）控制，-XX:TLABSize可设初始值，但 JVM 会根据分配速率自动伸缩 - 逃逸分析未生效时，即使方法内 new 的对象也可能被栈上分配——前提是 JIT 编译器确认该对象不会逃出方法作用域
最隐蔽的问题是：高并发下 TLAB 频繁耗尽，导致大量同步分配，gc.log 里 Allocation Failure 出现频率远高于对象创建频率。这时该看 -XX:+PrintTLAB 日志，而不是只盯着 Eden 使用率。
