自动装箱与拆箱在高性能Java框架中易引发对象创建、GC压力和空指针异常，应优先使用原始类型数组、专用原生集合（如IntArrayList）、避免泛型误用，并显式控制装拆箱时机以保障性能与安全性。
自动装箱（autoboxing）和拆箱（unboxing）在 Java 中看似方便，但在高性能框架中极易成为性能瓶颈——它们会隐式创建对象、触发额外 GC、引发空指针异常，且在循环、高频计算或并发场景下放大开销。规避的核心不是“禁用”，而是“有意识地绕过”。
优先使用原始类型数组与专用集合库
原始类型（如 int、long、double）不参与装箱，是零成本抽象的基础。
- 避免
List<integer></integer>，改用IntArrayList（来自 Eclipse Collections）或TIntArrayList（Trove）等原生类型集合 - 高频数值计算场景（如指标聚合、时间序列处理），直接使用
int[]、long[]或DoubleBuffer，跳过任何泛型包装 - 注意：Java 标准库的
Arrays.asList(int[])会把整个数组当作一个元素装箱为List<int></int>，不是你想要的
禁用泛型对原始类型的误用
泛型擦除机制决定了 List<t></t> 在运行时只能存对象引用，强制装箱无法避免。关键是要识别并拦截这类误用点：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 在构建阶段用 SpotBugs 或 ErrorProne 插件启用
BOXING_INTO_COLLECTION检查，提前拦截Map<string integer></string>类型在热点路径中的使用 - 对配置类、DTO、缓存 key 等非计算场景，可接受装箱；但对计数器、滑动窗口、布隆过滤器底层等，必须定义专用原始类型结构（如
LongCounter） - 不要为图便利写
map.computeIfAbsent(key, k -> 0)——0是Integer字面量，每次调用都装箱；应改用computeIfAbsent(key, k -> new AtomicInteger(0))或预分配原子数组
手动控制拆箱时机，杜绝隐式空解包
拆箱最危险的不是性能，而是 NullPointerException：当 Integer 为 null 时，int x = integerObj; 直接抛异常。高性能框架必须消除这种不确定性。
立即学习“Java免费学习笔记（深入）”；
- 所有入参、返回值、缓存值若可能为
null，绝不直接拆箱；统一用Objects.requireNonNull(integerObj, "xxx must not be null").intValue()显式断言 - 用 OptionalInt / OptionalLong 替代
Optional<integer></integer>，避免二次装箱（Optional.of(42)→ 装箱Integer→ 再包装成Optional） - 在序列化/反序列化层（如 JSON 解析），配置 Jackson 使用
@JsonFormat(shape = JsonFormat.Shape.NUMBER)强制原始类型绑定，避免中间生成Integer对象
编译期与 JIT 友好写法
某些写法看似无害，实则阻碍 JVM 优化：
- 避免在循环内写
list.add(i)（i 是int）——每次 add 都触发一次装箱；改用批量构造或原始集合 - 不要用
Integer.valueOf(x).compareTo(y)，直接用Integer.compare(x, y)（静态方法，不创建对象） - 慎用 lambda 表达式捕获原始变量：若 lambda 被转为函数式接口实例（如
Supplier<integer></integer>），捕获的int会被装箱；优先用IntSupplier等专用函数式接口
