自动装箱不能优化泛型集合初始化，因其本质是强制类型转换而非性能优化；每次装箱均触发valueOf()或new操作，无法避免对象创建，且泛型擦除和引用类型要求使基本类型无法直接参与。
自动装箱不能用于泛型集合的初始化优化，根本原因在于：泛型集合本身不接受基本类型，而自动装箱只是语法糖，它不改变运行时对象创建的本质，也无法绕过泛型擦除和类型系统限制。
泛型要求引用类型，基本类型天生被排除
Java 泛型在编译期就要求类型参数必须是引用类型。像 List<int> 这样的写法直接编译失败——JVM 不支持基本类型作为泛型实参。因此，哪怕你写 list.add(42)，这个 42 也必须变成 Integer 对象才能存进去。自动装箱在这里不是“优化”，而是强制转换的必经环节。
自动装箱不省对象，只省代码
它不会合并、复用或延迟创建对象，每次触发都对应一次 valueOf()（或 new）调用：
-
list.add(1)→Integer.valueOf(1)→ 缓存命中，复用对象 -
list.add(200)→Integer.valueOf(200)→ 超出缓存范围，每次新建对象 -
List<Integer> list = Arrays.asList(1, 2, 3);→ 三个独立装箱操作，生成三个对象
初始化阶段无法做“批量优化”
集合初始化（如构造器、Arrays.asList、静态块赋值）发生在运行时，编译器无法预知数据规模、取值分布或后续使用方式，因此无法：
立即学习“Java免费学习笔记（深入）”；
- 把多个
int打包成一个紧凑结构 - 跳过装箱直接存原始值（因为底层仍是
Object[]） - 统一替换为原始类型集合（那是第三方库或 JDK 特化 API 的事，比如
IntList或IntStream）
真正有效的替代方案不是“优化装箱”，而是绕开它
想提升性能，重点不在让装箱更快，而在减少甚至消除装箱需求：
- 高频数值计算用
int[]或IntArrayList（Trove/Eclipse Collections） - 流式处理优先选
IntStream.of(1,2,3).sum()，而非Stream.of(1,2,3).mapToInt(i -> i).sum() - 字段/参数能用
int就不用Integer，尤其避免private static final Integer CODE = 200这类“一次性装箱”
