自动装箱和拆箱是Java 5引入的编译器语法糖，装箱即基本类型→包装类（调用valueOf()），拆箱即包装类→基本类型（调用xxxValue()）；常见于集合操作、方法传参、运算等场景，需警惕NPE、缓存陷阱和性能开销。
自动装箱和拆箱是 Java 5 引入的编译器级语法糖，本质是让基本类型和包装类之间能“看起来无缝”地互相赋值或参与运算，但背后有明确的转换逻辑和潜在风险。
装箱与拆箱到底在做什么
装箱（Boxing）指把基本类型值转成对应包装类对象，比如 int → Integer；拆箱（Unboxing）则相反，把包装类对象取出内部的基本类型值，比如 Integer → int。
关键点在于：这不是 JVM 运行时的魔法，而是编译器在编译阶段就悄悄替你补上了方法调用：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 自动装箱等价于调用 valueOf() 方法，如
Integer i = 10;实际编译为Integer i = Integer.valueOf(10); - 自动拆箱等价于调用 xxxValue() 方法，如
int n = i;实际编译为int n = i.intValue();
哪些地方会悄悄触发装箱/拆箱
这些场景很常见，但容易被忽略其隐含开销或风险：
-
集合操作：List
、Map 等泛型集合要求元素是对象，往里放 list.add(42)就会自动装箱；取值int x = list.get(0)就会自动拆箱 -
方法参数与返回值：调用接受
Integer参数的方法时传入int，或方法返回Integer却赋给int变量，都会触发转换 -
算术与逻辑运算：如
Integer a = 5; int b = a + 3;—— 先拆箱a，再计算，结果仍是基本类型；若写成Integer c = a + b;，则计算后还要再装箱
必须注意的三个典型陷阱
看似方便，但不留意就可能出错或拖慢性能：
-
空指针异常（NPE）：对值为
null的包装类变量执行拆箱，如Integer i = null; int n = i;，运行时直接抛NullPointerException -
缓存陷阱（== 判断失效）：
Integer.valueOf(100)返回缓存对象，Integer a = 100, b = 100; a == b为true；但Integer c = 200, d = 200; c == d是false（超出 -128~127 缓存范围），应统一用equals()比较值 -
循环中性能损耗：在高频循环里频繁使用
Integer替代int（如for (Integer i = 0; i ），每次迭代都触发装箱/拆箱，生成大量临时对象，加重 GC 压力
什么时候该手动控制，而不是依赖自动
多数日常开发用自动机制没问题，但在以下情况建议显式处理：
- 明确需要判断是否为
null时，避免拆箱前未校验——先if (wrapper != null) { int v = wrapper.intValue(); } - 性能敏感路径（如算法内层循环、高频服务逻辑），坚持用基本类型，只在必要处（如存入集合）才做一次装箱
- 需要确保对象唯一性或复用缓存时，主动调用
Integer.valueOf(x)而非new Integer(x)（后者已废弃且不走缓存）
