問題描述
為什么整數(shù) == 運(yùn)算符不適用于 128 及之后的整數(shù)值?有人能解釋一下這種情況嗎?
Why Integer == operator does not work for 128 and after Integer values? Can someone explain this situation?
這是我的 Java 環(huán)境:
This is my Java environment:
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01, mixed mode)
示例代碼:
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");
}
}
部分控制臺(tái)輸出:
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
推薦答案
查看Integer 的源代碼 .您可以在那里看到值的緩存.
Check out the source code of Integer . You can see the caching of values there.
緩存僅在您使用 Integer.valueOf(int) 時(shí)發(fā)生，而不是在您使用 new Integer(int) 時(shí)發(fā)生.您使用的自動(dòng)裝箱使用 Integer.valueOf.
The caching happens only if you use Integer.valueOf(int), not if you use new Integer(int). The autoboxing used by you uses Integer.valueOf.
根據(jù) JLS，您始終可以相信，對(duì)于介于 -128 和 127 之間的值，在自動(dòng)裝箱后您會(huì)獲得相同的 Integer 對(duì)象，并且在某些實(shí)現(xiàn)中，即使對(duì)于更高的值，您也可能會(huì)獲得相同的對(duì)象.
According to the JLS, you can always count on the fact that for values between -128 and 127, you get the identical Integer objects after autoboxing, and on some implementations you might get identical objects even for higher values.
實(shí)際上在 Java 7 中(我認(rèn)為在 Java 6 的較新版本中)，IntegerCache 類的實(shí)現(xiàn) 已更改，上限不再是硬編碼，但可以通過屬性java.lang.Integer.IntegerCache.high"進(jìn)行配置，所以如果你使用 VM 參數(shù) -Djava.lang.Integer.IntegerCache.high=1000 運(yùn)行您的程序，您將獲得相同的值"；所有值.
Actually in Java 7 (and I think in newer versions of Java 6), the implementation of the IntegerCache class has changed, and the upper bound is no longer hardcoded, but it is configurable via the property "java.lang.Integer.IntegerCache.high", so if you run your program with the VM parameter -Djava.lang.Integer.IntegerCache.high=1000, you get "Same values" for all values.
但是 JLS 仍然保證它只到 127:
But the JLS still guarantees it only until 127:
理想情況下，裝箱一個(gè)給定的原始值 p，總是會(huì)產(chǎn)生一個(gè)相同的引用.在實(shí)踐中，使用現(xiàn)有的實(shí)現(xiàn)技術(shù)這可能是不可行的.上述規(guī)則是一種務(wù)實(shí)的妥協(xié).上面的最后一個(gè)條款要求某些常見的值總是被裝箱到無法區(qū)分的對(duì)象中.實(shí)現(xiàn)可能會(huì)延遲或急切地緩存這些內(nèi)容.
Ideally, boxing a given primitive value p, would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rules above are a pragmatic compromise. The final clause above requires that certain common values always be boxed into indistinguishable objects. The implementation may cache these, lazily or eagerly.
對(duì)于其他值，此公式不允許程序員對(duì)裝箱值的身份進(jìn)行任何假設(shè).這將允許(但不要求)共享部分或全部這些引用.
For other values, this formulation disallows any assumptions about the identity of the boxed values on the programmer's part. This would allow (but not require) sharing of some or all of these references.
這可確保在最常見的情況下，行為將是所需的行為，而不會(huì)造成過度的性能損失，尤其是在小型設(shè)備上.例如，內(nèi)存限制較少的實(shí)現(xiàn)可能會(huì)緩存所有字符和短整數(shù)，以及 -32K - +32K 范圍內(nèi)的整數(shù)和長(zhǎng)整數(shù).
This ensures that in most common cases, the behavior will be the desired one, without imposing an undue performance penalty, especially on small devices. Less memory-limited implementations might, for example, cache all characters and shorts, as well as integers and longs in the range of -32K - +32K.
這篇關(guān)于為什么相等運(yùn)算符適用于整數(shù)值直到 128 數(shù)字?的文章就介紹到這了，希望我們推薦的答案對(duì)大家有所幫助，也希望大家多多支持html5模板網(wǎng)！