自动装箱生成的包装类对象默认分配在新生代Eden区，是否晋升老年代取决于存活时间、对象大小及引用持有情况，与是否自动装箱无关；小整数（-128~127）复用缓存对象，不涉及堆内存分配。
Java中自动装箱生成的包装类对象（如 Integer i = 100;）不会立刻进入老年代，它们和其他普通对象一样，默认分配在新生代Eden区，生命周期长短取决于实际使用场景和GC行为，与“是否是装箱产生”无关。
关键点在于：JVM不区分对象是手动 new、反射创建、反序列化，还是自动装箱生成——只看对象大小、存活时间、内存压力等运行时条件。
以下几种情况会影响其是否较快晋升老年代：
小整数缓存（-128 ~ 127）是特例，但不是“进入老年代”，而是根本不会新建对象
例如Integer a = 100; Integer b = 100;，a 和 b 指向的是IntegerCache.cache[]中同一个已存在的对象（位于方法区/元空间），不属于堆中对象，自然不涉及新生代或老年代分配。-
超出缓存范围的装箱对象（如
Integer i = 200;）会真实创建新对象
这类对象：- 初始分配在 Eden 区；
- 若方法调用结束、局部变量出作用域且无其他引用，通常在下一次 Minor GC 就被回收；
- 只有在多次 Minor GC 后仍存活（比如被长期持有于静态集合、缓存、ThreadLocal 等），才可能因年龄达标或 Survivor 溢出而晋升老年代。
大数组包装（如
new Integer[100000]）可能触发大对象直入老年代
注意：这里“大对象”指数组本身占用内存超过-XX:PretenureSizeThreshold（如设为 4MB）。单个Integer对象很小（约 16 字节），但百万级数组对象头+元素总大小可能超阈值，此时整个数组对象会直接分配在老年代——但这属于“大对象规则”，和“装箱”无直接关系。频繁装箱 + 长期持有 → 加速老年代填充
比如循环中list.add(Integer.valueOf(i))，且 list 是静态或长生命周期对象，这些Integer实例无法及时回收，就会逐步晋升到老年代，最终可能引发老年代空间紧张甚至 Full GC。
总结来说：
立即学习“Java免费学习笔记（深入）”；
- 自动装箱 ≠ 特殊生命周期；
- 装箱对象默认走常规分代路径（Eden → Survivor → Old）；
- 是否进老年代，取决于它活了多久、有多大、Survivor 是否装得下、老年代是否兜得住；
- 真正影响晋升速度的是引用持有方式和作用域设计，而不是语法糖本身。
所以，别担心“用了 int 转 Integer 就会压垮老年代”——只要避免无意识的长引用，这类对象多数会在新生代就安静消失。
