自动装箱通过编译器将基本类型赋值转为调用包装类valueof()方法，如integer i = 100编译为integer.valueof(100)，利用缓存提升性能但需警惕null拆箱npe、三元表达式陷阱及泛型擦除下的频繁装拆箱开销。
自动装箱是怎么调用 valueOf() 的
Java 编译器在遇到基本类型赋值给包装类型时（如 Integer i = 100;），会自动插入对对应包装类 valueOf() 方法的调用，而不是直接调用构造器。例如 int → Integer 转换实际编译为 Integer.valueOf(100)。
这带来两个关键影响：
-
valueOf()对小范围值做了缓存（如Integer.valueOf()缓存 -128 到 127），所以Integer a = 100; Integer b = 100;时a == b为true；但超出缓存范围（如 200）就会新建对象，==返回false -
Boolean.valueOf()、Byte.valueOf()、Short.valueOf()、Character.valueOf()同样有缓存，但Long.valueOf()和Float.valueOf()在 JDK 5–8 中默认只缓存 -128~127（Long的缓存范围可通过-Djava.lang.Long.IntegerCache.high扩展） - 自定义包装类（如自己写的
MyInt）不会被编译器识别，无法触发自动装箱
拆箱失败时抛出 NullPointerException
当一个为 null 的包装类型变量参与自动拆箱（如 int x = integerObj;），JVM 会在运行时调用其 xxxValue() 方法（如 integerObj.intValue()），而 null 上调用任何实例方法都会触发 NullPointerException。
常见踩坑场景：
立即学习“Java免费学习笔记（深入）”；
- 从
Map或 JSON 解析结果中取值后直接拆箱：Integer status = map.get("status"); int s = status;—— 若 key 不存在，status为null，立刻崩溃 - 三元表达式中混用包装类型和基本类型：
Integer a = null; int b = a != null ? a : 0;表面安全，但实际仍会先尝试拆箱a导致 NPE（JDK 8+ 已修复此行为，但旧版本或某些编译器优化路径下仍可能触发） - 数据库 ORM 映射字段为
NULL时，若实体字段声明为Integer，getter 返回null，后续链式调用（如user.getAge() + 1）直接报错
泛型擦除让自动装箱/拆箱只发生在边界处
Java 泛型在编译后被擦除，List<integer></integer> 实际存储的是 Object 引用。因此，往 List<integer></integer> 添加 int 值时，必须装箱；从其中读取元素赋给 int 变量时，必须拆箱——这些转换只发生在「泛型边界」，即进出集合的那一刻。
这意味着：
- 集合内部不感知基本类型，所有元素都是对象引用，不存在“部分装箱”的中间状态
- 循环遍历
List<integer></integer>并做算术运算（如sum += list.get(i)）会反复触发拆箱，高频场景下可考虑改用int[]或第三方原生集合库（如 Eclipse Collections 的IntList） - 使用
stream().mapToInt()可提前卸载装箱负担：list.stream().mapToInt(Integer::intValue).sum()避免中间生成大量Integer对象
手动控制装箱时机比依赖自动机制更可控
自动装箱/拆箱是语法糖，不是零成本操作。尤其在循环、高频计算、内存敏感场景中，显式调用 valueOf() 或避免不必要的包装类型能减少 GC 压力和空指针风险。
实用建议：
- 入参能用基本类型就不用包装类型：方法签名优先写
void process(int id)而非void process(Integer id)，除非需要表达 “缺失” 语义 - 初始化时明确是否需要缓存：如需复用小整数对象，用
Integer.valueOf(42)；若确定要新对象（比如测试 identity），才用new Integer(42)（注意：JDK 9+ 已将new Integer(int)标记为 deprecated） - 日志或调试打印时慎用字符串拼接：
log.info("value=" + integerObj);会触发自动拆箱再转字符串，若integerObj为null就变成"value=null"—— 看似无害，但掩盖了本该暴露的逻辑问题
最常被忽略的一点：自动装箱/拆箱的语义隐含了「空安全假设」，而这个假设在真实系统中往往不成立。宁可多写一行判空，也不要赌编译器替你兜底。
