避免Java自动装箱拆箱性能陷阱的关键是明确高频触发场景并主动绕过语法糖，优先使用原始类型集合、基本类型日志传参、预判null的显式拆箱及缓存可控的valueOf()调用。
避免Java自动装箱与拆箱的性能陷阱，关键不是禁用它，而是清楚知道哪些场景会高频触发、何时该绕过语法糖、用什么替代更高效。
高频循环中彻底避开装箱
在for循环、stream数值计算、批量日志等场景下，反复将int转Integer或反之，会持续创建短生命周期对象，显著增加GC压力。
- 不要写：
List<integer> list = new ArrayList(); for (int i = 0; i —— 每次add都装箱</integer> - 改用原始类型集合库：Eclipse Collections 的
IntList、Trove 的TIntArrayList，或直接用int[] - 日志占位符传参时，优先传基本类型（如
log.info("count: {}", count)，其中count是int），SLF4J能避免装箱；若传Integer，则仍会触发
泛型容器操作前评估数据规模
泛型擦除导致每次add/get都伴随一次装箱/拆箱。小数据量影响不大，但百万级数值运算或实时统计类逻辑中，开销不可忽视。
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- Map
存大量计数？考虑用 ObjIntMap<string></string>（Eclipse Collections）或TObjectIntHashMap<string></string>（Trove） - 数据库查询返回List
用于后续计算？尽早转为原始数组： int[] arr = list.stream().mapToInt(Integer::intValue).toArray() - 避免在热点路径中混用包装类和基本类型做算术，例如
sum += boxedValue—— 每次都隐式拆箱
明确控制装箱时机，不用编译器“替你决定”
自动装箱看似方便，但valueOf()是否走缓存、是否新建对象，取决于值范围和JVM参数。性能敏感处必须可预测。
立即学习“Java免费学习笔记（深入）”；
- 统一用
Integer.valueOf(x)，不用new Integer(x)（已废弃），也不依赖Integer i = x这种隐式写法 - 对Long、Integer等可能超出缓存范围的值，若需复用对象，可预热缓存（如启动时调用
Long.valueOf(1000)多次），或自定义对象池 - 第三方API返回包装类（如OptionalInt.orElse()返回int，但某些ORM返回Integer）？立即拆箱并校验null，不带入后续计算链
警惕三元表达式和条件分支中的隐式拆箱
这类写法表面无害，实则在字节码层面强制插入拆箱指令，一旦值为null，NPE发生在最意想不到的位置，还拖慢执行路径。
- 错误示例：
int value = flag ? map.get("key") : 0;—— 若get返回null，此处直接NPE - 安全写法：
Integer boxed = map.get("key"); int value = (boxed != null) ? boxed : 0;或Objects.requireNonNullElse(boxed, 0) - 流式处理中避免
list.stream().mapToInt(Integer::intValue)前未过滤null，应先.filter(Objects::nonNull)
