为什么Integer常量池的行为在127发生变化？

  • Z时代
  • 2024-01-10
  • 分类：问答

我无法理解Java常量池常量的工作方式。

我了解字符串的行为，因此可以证明自己与整数常量也是如此。

所以，对于整数

Integer i1 = 127;
Integer i2 = 127;
System.out.println(i1==i2); // True

和

Integer i1 = new Integer(127);
Integer i2 = new Integer(127);
System.out.println(i1==i2); // False

直到这里一切都进入我的脑海。

我无法理解的是，当我从127增加整数时，它的行为有所不同。此行为在127之后发生变化，下面是代码段

Integer i1 = 128;
Integer i2 = 128;
System.out.println(i1==i2); // False. WHY?????

有人可以帮我理解吗？

回答：

不，用于数字的常量池与用于字符串的方法不同。对于字符串，只保留编译时常量-而对于整数类型的包装器类型，如果适用于该值，则任何装箱操作将始终使用该池。因此，例如：

int x = 10;
int y = x + 1;
Integer z = y; // Not a compile-time constant!
Integer constant = 11;
System.out.println(z == constant); // true; reference comparison

JLS保证池值的范围很小，但是实现可以根据需要使用更大的范围。

请注意，尽管不能保证，但是我看过的每个实现都可以Integer.valueOf用来执行装箱操作-因此，在没有语言帮助的情况下，你可以获得相同的效果：

Integer x = Integer.valueOf(100);
Integer y = Integer.valueOf(100);
System.out.println(x == y); // true

从JLS的5.1.7节开始：

如果装箱的值p为true，false，字节或\ u0000到\ u007f范围内的char或-128到127（含）之间的整数或短数，则令r1和r2为p的任何两次拳击转换。r1 == r2总是这样。

理想情况下，将给定的原始值p装箱将始终产生相同的参考。实际上，使用现有的实现技术可能不可行。以上规则是一种务实的妥协。上面的最后一个子句要求始终将某些通用值装在无法区分的对象中。该实现可以懒惰地或急切地缓存它们。对于其他值，此公式不允许对程序员方面的带框值的身份进行任何假设。这将允许（但不要求）共享部分或全部这些引用。

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

以上是 为什么Integer常量池的行为在127发生变化？ 的全部内容， 来源链接： utcz.com/qa/411014.html

回到顶部