一场由Java中Integer引发的踩坑实战

看过阿里巴巴开发手册的同学应该都会对Integer临界值127有点印象。

原文中写的是：

【强制】所有整型包装类对象之间值的比较，全部使用 equals 方法比较。

说明：对于 Integer var = ? 在-128 至 127 之间的赋值，Integer 对象是在 IntegerCache.cache 产生，

会复用已有对象，这个区间内的 Integer 值可以直接使用==进行判断，但是这个区间之外的所有数据，都

会在堆上产生，并不会复用已有对象，这是一个大坑，推荐使用 equals 方法进行判断。

没错，文中要求Integer对象比较的时候必须要用equals进行。

然后很多同学对于为什么要这么干没什么感觉。对于IntegerCache.cache也没什么感觉。

很多时候我们写的代码可能是这样的：

Integer num = 127;
if(num==128){
	//...
}

这种情况下，我们拿Integer和一个数字比较的时候，是不会出什么问题。

然后如果我们这样写

Integer num1 = 127;
num1++;
Integer num2=  128;
if (num1 == num2) {
    System.out.println(true);
}
else{
    System.out.println(false);
}

神奇的事情发生了，num1和num2虽然都是128，但是他们并不相等。

这是因为Integer的值如果是-128~127之间的时候，Integer并不会创建新的对象，而是从IntegerCache.cache中取出的，所以他们随便比较都没有问题。

但是如果超出了这个范围，就不一样了。

不信你可以试试下面的代码：

Integer num1 = 127;
Integer num2=  127;
if (num1 == num2) {
    System.out.println(true);
}
else{
    System.out.println(false);
}

=================================

可惜的是工作中常常忘记了这一点，于是一场意外发生了。

本人前段时间写的一段代码中有下面一段：

String standardItemNameStr = sampleStandardItemList.stream()
  .filter(item -> item.getSampleId()==sample.getSampleId())
  .map(item -> item.getStandardItemName()).collect(Collectors.joining("、"));

系统刚刚上线的时候一切NICE，运行很正常。突然有一天出事了。客户跟反馈出BUG了。

本该显示数据的地方，成了空值。

自己在本地测试，一切OK。代码检测了十遍以上，没发现什么问题。

把生产环境的数据DOWN下来一跑发现其中第二行item.getSampleId()的值是180，这时突然想起Integer的这个设定。二话不说，修改为下面的代码，一切恢复正常。

String standardItemNameStr = sampleStandardItemList.stream()
    .filter(item -> item.getSampleId() .equals(sample.getSampleId()))
    .map(item -> item.getStandardItemName()).collect(Collectors.joining("、"));

这个问题虽然很简单，但还是很容易忽略的。由此也扩展思考了一下，去测试一下Double、Float包装类，并没有catch这类的设计思路。

原因嘛应该也很简单，Integer是整数，很多时候我们用Integer的时候需要用到的值确实是比较小的，所以官方做个catch确实能起到提高执行效率的作用，而且这个缓存命中率还是比较高的，但是小数的主要用途是在小数方面，如果要做catch的话，那数量可就太多了。

那么byte、short、long的包装类会不会也有catch的设计呢？

补充：Java Integer比较中的那些坑

前几天同事偶然遇到的一个问题，在list中查询出重复的值，留下第一个，其余删除。

ArrayList<Integer> a//a中装有要操作的数据，都是数字
for(int i;i<a.size();i++){
    //....遍历
    for(int j=i;j<a.size();j++){
        if(a.get(i)==a.get(j)){
        a.remove(j);
        }
    }
}

然后喜闻乐见的程序出问题了：程序无法将相同的值除第一个外删除掉。说起来这也是一个比较基础性的问题。

int为基本类型，Integer类型为基本包装类型。因而可以将Integer当做一个对象来理解，所以在上面的代码示例中，用==来比较2个对象的引用无疑就是在搞笑了，地址都不一样，怎么可能返回true。

但是这里存在着一些坑，就是Integer有时候用==比较是可以得到true的（值相同），原因如下：

在-128至127之间的赋值，Integer对象是在IntegerCache.cache产生，会复用已有对象，这个区间内的Integer值可以直接使用==进行判断，但是这个区间之外的所有数据，都会在堆上产生，并不会复用已有对象。

所以推荐都使用equals比较。

附上int类型自动装箱为Integer时的源代码（IntegerCache.low为-128）

public static Integer valueOf(int i) {
        assert IntegerCache.high >= 127;
        if (i >= IntegerCache.low && i <= IntegerCache.high)
            return IntegerCache.cache[i + (-IntegerCache.low)];
        return new Integer(i);
    }

这里还牵涉到了一点，就是这里为什么不直接用int类型呢？这是因为ArrayList中只接受Object对象，实际情况如下：

ArrayList al=new ArrayList();
int n=40;
Integer nI=new Integer(n);
al.add(n);//不可以
al.add(nI);//可以

总结

到此这篇关于一场由Java中Integer引发的踩坑实战的文章就介绍到这了,更多相关Java中Integer踩坑内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！