JVM内存分配与垃圾回收需协同优化，核心是按对象生命周期合理分配：短命对象入新生代，长存对象入老年代；通过参数调优（如PretenureSizeThreshold、SurvivorRatio、TLAB等）和收集器适配（G1/ZGC特性），抑制异常晋升与Full GC。
JVM 垃圾回收与内存分配不是孤立过程，而是紧密联动的系统行为。优化的关键在于让对象“该在哪分配、就分在哪”，减少跨代移动、避免提前晋升、抑制 Full GC。实际效果取决于参数设置、对象生命周期特征和收集器选择，而非单纯调大堆内存。
按对象生命周期匹配分配区域
新生代（Eden + Survivor）专为短命对象设计，老年代则承载长期存活对象。若大量本该短期存活的对象被错误送入老年代，会快速填满空间并触发代价高昂的 Full GC。
- 控制大对象直入老年代：用 -XX:PretenureSizeThreshold 设置阈值（如 1MB），避免大数组/长字符串在 Eden 分配失败后被迫晋升；注意该参数仅对 Serial 和 ParNew 收集器生效
- 防止 Survivor 溢出导致被动晋升：通过 -XX:SurvivorRatio（默认 8）调整 Eden 与单个 Survivor 比例；若日志中频繁出现 “to-space overflow”，说明 Survivor 太小，可适当调高比例或启用动态扩容（G1/ZGC 默认支持）
- 观察对象年龄分布：用 -XX:+PrintGCDetails 查看每次 Minor GC 后各年龄对象大小，若某次 GC 后年龄 2 的对象已占 Survivor 50% 以上，说明动态年龄判断已触发晋升——此时应检查是否对象生命周期异常变长，或 Survivor 容量不足
善用 TLAB 减少分配竞争
多线程高频创建小对象时，若所有线程都争抢 Eden 的公共指针，会引发同步开销。TLAB（Thread Local Allocation Buffer）为每个线程预划一小块私有 Eden 空间，分配无需加锁。
- 默认开启（-XX:+UseTLAB），一般无需关闭；若应用线程数极多且单个 TLAB 过大造成 Eden 浪费，可用 -XX:TLABSize 或 -XX:TLABWasteTargetPercent 微调
- 配合 -XX:+ResizeTLAB（默认开启），让 JVM 根据线程分配速率动态调整 TLAB 大小，提升空间利用率
- TLAB 分配失败时会退化为 Eden 公共分配，若日志中频繁出现 “TLAB allocation failure”，说明 TLAB 太小或对象普遍偏大，需结合对象大小分布分析
收集器与参数协同调优
不同收集器对分配行为的响应逻辑不同，不能套用统一参数。例如 G1 不再严格区分 Eden/Survivor，而是基于 Region 动态管理；ZGC 则完全消除分代概念。
- 使用 G1 时：关闭显式 SurvivorRatio 设置，改用 -XX:MaxGCPauseMillis（如 200ms）驱动自适应回收；通过 -XX:G1NewSizePercent 和 -XX:G1MaxNewSizePercent 控制新生代占比（默认 5%~60%），避免新生代过小导致频繁 Young GC
- 避免错误组合：如启用 -XX:+UseG1GC 却仍配置 -XX:PretenureSizeThreshold，该参数对 G1 无效，反而干扰判断
- 监控晋升行为：添加 -XX:+PrintTenuringDistribution，查看每次 GC 后各年龄对象数量，验证晋升阈值（-XX:MaxTenuringThreshold，默认 15）是否合理；多数业务中设为 6～8 更贴合真实对象寿命
识别并拦截不合理晋升源头
老年代膨胀往往不是因为对象真“老”，而是分配策略或代码行为导致本不该活久的对象提前卡在老年代。
- 检查缓存类对象：如 HashMap、ConcurrentHashMap 中长期持有的 value，若未及时清理或未使用弱引用，会在多次 GC 后自然晋升，最终撑爆老年代
- 警惕静态集合：static List/Map 存储临时对象，生命周期与类绑定，极易成为 GC Roots 并阻止回收
- 避免手动触发 GC：System.gc() 可能强制触发 Full GC，尤其在 CMS/G1 中会干扰正常回收节奏；生产环境应禁用并用 -XX:+DisableExplicitGC
