一尘不染

为什么equal运算符对Integer值直到128数字有效?

java

为什么Integer “ =”运算符不适用于128和Integer值之后的值?有人可以解释这种情况吗?

这是我的Java环境:Java版本“ 1.6.0_37”

Java(TM)SE运行时环境(内部版本1.6.0_37-b06)

Java HotSpot(TM)64位服务器VM(内部版本20.12-b01,混合模式)

样例代码:

    Integer a;
    Integer b;
    a = 129;
    b = 129;

    for (int i = 0; i < 200; i++) {
        a = i;
        b = i;

        if (a != b) {
            System.out.println("Value:"+ i + " - Different values");
        } else {
            System.out.println("Value"+ i + " Same values");
        }
    }

控制台输出的一部分:

Value:124 - Same values
Value:125 - Same values
Value:126 - Same values
Value:127 - Same values
Value:128 - Different values
Value:129 - Different values
Value:130 - Different values
Value:131 - Different values
Value:132 - Different values

谢谢!


阅读 345

收藏
2020-03-22

共1个答案

一尘不染

查看Integer的源代码。你可以在那里看到值的缓存。

缓存仅在你使用时发生Integer.valueOf(int),而不是在使用时发生new Integer(int)。你使用的自动装箱Integer.valueOf

根据JLS,你始终可以相信,对于-128到127之间的值,自动装箱后你将获得相同的Integer对象,并且在某些实现中,即使对于更高的值,也可能会获得相同的对象。

实际上,在Java 7中(并且我认为在Java 6的较新版本中),IntegerCache类的实现已更改,并且上限不再进行硬编码,而是可以通过属性“ java.lang.Integer.IntegerCache进行配置”。高”,因此,如果使用VM参数运行程序,则-Djava.lang.Integer.IntegerCache.high=1000所有值都将获得“相同值”。

但是JLS仍然只保证直到127:

理想情况下,将给定的原始值p装箱将始终产生相同的参考。实际上,使用现有的实现技术可能不可行。以上规则是一种务实的妥协。上面的最后一个子句要求始终将某些通用值装在无法区分的对象中。该实现可以懒惰地或急切地缓存它们。

对于其他值,此公式不允许对程序员方面的带框值的身份进行任何假设。这将允许(但不要求)共享部分或全部这些引用。

这样可以确保在最常见的情况下,这种行为将是理想的行为,而不会造成不必要的性能损失,尤其是在小型设备上。例如,较少内存限制的实现可能会缓存所有字符和短裤以及-32K-+ 32K范围内的整数和长整数。

2020-03-22