Java自动装箱开销需综合对象生命周期、缓存（-128~127）、调用频次与GC压力评估；盲目替换Integer为int可能引入null风险；高频场景应通过JFR/async-profiler定位热点，优先优化火焰图Top10方法及GC影响。
Java 中自动装箱（Autoboxing）的开销不能只看“一次装箱多少纳秒”，而要结合对象生命周期、缓存机制、调用频次和 GC 压力综合评估。盲目替换 Integer 为 int 可能掩盖真正瓶颈，也可能引入隐式 null 解引用风险。
看是否命中缓存：-128 到 127 是关键分水岭
Java 对 Boolean、Byte、Character（\u0000–\u007f）、Short、Integer（-128 至 127）做了缓存。在这个范围内的自动装箱不创建新对象，开销极小；超出则每次触发 new Integer()，带来堆分配和后续 GC 成本。
- 高频循环中用
Integer i = 100没问题，但Integer i = 300就可能累积大量短命对象 - 可通过
Integer.valueOf(300) == Integer.valueOf(300)返回false验证是否缓存失效 - 注意：缓存范围可通过 JVM 参数
-XX:AutoBoxCacheMax=2000扩展，但仅影响Integer
查调用栈深度和热点位置：避免在 hot path 上装箱
用 JFR（Java Flight Recorder）或 async-profiler 抓取 CPU 火焰图，重点关注 Integer.valueOf、Long.valueOf 等方法是否出现在高占比栈帧中。尤其警惕以下场景：
- 集合遍历中用
for (Integer x : list)配合list.get(i)返回int→ 装箱再拆箱 - Stream 处理基本类型包装类，如
list.stream().mapToInt(Integer::intValue).sum()实际已拆箱，但源头若为List<integer></integer>，仍存在存储开销 - 日志或 toString() 中隐式调用，如
log.info("value={}", obj.getId())，若 getId() 返回Integer，会触发装箱+字符串拼接双重开销
权衡可读性与性能：不是所有装箱都该消灭
装箱本身单次成本约 5–20 ns（现代 JVM），远低于一次 HashMap 查找或一次 I/O。优化优先级应是：
立即学习“Java免费学习笔记（深入）”；
- 先确认它出现在压测/线上火焰图的 Top 10 方法中
- 检查是否引发 Minor GC 次数明显上升（通过
jstat -gc观察YGC和YGCT） - 避免为省几个纳秒把
Optional<integer></integer>改成OptionalInt，除非明确需要链式计算且调用量达百万/秒级 - 接口设计上，对内部高频模块用原始类型 + 专用容器（如 Trove、Eclipse Collections），对外 API 仍可保留包装类保证 null 安全和语义清晰
用工具验证而非猜测：三步实测法
写微基准测试时，必须用 JMH，并控制变量：
- 对比
List<integer></integer>vsIntList（如 Eclipse Collections 的MutableIntList）在相同数据量下的吞吐量与 GC 时间 - 用
@Fork(jvmArgsAppend = "-Xmx64m")限制堆，放大装箱对 GC 的影响 - 开启 JFR 录制，导出事件查看 “Object Allocation Outside TLAB” 是否集中在 valueOf 方法
