隐式自动装箱会触发valueof和intvalue调用，引发对象创建与gc压力；缓存仅限-128~127，越界必new对象；集合与stream中泛型擦除加剧装箱开销；应优先使用intstream等原始类型流及数组替代包装类。
隐式自动装箱看似省事，实则在字节码层面悄悄引入对象创建、方法调用和潜在缓存判断，直接影响性能与gc压力。优化的关键不是“少写几行”，而是看清编译器替你干了什么，再针对性绕过。
看懂字节码：装箱=调用valueOf，拆箱=调用intValue
Java编译器对 Integer i = 10; 和 int j = i; 这类写法不做直译，而是翻译为标准方法调用：
-
装箱操作 → 编译为
invokestatic java/lang/Integer.valueOf(I)Ljava/lang/Integer; -
拆箱操作 → 编译为
invokevirtual java/lang/Integer.intValue()I
这意味着每次隐式转换，都是一次静态方法或虚方法调用，还附带一次堆内存分配（除非命中缓存）。用 javap -c 查看字节码，能清晰看到这两条指令——它们就是性能开销的“指纹”。
缓存有边界：-128~127不是万能保险
Integer.valueOf(int) 内部做了小范围缓存（默认 -128 到 127），但超出范围就会 new 对象：
-
Integer a = 100;→ 复用缓存对象，无新分配 -
Integer b = 200;→ 每次都 new Integer(200)，堆上多一个对象
高频场景下（如循环中生成大量非缓存区间整数），会快速制造短命对象，推高 Young GC 频率。别假设“用了valueOf就一定不分配”。
集合与Stream是重灾区：泛型擦除放大装箱代价
泛型在运行时被擦除，ArrayList<integer></integer> 实际存储的是 Object。每次 add(1) 都触发装箱；每次 get(0) 都触发拆箱；而 stream() 默认返回 Stream<integer></integer>，后续 map/filter 全在包装类上运算——每一步都伴随隐式拆装箱。
- 错误示范：
list.stream().mapToInt(x -> x).sum()—— filter阶段仍用Integer，先拆再转int - 正确做法：
IntStream.range(1, n).filter(x -> x % 2 == 0).sum()—— 从源头杜绝包装类
规避策略：用原始类型流 + 显式类型控制代替语法糖
不依赖编译器“猜你要什么”，主动指定原始类型语义：
- 数值计算优先选
IntStream/LongStream/DoubleStream - 避免
List<integer></integer>存储纯计算数据，改用数组int[]或IntArrayList（如 fastutil 库） - 函数式接口若只处理基本类型，定义专用接口如
IntPredicate、IntFunction，而非Predicate<integer></integer> - 必要时手动控制：用
Integer.valueOf(x)替代x直接赋值，明确意图并便于统一监控
字节码不会说谎。把 javap -c 当成日常工具，一眼识别哪行代码悄悄调用了 valueOf 或 intValue，就能在性能问题发生前掐住源头。
