堆内存对象分配是与gc策略实时咬合的动态闭环过程：分配触发回收，回收结果约束下一轮分配；具体方式由gc算法决定，如g1用region划分、zgc/shenandoah激进tlab、serialgc规整布局；minor gc由eden写满触发，大对象直入老年代，晋升依动态年龄判定而非固定阈值，担保失败则引发full gc。
堆内存的对象分配不是静态填空，而是和GC策略实时咬合的动态过程。分配行为直接触发回收动作，回收结果又反过来约束下一轮分配——二者构成闭环反馈。
对象去哪儿，由GC算法说了算
新生代默认用复制算法（如ParNew、Serial），所以Eden区必须规整，适合指针碰撞分配；老年代多用标记-整理或标记-清除（如CMS、G1），空间易碎片化，倾向空闲列表管理。分配方式不是凭空设定，而是被所选GC算法倒逼出来的。
- 用G1时，堆被划分为固定大小Region，大对象可能直接落入单个Humongous Region，跳过新生代流转
- 用ZGC或Shenandoah时，因支持并发标记与移动，TLAB分配更激进，且对象晋升阈值常被弱化甚至忽略
- 若启用-XX:+UseSerialGC，整个堆都按规整布局管理，Eden/Survivor比例固定，分配与回收节奏高度可预测
分配压力是GC启动的开关
Minor GC不是定时闹钟，而是由Eden区“写满”这一具体事件触发。一次new操作是否引发GC，取决于当前Eden剩余空间是否足够容纳该对象（含TLAB预留）。不是所有分配都会导致GC，但每一次GC必然源于某次分配失败。
- 小对象批量创建：可能填满Eden后才触发一次Minor GC，回收效率高
- 单个超大对象（> Eden容量）：直接绕过Eden，尝试进入老年代；若老年代也无连续空间，则触发Full GC
- Survivor区过小或对象年龄增长快：导致提前晋升，加剧老年代压力，间接诱发Old GC或Mixed GC
晋升逻辑决定老年代“体质”
对象什么时候进老年代，不只看年龄，更要看Survivor空间的实际负载。动态年龄判定机制意味着：哪怕某个对象才活过2次Minor GC，只要同龄对象总占Survivor一半以上，它就立刻晋升——这是对内存使用率的实时响应，而非机械计数。
- 设置-XX:MaxTenuringThreshold=15只是上限，实际晋升可能发生在年龄=2、3、6等任意值
- -XX:TargetSurvivorRatio=50（默认）控制的是“临界占比”，调低该值会让对象更快晋升，缓解Survivor压力但加重老年代负担
- 长期存活对象（如Spring Bean）往往在第一次GC后就因引用链稳固而留在Survivor，几轮后自然达到阈值晋升，路径清晰可预期
担保失败是Full GC的导火索
Minor GC前的“内存担保检查”是一道安全阀：JVM先判断老年代是否有足够空间容纳本次可能晋升的所有对象。若判断失败且-XX:+HandlePromotionFailure关闭，就只能停顿全局，执行Full GC。
- 常见诱因：老年代碎片多（如CMS未及时整理）、新生代过大、历史晋升平均值估算偏差大
- 开启HandlePromotionFailure后，JVM会基于过往晋升数据做概率预估，允许“冒险”Minor GC，失败则退回到Full GC
- 频繁担保失败是堆配置失衡的明确信号，需检查-Xmn与-Xmx比例、老年代碎片率、对象生命周期分布
