Integer 使用不当导致生产的事故

问题回顾:

某系统是做理财这块业务的,每天会收到一个基金公司的收益文件, 然后需要把这个文件解析并且保存每个用户的收益数据到数据库。 在解析文件的时候,需要对数据的条数做校验,于是用到了 Integer 这个对象并且使用==来判断。 测试环境都没问题,但是到了生产环境上出现用户收益没有到账的问题,造成了大规模的投诉。 最后定位才发现是收益文件验证失败导致没有被解析入库。 所以这里就出现一个问题:"为什么两个 Integer 的对象不能用==号来判断?为什么测试环境没有把这问题测试出来"。


问题分析与解决:

Integer 是一个封装类型。它是对应一个 int 类型的包装。

在 Java 里面之所以要提供 Integer 这种基本类型的封装类,是因为 Java 是一个面向对象的语言, 而基本类型不具备对象的特征,所以在基本类型上做了一层对象的包装并且提供了相关的属性和访问方法来完善基本类型的操作。

在Integer 这个封装类里面,除了基本的 int 类型的操作之外,还引入了享元模式的设计, 对-128 到 127 之间的数据做了一层缓存(如图),也就是说,如果 Integer 类型的目标 值在-128 到 127 之间, 就直接从缓存里面获取 Integer 这个对象实例并返回,否则创建一个新的Integer对象。

java 复制代码
    public static Integer valueOf(int i) {
        int low = -128;
        int h = 127;
        if (i >= IntegerCache.low && i <= IntegerCache.high)
            return IntegerCache.cache[i + (-IntegerCache.low)];
        return new Integer(i);
    }

这么设计的好处是减少频繁创建 Integer 对象带来的内存消耗从而提升性能。 因此在这样一个前提下,如果定义两个 Integer 对象,并且这两个 Integer 的取值范围 正好在-128 到 127 之间。 如果直接用==号来判断,返回的结果必然是 true,因为这两个 Integer 指向的内存地址是同一个。 否则,返回的结果是 false。

之所以在测试环境上没有把这个问题暴露出来,是因为测试环境上验证的数据量有限, 使得取值的范围正好在 Integer 的缓存区间,从而通过了测试。 但是在实际的应用里面,数据量远远超过 IntegerCache 的取值范围,所以就导致了校验失败的问题。

相关推荐
R cddddd42 分钟前
Java实习面试记录
java·spring cloud·java-rocketmq
代码的余温1 小时前
Java试题-选择题(2)
java·开发语言
lemon_sjdk1 小时前
java笔记——ConcurrentLinkedQueue
java·开发语言·笔记
天天摸鱼的java工程师1 小时前
QPS 10 万,任务接口耗时 100ms,线程池如何优化?
java·后端·面试
双向331 小时前
从O(n²)到O(n log n):深度剖析快速排序的内存优化与cache-friendly实现
后端
回家路上绕了弯1 小时前
深度解析:频繁 Full GC 的诊断与根治方案
jvm·后端
武子康1 小时前
大数据-57 Kafka 高级特性 Producer 消息发送流程与核心配置详解
大数据·后端·kafka
知其然亦知其所以然1 小时前
MySQL社招面试题:索引有哪几种类型?我讲给你听的不只是答案!
后端·mysql·面试
天天摸鱼的java工程师1 小时前
掘金图片上传被拒:一次由CheckAuthenticationError引发的密钥‘失踪’迷案
java·后端
福大大架构师每日一题1 小时前
2025-08-01:粉刷房子Ⅳ。用go语言,给定一个偶数个房屋排列在一条直线上,和一个大小为 n x 3 的二维数组 cost,其中 cost[i][j] 表
后端