自动装箱的性能损耗关键在于高频场景下的累积效应，需从字节码指令、对象分配和GC行为三层面量化：循环中频繁出现valueOf、intValue等指令会显著拖慢性能，导致Eden区快速填满、YGC激增，甚至引发空指针异常；优化应聚焦非热点路径，优先使用基本类型及原始集合库。
自动装箱的性能损耗不能只看“一次转换快不快”，而要看它在**高频上下文中的累积效应**——尤其在循环、集合遍历、数学累加等场景下，损耗会指数级放大。真正可量化的关键，是落到字节码指令、对象分配和GC行为三个层面。
看字节码：识别装箱/拆箱指令出现频次
用 javap -c 反编译代码，重点关注以下指令是否在循环体内重复出现：
-
invokestatic java/lang/Integer.valueOf(I)Ljava/lang/Integer;→ 每次迭代都装箱 -
checkcast java/lang/Integer+invokevirtual java/lang/Integer.intValue()I→ 每次取值都解包 -
new java/lang/Integer+dup+invokespecial→ 手动 new，开销比 valueOf 更大
如果这些指令在 for 循环或 forEach 方法体内部反复出现，就说明装箱已进入热路径，必须优化。
测分配：统计每秒创建多少包装对象
借助 JVM 工具直接观测对象生成压力：
立即学习“Java免费学习笔记（深入）”；
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 用
jstat -gc <pid>查看YGC（年轻代 GC）频率和EU（Eden 区使用量）增长速度；高频装箱会让 Eden 区迅速填满 - 用
jcmd <pid> VM.native_memory summary或 JFR（Java Flight Recorder）开启ObjectAllocationInNewTLAB事件，定位哪段代码在大量分配 Integer/Long 实例 - 简单对比：用
long sum = 0L循环累加耗时约 1000ms；换成Long sum = 0L，同一循环可能飙升至 7000ms —— 差距主要来自每轮迭代新建 Long 对象 + 拆箱调用
算成本：一次装箱的实际开销组成
不是“类型转换慢”，而是背后一整套运行时动作：
-
堆内存分配：每次
valueOf()超出缓存范围（如Integer.valueOf(200)）就会执行new Integer()，触发 TLAB 分配 - GC 压力传导：短命 Integer 对象大量进入 Eden 区，加快 YGC 触发频率，STW 时间累积影响吞吐
-
空指针风险：解包时若对象为 null（如 map.get(key) 返回 null），直接抛
NullPointerException，属于隐式运行时成本
缓存仅覆盖 Integer 的 -128 ~ 127 范围，超出即无优化；Long、Double 等默认无缓存，每次都是新对象。
定优化边界：从“哪里能改”倒推量化目标
不追求消除所有装箱，而是把装箱操作控制在**非热点路径**：
- 循环变量、累加器、中间计算结果 → 必须用
int/long，禁用Integer/Long - 集合存储确实需对象语义（如允许 null、需泛型统一接口）→ 改用原始类型集合库（如 Eclipse Collections 的
IntList），字节码全程走iload/iadd，无引用指令 - 必须保留
List<Integer>接口时 → 提前转成int[]再遍历：values.stream().mapToInt(Integer::intValue).toArray()，装箱仅发生在初始化阶段
优化后，可通过字节码中是否还存在上述装箱指令、jstat 中 YGC 频率是否下降、JFR 中对象分配速率是否归零来闭环验证。
