★ FEATURED ARTICLE 日常开发写代码基本都会频繁用到基本类型和包装类互换。int、long、boolean 这类基础类型搭配 Integer、Long、Boolean 使用平时赋值、计算、传参编译器自动帮我们完成装箱拆箱体感上完全感知不到差异。也正是因为太透明很多人写代码完全不设防。默认包装类不会空、默认计算逻辑绝对安全直到线上偶尔爆出空指针定位代码一看完全想不通这里为什么会空。我之前处理过好几次线上偶发 NPE既不是对象为空也不是参数未校验根源全是自动拆箱触发的隐性空异常。最常见也最容易被忽视的场景就是包装类直接参与数学运算。业务代码里经常有数值累加、差值计算、倍率换算很多人直接拿 Integer、Long 类型的字段去加减乘除。数据库字段允许为空、接口参数未传值、缓存取不到数据都会导致包装类变量为 null。编译阶段完全没问题运行时一旦触发拆箱直接空指针报错。这种报错特别隐蔽正常有值的情况下百分百正常运行只有字段为空的边界场景才会炸。测试用例大多覆盖正常数值很难复现基本都是线上真实场景才暴露问题。很多人习惯用包装类接收数据库可空字段却沿用基本类型的计算逻辑这是最大的问题来源。还有一个坑点是三目运算符引发的隐性装箱问题。不少精简代码会用三目做默认值判断一边写基本类型、一边写包装类型。编译器编译后会统一做自动装箱处理整体变成包装类型。看似简洁的代码实际暗藏空值风险。一旦条件分支里出现 null 值后续直接触发拆箱异常。很多人排查代码看着逻辑完全没问题怎么都想不到是三目语法导致的类型隐性转换。缓存取值、RPC 返回值也是重灾区。Redis、远程接口返回数值类型大概率会出现 null 的情况。直接赋值给基本类型变量会强制拆箱瞬间抛出异常。很多业务为了偷懒不做 null 判断直接强转、直接赋值、直接计算。本地测试缓存全是正常值线上缓存过期、未命中、数据清空瞬间触发批量报错。还有一个细节很多人分不清基本类型和包装类型的默认值差异。基本类型有固定默认值int 默认0、long 默认0L。包装类型默认全是 null。实体类、DTO、缓存模型里的数值字段绝大多数都用包装类。很多开发潜意识里觉得数值字段不可能为空直接参与业务判断、金额计算、状态比对。一旦遇到历史空数据、新业务未赋值数据null 参与判断逻辑会出现和预期完全不符的结果甚至直接崩流程。常年写代码慢慢发现自动装箱拆箱是 Java 最温柔的陷阱。编译器帮我们抹平了类型差异提升了开发效率却也让很多人忽略了空值风险。所有线上这类空指针从来不是语法问题都是编码习惯松散造成的边界漏洞。现在我写数值逻辑只要是包装类字段但凡涉及计算、比较、赋值一定会提前做空值兜底。不再依赖编译器自动转换也不再凭直觉默认数值一定存在。很多微小的语法细节看着无关痛痒恰恰是线上稳定性的关键。
阅读完成 · 觉得有帮助？
