Java：整数等于与 ==
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3637936/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Java: Integer equals vs. ==
提问by Jeremy Goodell
As of Java 1.5, you can pretty much interchange Integerwith intin many situations.
从Java 1.5中，你几乎可以互换Integer使用int在许多情况下。
However, I found a potential defect in my code that surprised me a bit.
然而，我在我的代码中发现了一个潜在的缺陷，这让我有点惊讶。
The following code:
以下代码：
Integer cdiCt = ...;
Integer cdsCt = ...;
...
if (cdiCt != null && cdsCt != null && cdiCt != cdsCt)
mismatch = true;
appeared to be incorrectly setting mismatch when the values were equal, although I can't determine under what circumstances. I set a breakpoint in Eclipse and saw that the Integervalues were both 137, and I inspected the boolean expression and it said it was false, but when I stepped over it, it was setting mismatch to true.
当值相等时，似乎错误地设置了不匹配，尽管我无法确定在什么情况下。我在 Eclipse 中设置了一个断点，看到Integer两个值都是 137，我检查了布尔表达式，它说它是假的，但是当我跨过它时，它将不匹配设置为真。
Changing the conditional to:
将条件更改为：
if (cdiCt != null && cdsCt != null && !cdiCt.equals(cdsCt))
fixed the problem.
解决了这个问题。
Can anyone shed some light on why this happened? So far, I have only seen the behavior on my localhost on my own PC. In this particular case, the code successfully made it past about 20 comparisons, but failed on 2. The problem was consistently reproducible.
任何人都可以解释为什么会发生这种情况吗？到目前为止，我只在我自己的 PC 上看到了本地主机上的行为。在这种特殊情况下，代码成功地通过了大约 20 次比较，但失败了 2 次。问题始终是可重现的。
If it is a prevalent problem, it should be causing errors on our other environments (dev and test), but so far, no one has reported the problem after hundreds of tests executing this code snippet.
如果这是一个普遍的问题，它应该会在我们的其他环境（开发和测试）中导致错误，但到目前为止，在执行此代码片段的数百次测试之后，没有人报告该问题。
Is it still not legitimate to use ==to compare two Integervalues?
==用于比较两个Integer值仍然不合法吗？
In addition to all the fine answers below, the following stackoverflow link has quite a bit of additional information. It actually would have answered my original question, but because I didn't mention autoboxing in my question, it didn't show up in the selected suggestions:
除了下面所有的好答案之外，下面的 stackoverflow 链接还有很多额外的信息。它实际上会回答我原来的问题，但因为我没有在我的问题中提到自动装箱，它没有出现在选定的建议中：
Why can't the compiler/JVM just make autoboxing “just work”?
采纳答案by Adam
The JVM is caching Integer values. == only works for numbers between -128 and 127 http://www.owasp.org/index.php/Java_gotchas#Immutable_Objects_.2F_Wrapper_Class_Caching
JVM 正在缓存整数值。== 仅适用于 -128 和 127 之间的数字 http://www.owasp.org/index.php/Java_gotchas#Immutable_Objects_.2F_Wrapper_Class_Caching
回答by MattC
The issue is that your two Integer objects are just that, objects. They do not match because you are comparing your two object references, not the values within. Obviously .equalsis overridden to provide a value comparison as opposed to an object reference comparison.
问题是您的两个 Integer 对象就是对象。它们不匹配，因为您正在比较两个对象引用，而不是其中的值。显然.equals被覆盖以提供值比较而不是对象引用比较。
回答by wheaties
Integerrefers to the reference, that is, when comparing references you're comparing if they point to the same object, not value. Hence, the issue you're seeing. The reason it works so well with plain inttypes is that it unboxes the value contained by the Integer.
Integer指的是引用，也就是说，在比较引用时，您要比较的是它们是否指向同一个对象，而不是值。因此，你看到的问题。它适用于普通int类型的原因是它将Integer.
May I add that if you're doing what you're doing, why have the ifstatement to begin with?
我可以补充一点，如果你正在做你正在做的事情，为什么要以if声明开头？
mismatch = ( cdiCt != null && cdsCt != null && !cdiCt.equals( cdsCt ) );
回答by Colin Hebert
You can't compare two Integerwith a simple ==they're objects so most of the time references won't be the same.
您无法将两个Integer与简单的==对象进行比较，因此大多数情况下引用不会相同。
There is a trick, with Integerbetween -128 and 127, references will be the same as autoboxing uses Integer.valueOf()which caches small integers.
有一个技巧，Integer在 -128 和 127 之间，引用将与Integer.valueOf()缓存小整数的自动装箱使用相同。
If the value p being boxed is true, false, a byte, a char in the range \u0000 to \u007f, or an int or short number between -128 and 127, then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.
如果被装箱的值 p 是真、假、一个字节、一个 \u0000 到 \u007f 范围内的字符，或者一个 int 或 -128 到 127 之间的短数，那么让 r1 和 r2 是任何两个装箱转换的结果p. 的 r1 == r2 总是如此。
Resources :
资源 ：
On the same topic :
在同一主题上：
回答by vijay
"==" always compare the memory location or object references of the values. equals method always compare the values. But equals also indirectly uses the "==" operator to compare the values.
“==”总是比较值的内存位置或对象引用。equals 方法总是比较值。但是 equals 也间接使用“==”运算符来比较值。
Integer uses Integer cache to store the values from -128 to +127. If == operator is used to check for any values between -128 to 127 then it returns true. for other than these values it returns false .
Integer 使用 Integer 缓存来存储从 -128 到 +127 的值。如果 == 运算符用于检查 -128 到 127 之间的任何值，则返回 true。除了这些值，它返回 false 。
Refer the link for some additional info
有关其他信息，请参阅链接
回答by ZhaoGang
Besides these given great answers, What I have learned is that:
除了这些给出了很好的答案，我学到的是：
NEVER compare objects with == unless you intend to be comparing them by their references.
永远不要用 == 比较对象，除非你打算通过它们的引用来比较它们。
回答by Mc Bton
As well for correctness of using ==you can just unbox one of compared Integervalues before doing ==comparison, like:
同样为了使用的正确性，==您可以Integer在进行==比较之前将比较值之一拆箱，例如：
if ( firstInteger.intValue() == secondInteger ) {..
The second will be auto unboxed (of course you have to check for nulls first).
第二个将自动拆箱（当然你必须先检查nulls）。
