昨天一个工作4年的粉丝私信我,他说最近背了一个生产事故,想让我来给大家分享一下避免采坑。
他是做理财这块业务的,他每天会收到一个基金公司的收益文件,然后他需要把这个文件解析并且保存每个用户的收益数据到数据库。
在解析文件的时候,他需要对数据的条数做校验,于是用到了Integer这个对象并且使用
==
来判断。测试环境都没问题,但是到了生产环境上出现用户收益没有到账的问题,造成了大规模的投诉。
最后定位才发现是收益文件验证失败导致没有被解析入库。
所以这里就出现一个问题:“为什么两个Integer的对象不能用==号来判断?为什么测试环境没有把这问题测试出来”。
另外我花了1个多星期的时间,把往期高手回答整理成了10W字的文档,想获取的小伙伴可以扫描文章尾端名片二维码领取。
下面看看高手对这个问题的回答。
大家记得点赞收藏加关注!
需要高手面试文档面试文档的小伙伴可以扫描文章底部二维码
高手
好的,面试官。
Integer是一个封装类型。它是对应一个int类型的包装。
在Java里面之所以要提供Integer这种基本类型的封装类,是因为Java是一个面向对象的语言,
而基本类型不具备对象的特征,所以在基本类型上做了一层对象的包装并且提供了相关的属性和访问方法来完善基本类型的操作。
在Integer这个封装类里面,除了基本的int类型的操作之外,还引入了享元模式的设计,
对-128到127之间的数据做了一层缓存,也就是说,如果Integer类型的目标值在-128到127之间,
就直接从缓存里面获取Integer这个对象实例并返回,否则创建一个新的Integer对象。
这么设计的好处是减少频繁创建Integer对象带来的内存消耗从而提升性能。
因此在这样一个前提下,如果定义两个Integer对象,并且这两个Integer的取值范围正好在-128到127之间。
如果直接用==
号来判断,返回的结果必然是true,因为这两个Integer指向的内存地址是同一个。
否则,返回的结果是false。
之所以在测试环境上没有把这个问题暴露出来,是因为测试环境上验证的数据量有限,使得取值的范围正好在Integer的缓存区间,从而通过了测试。
但是在实际的应用里面,数据量远远超过IntegerCache的取值范围,所以就导致了校验失败的问题。
总结
对Java基础有一个非常深度的理解是很重要的。
一个小小的知识点,往往能够造成生产环境上较大规模的影响。
所以在一些大厂面试中,基础的考察比例会比较重。
另外一个层面,中间件和技术框架已经是一个成熟的产品,所以即便我们再怎么乱玩,造成的影响也有限。
另外,我将所有Java面试系列制作成了完整的面试文档。它的便捷之处在于,可以通过检索的方式,找到你想要的面试题,目前已经更新180期,总计超过15W字!