Java自动拆箱遇null会抛NPE，因其本质是调用包装类的xxxValue()实例方法，而null无法调用任何方法；常见隐式拆箱场景包括==比较、算术运算、三目运算、mapToInt及取值赋值等。
Java自动拆箱时遇到null包装类会直接抛出NullPointerException，根本原因是JVM在拆箱过程中对null调用了对应基本类型的方法（如Integer.intValue()），而null无法响应任何方法调用。
明确哪些操作会触发自动拆箱
以下场景看似简单，实则隐含拆箱动作，一旦对象为null就会崩溃：
- 用
==或!=与基本类型比较（如Integer a = null; if (a == 0) {...}） - 参与算术运算（如
Integer x = null; int y = x + 1;） - 作为条件表达式中的布尔值（如
Boolean flag = null; if (flag) {...}） - 传入只接受基本类型参数的方法（如
Math.max(int, int)接收Integer）
推荐的防御性写法
不依赖“运气”，主动检查null或使用安全替代方案：
-
显式判空后取值：
int value = (obj != null) ? obj.intValue() : 0; -
使用Objects.requireNonNullElse()（Java 9+）：
int value = Objects.requireNonNullElse(obj, 0).intValue(); -
用Optional封装（更语义化）：
int value = Optional.ofNullable(obj).orElse(0); -
数据库/JSON场景中统一设默认值：如MyBatis用
@Results配置column="xxx" property="y" javaType="int" jdbcType="INTEGER" nullValue="0"
工具类和Lombok辅助
避免重复写判空逻辑，可封装通用方法：
立即学习“Java免费学习笔记（深入）”；
- 自定义工具类：
NumberUtils.toInt(Integer i, int defaultValue) - Lombok的
@NonNull可提醒入参非空，但不解决运行时拆箱问题；配合@SneakyThrows也不推荐用于掩盖NPE - IDEA等工具能静态检测部分潜在拆箱NPE，开启 inspections 中 “Boxing/unboxing of primitive types” 相关提示
设计层面的预防建议
从源头减少null包装类的产生：
- 方法返回值尽量用基本类型（如
int而非Integer），除非需表达“不存在”语义 - 集合、Map中存基本类型时，优先考虑
IntList（如Eclipse Collections）、IntArrayList（FastUtil）等原始类型集合库 - DTO/VO中慎用包装类字段，必要时用
@NotNull+ Bean Validation，并在反序列化时配置默认值（如Jackson的@JsonSetter(nulls = Nulls.SKIP)或@JsonInclude(JsonInclude.Include.NON_NULL)）
