jvm内存分配策略是动态协同机制，对象按特征分流至eden区、老年代或tlab；存活年龄达15或survivor空间不足时晋升老年代；分配直接影响gc频率与停顿。
JVM 内存分配策略不是固定规则，而是围绕对象生命周期、GC 效率和系统吞吐量动态协同的一套机制。它直接决定对象去哪儿、待多久、何时被回收——这些选择稍有偏差，就可能引发频繁 GC、内存碎片或停顿飙升。
对象去哪儿：三类主流分配路径
新对象并非“一刀切”进堆某处，JVM 会按特征自动分流：
- Eden 区优先分配：95% 以上普通对象（如 String、HashMap、DTO 实例）默认在新生代 Eden 区分配。这是最快路径，依赖指针碰撞（Bump Pointer）实现近乎零开销分配。
-
大对象直入老年代：连续大内存需求对象（如 byte[2MB]、ArrayList(100w 元素)）绕过新生代，直接进入老年代。避免在 Minor GC 中反复复制，减少 Eden/Survivor 区压力。阈值由
-XX:PretenureSizeThreshold=2097152（2MB）控制，单位为字节。 -
TLAB 线程私有分配：每个线程独占一小块 Eden 子区域（Thread Local Allocation Buffer），分配无需加锁。当 TLAB 不足时才同步申请新块——既降低竞争，又保持分配效率。可通过
-XX:+UseTLAB（默认开启）和-XX:TLABSize微调。
对象待多久：年龄与晋升的平衡逻辑
对象不会永远留在 Eden，它的“成长路径”由存活次数和空间压力共同决定：
- 每次 Minor GC 后仍存活的对象，从 Eden 移入 Survivor（From → To），年龄 +1；
- 默认年龄达 15 才晋升老年代（
-XX:MaxTenuringThreshold=15），但 JVM 还有动态判定：若某年龄批次对象总大小超过 Survivor 空间一半，该年龄及以上对象立即晋升——防止 Survivor 溢出； - Survivor 区太小（如
-XX:SurvivorRatio=2导致仅占新生代 1/4）会导致对象早早“被迫”晋升，加速老年代膨胀；过大则浪费空间，拖慢 Minor GC。
对象何时被回收：分配策略如何牵动 GC 行为
内存怎么分，GC 就怎么扫——二者是硬币两面：
-
Eden 大小直接影响 Minor GC 频率：Eden 占新生代 80%（默认
-XX:SurvivorRatio=8），若应用创建大量短期对象，Eden 快满 → Minor GC 更频繁 → STW 时间累积上升； - 老年代“兜底能力”触发 Full GC：Minor GC 前 JVM 检查老年代剩余空间是否足够容纳本次所有幸存对象（空间分配担保）。若不够，先触发 Full GC——这是最耗时的停顿来源之一；
-
大对象集中分配易引发碎片与压缩开销：CMS 收集器无法整理内存，老年代碎片化后，即使总空闲空间够，也可能因缺乏连续块而失败；G1 则通过 Region 分配+混合回收缓解，但仍需关注
-XX:G1HeapRegionSize与对象尺寸匹配。
调优关键点：从参数到观察
调优不是盲目改数字，而是基于 GC 日志反推分配合理性：
- 观察
gc.log中PSYoungGen和ParOldGen的变化趋势：Minor GC 后老年代持续增长，说明晋升过早或 Survivor 设置不合理； - 用
jstat -gc <pid></pid>查看S0C/S1C（Survivor 容量）、EC（Eden 容量）、OC（老年代容量）及各区使用率； - 典型组合建议：堆设为
-Xms4g -Xmx4g（避免运行中扩容抖动），新生代设为-Xmn1g（约 1/4），再按比例调整 Survivor（如-XX:SurvivorRatio=6）； - 对高吞吐服务，可适度增大 Eden（减少 Minor GC 次数）；对低延迟场景（如金融交易），宜缩小 Eden + 提高晋升阈值，让短期对象更快消亡。
