自动装箱本质是调用Integer.valueOf()而非new Integer()，其内部对-128~127范围整数缓存复用；拆箱本质是调用xxxValue()，null时抛NullPointerException；算术运算、集合操作、方法调用等均会隐式触发装箱/拆箱。
自动装箱本质是调用 Integer.valueOf()，不是 new Integer()
Java 编译器在遇到 Integer i = 10; 这类赋值时，并不会生成 new Integer(10) 字节码，而是插入 Integer.valueOf(10) 调用。这点从 javap -c 反编译结果可直接验证——字节码里明确出现 invokestatic #2 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;。
-
valueOf()内部有缓存优化：对-128到127（含）之间的整数，复用常量池中已存在的Integer实例；超出范围则新建对象 - 所以
Integer a = 127; Integer b = 127;时a == b为true；但Integer c = 128; Integer d = 128;时c == d为false -
Double.valueOf()、Float.valueOf()等不缓存，每次调用都新建对象，因此永远不要用==比较它们的引用
自动拆箱本质是调用 xxxValue()，null 时直接抛 NullPointerException
当写 int x = integerObj;，编译器实际插入的是 integerObj.intValue()。这意味着：只要 integerObj 是 null，运行时立刻触发空指针异常——哪怕你只是想做个安全比较或默认值 fallback。
- 常见踩坑场景：
map.get("key")返回Integer，直接赋给int变量，而没检查是否为null - 错误写法：
Integer status = configMap.get("status"); int code = status; // status 为 null → NullPointerException - 安全写法：
Integer status = configMap.get("status"); int code = (status != null) ? status : 0;或使用Objects.requireNonNullElse(status, 0)
哪些地方会隐式触发装箱/拆箱？不只是赋值
装箱和拆箱不是只发生在变量赋值语句里，任何类型不匹配但语义上“合理”的上下文，编译器都会介入。最容易被忽略的是算术表达式和集合操作。
- 算术混合运算：
Integer a = 5; int b = a + 3;→ 先拆箱a.intValue()，再执行加法 - 集合泛型：
List→list = new ArrayList(); list.add(42); 42自动装箱；int x = list.get(0);→ 自动拆箱 - 方法参数传递：
void process(int x) { ... }; process(integerObj);→ 拆箱；void accept(Integer x) { ... }; accept(100);→ 装箱 - 三元运算符：
Integer a = flag ? 1 : null;→1被装箱；但int b = flag ? integerObj : 0;→ 若integerObj为null，仍会 NPE
性能与设计权衡：别在高频循环或底层工具类里滥用
每次装箱都可能新建对象（尤其超出缓存范围），每次拆箱都要做非空校验和方法调用。在吞吐敏感路径（如网络解析、日志格式化、数值计算循环）中，累积开销可观。
立即学习“Java免费学习笔记（深入）”；
- 反模式示例：
for (int i = 0; i < 100000; i++) { list.add(i); // 每次都装箱 → 10w 个 Integer 对象 - 替代方案：若只需临时计算，优先用基本类型变量；若必须存集合，考虑
IntArrayList（如 Trove、Eclipse Collections）等原生 int 集合库 - 注意
OptionalInt、IntStream等专门针对基本类型的 API，它们全程避免装箱，比Optional和Stream更轻量
最隐蔽的风险不是性能，而是 null 拆箱和 == 误判——这两个问题在线上环境往往表现为偶发 NPE 或逻辑错乱，排查时容易绕远路。写完涉及包装类型的代码，盯住所有 =、+、?、.get() 的位置，问一句：“这里会不会是 null？我是不是在用 == 比较两个包装类？”
